...
The Payments Initiation API: This enables a customer to make payment(s) via a third party Third Party connecting directly and safely to the customer’s bank (API providerProvider).
Account Information API: This enables a customer to grant a third party Third Party access to the customer’s account information held with the customer’s bank (API providerProvider).
Payments Initiation
The v1.0 Payments Initiation standard redirects the customer from the merchant’s website or app, to their bank (API providerProvider) for authentication and payment authorisation. The v2.0 standard retains this redirect flow, but also adds a decoupled flow as another option for customer interactions and authentication. The v2.0 Payments Initiation standard also introduces enduring payment consent, which provides a long-lived authority for payment(s) to be initiated from a customer’s account, with the customer's consent. Other improvements to the v2.0 Payments Initiation standard have also be made.
...
The v2.0 API standard introduces enduring payment consent, which forms a part of the Payments Initiation specification. Enduring payment consent opens up use cases where the customer does not need to be present for a payment to be initiated.
The third party Third Party agrees the terms or attributes of the enduring payment consent with the Customer. The enduring payment content attributes set the parameters for when a one-off payment may be made. These include, for example: maximum transaction value; maximum payments frequency per time period; duration of the consent; etc.
The third party Third Party uses one of the authentication models, either redirect or decoupled, to authenticate the customer with the API provider Provider and lodge the consent with with the API provider Provider (customer’s bank).
The third party Third Party initiates a one-off payment on behalf of the customer when required, as per the agreement between the customer and the third partyThird Party. The API provider Provider processes the payment as long as it is within the attributes or parameters of that enduring payment consent.
...
Account access consents: Allows a third party to check on the status of a customer’s account access request with an API providerProvider.
Accounts: Allows a third party Third Party to retrieve the full list of accounts the customer has authorised the third party Third Party to access.
Balances: Allows a third party Third Party to retrieve the balance of a specified account(s) the customer has authorised the third party Third Party to access.
Transactions: Allows a third party Third Party to retrieve a list of transactions posted to an account that results in an increase or decrease to a balance within a defined date range.
Beneficiaries: Allows a third party Third Party to retrieve a list of trusted beneficiaries linked to a specific account.
Direct debits: Allows a third party Third Party to retrieve the list of direct debits that have been set up on a specific account.
Offers: Allows the third party Third Party to retrieve the offers available (product features) on a customer account, for example, interest rates, benefits, cash back, etc.
Standing orders (automatic payments): Allows a third party Third Party to retrieve the list of standing orders (New Zealand terminology is automatic payments) that have been set up on a specific account.
Party: Allows a third party Third Party to retrieve information about the party (customer or owner) linked to a specific account. This can include name, email address, phone, mobile, address, etc.
Scheduled payments: Allows a third party Third Party to see the list of scheduled payments set up against a specific account. A scheduled payment is a single one-off payment that has been scheduled for a future date.
Statements: Allows a third party Third Party to request all statements associated with a specific account within a specified date range.
...
The v2.0 standard introduces the decoupled authorisation flow, which provides a more customer and mobile friendly option for the customer to authorise consent (that has already been agreed between a customer and third partyThird Party) with the API providerProvider. This does not replace the existing redirect model summarised below, but instead adds an additional implementation option.
...
The v2.0 standard introduces the decoupled authentication flow, which provides a better experience and more mobile friendly option for how customers can interact with the third party Third Party and API providerProvider. The redirect authentication flow model features in both the v1.0 and v2.0 API standard.
The decoupled flow separates the API provider’s Provider’s and third party’s respective interactions with a customer, making it possible for the API provider Provider to send the customer authorisation request notifications. It also makes it possible for the customer to interact with the third party and their bank (API providerProvider) on different devices for the same action.
...