Contents
One of the primary ambitions of the Guidelines is to provide simplification and consistency of the API Standards implementation. Therefore, we have defined and illustrated a core set of payment initiation journeys.
The API Centre API Standards support Payment Initiation Services that enable a Third Party to:
initiate a single payment order, with explicit consent, from the Customer’s account held at their API Provider.
establish a long lived enduring payment consent that can be used to initiate multiple payment orders, from the Customer’s account held at their API Provider that falls within consented parameters.
The Third Party is then further able to retrieve the status of a payment order and to retrieve a consent from the API Provider.
This section describes how each of the Standard Users (Third Parties and API Providers) in the delivery of these services can optimise the Customer experience for these services. The key components are:
Payments Initiation Consent – A Customer giving consent to a Third Party to request payments initiation from their API Provider.
Third Party Enduring Payment Consent Dashboard and Revocation – facility to enable a Customer to view and cancel consents given to that Third Party.
API Provider Enduring Payment Consent Dashboard and Revocation – facility to enable a Customer to view all Third Parties that have access to their account(s) and the ability to cancel that access. This should be available on those channels that the Customer uses to manage their accounts with the API Provider and be easy and intuitive for the Customer to find and use.
This facility should not include unnecessary steps, superfluous information or language which could discourage the use of Third Party services or divert the Customer from the access management process.
Furthermore, it provides some clarifications to these Standard Users on the use of the APIs which are not covered by the technical specifications, and some best practice guidelines for implementation of the Customer journeys.
A Customer can initiate an instruction to their API Provider to make a one-off payment for a specific amount to a specific payee by providing their consent to a Third Party.
Once all information for a complete payment order (including the Customer’s account details) is passed from the Third Party to the API Provider, and the Customer has been authenticated, the Customer should be directed back to the Third Party domain without any further steps taking place in the API Provider domain.
There are cases where the payment order submitted by Third Parties to API Providers is incomplete, such as where the Customer’s account selection has not yet occurred.
A Customer can provide their enduring consent to a Third Party to initiate multiple one-time payments from a specific account held at an API Provider.
An enduring payment consent provided by a Customer allows a Third Party to initiate multiple one-time payments that fall within the agreed parameters of that enduring consent without needing the Customer to authenticate each individual payment.
The specification data model defines the variable parameters of the consent object that can be agreed with the Customer[1].
Once a Third Party establishes the parameters of the consent with Customer, the required agreed consent information is passed from the Third Party to the API Provider and the Customer is asked to authenticate and confirm the consent with the API Provider. The customer should be directed back to the Third Party domain without any further steps taking place in the API Provider domain.
Enduring Payment Consent can be acquired via any of the authentication flows as detailed in Section 3 – ‘Authentication Methods’.
There are cases where the payment order submitted by Third Parties to API Providers is incomplete, such as where the Customer’s account selection has not yet occurred.
Once a Third Party establishes the bounds of the consent with Customer and passes the Enduring Payment Consent object to the API Provider for account selection and the Customer completes authentication, the Customer should be directed back to the Third Party domain without any further steps taking place in the API Provider domain.
Enduring Payment Consent can be acquired via any of the authentication methods available to single domestic one-time payments as detailed in Section 3 – ‘Authentication Methods’.
The Third Party will be able to initiate a one-off payment on behalf of the Customer using the previously authorised enduring payment consent.
If a single one-off payment is initiated using an enduring payment consent and the payment fails for any reason (e.g., fraud checks, or is deemed outside the agreed enduring consent parameters), the Third Party should inform the Customer and initiate a single one off payment initiation services journey as detailed in Section 5.1 – ‘Mandatory payment initiation services journeys’.
This will not invalidate the enduring payment consent object for future payment initiations.
The Third Party must provide Customers with a facility to view and cancel all enduring payment consents that they have given to that Third Party.
This section describes how these consents should be displayed and how the Customer journey to cancel them should be constructed.
NOTE: It is not possible for a customer to edit / adjust a consent after it has been submitted for authentication and should changes need to be made, the consent must be cancelled and re-established.
API Providers should provide Customers with a facility to view and cancel ongoing enduring payment consents that they have given to any Third Party.
This section describes how all Customer enduring payment consents should be displayed and how the Customer journey to cancel it should be constructed.
NOTE: It is not possible for a Customer to edit / adjust a consent after it has been submitted for authentication and if changes need to be made, the consent must be cancelled and re-established.
[1] https://paymentsnz.atlassian.net/wiki/spaces/PaymentsNZAPIStandards/pages/800031713/Enduring+Payment+Consents+-+v2.1.0#Data-Model
