Content

Introduction

Market feedback from the 2018 industry pilot and the v1.0 Standard indicated that requiring the Customer to authenticate and authorise every payment does not support a number of use cases. The industry provided clear guidance that there was significant demand for an ‘enduring payment consent’ standard, and developed and scoped a conceptual design for this. The v2.0 Payments Initiation standard includes functionality to support Third Parties and API Providers bilaterally partnering to offer new services using the ‘enduring payment consent’ standard.

Enduring payment consent functionality offers the Customer a blend of high level control over the parameters of their enduring payment consent, with the convenience of automating payments that fall within the parameters of this enduring payment consent. This addresses key pilot lessons learned regarding the friction a Customer experiences when authenticating and authorising every payment using the v1.0 ‘redirect flow’ process.
Enduring payment consent opens up use cases where the Customer does not need to be present for a payment to be processed, while ensuring the customer remains in control and has appropriately consented to the action.

• The Third Party agrees the terms of the enduring payment consent with the Customer. The consent’s parameters can be limited by payment frequency and value combinations.

• The Third Party uses one of the authentication models (either Redirect or Decoupled) to authenticate the Customer with the API Provider.

• The Customer authorises the enduring payment consent with their API Provider.

• The Third Party initiates a single one-off payment on behalf of the Customer whenever necessary. The API Provider then processes the payment, so long as it is within the parameters of the enduring payment consent.

• The Customer can revoke the consent at any time with either the Third Party or their API Provider.

The high level implications of the enduring payment consent are:

• The Customer will need to be present to initially authenticate themselves to set up the enduring payment consent.

• The Customer does not need to be present to authenticate future payments within the parameters of the enduring payment consent.

While the ‘enduring payment consent’ is understood to be a world first, from a technical design perspective it draws heavily on the standards and processes used to set up the enduring consent that is used to allow Account Information access.

Key principles

The following principles apply to only the enduring payment consent functionality:

Relationship between enduring payment consent and other API standards

The enduring consent functionality for payments sits inside the Payments Initiation API specification only.

The enduring payment consent functionality within the Payments Initiation API does not support or interact with the Account Information API specification.

While this may create a duplication of customer effort when setting up consents for both account information and payments, this position is taken for the following reasons:

• API Provider source account filters differ between payments and account data, i.e. API Providers would have to present two account filters or only present the group of accounts that are common between account data and payments.

• The user experience becomes more complicated, i.e. being presented with consent information at the same time for both account information and payments via enduring consent.

• Enduring payment consent deviates from the upstream UK standard. New Zealand’s Account Information API specification is based directly on this upstream standard.

• The majority of use cases do not require both payments and account information.

• The enduring payment consent functionality does not specify any recourse or liability frameworks with respect to fraudulent or disputed payments. This is left between API Providers and Third Parties to manage bilaterally.

Payment model scenarios

Enduring payment consent has been designed to be flexible in order to support a range of scenarios and use cases.

Optional enduring payment consent endpoint provision

The enduring payment functionality has three API endpoints within the Payments Initiation API standard.

1. POST /enduring-payment-consents - this is used to set up a new enduring payment consent.

2. GET /enduring-payment-consents/{ConsentId} - this is used by Third Parties to obtain the status of an established enduring payment consent.

3. DELETE /enduring-payment-consents/{ConsentId} - this is used by Third Parties to revoke an established enduring payment consent.

Through the development of the enduring payment consent endpoints, it was agreed by all Standards Users that the provision of the enduring payment consent endpoints would be defined as optional in v2.0 of the Payments Initiation API standard.

This was agreed for the following key reasons:

• Technical readiness: Substantial additional technical development will be required in order for API Providers to support the enduring payment consent endpoints. This would substantially affect the short to medium term uptake of the next version of the standards should the endpoint be made mandatory.

• Wider implementation impacts: The adoption of enduring payment consent by API Providers will have wider impacts across business activities, potentially increasing risk to an API Provider’s customer accounts or operational activities.

• Additional v2.0 feature support: Version 2.0 of the API standards support a wide range of additional functionality, including the ‘decoupled’ authentication flow. Making the endpoint optional in v2.0 of the standards will allow for additional API Provider / Third Party use cases to be fulfilled immediately.

• Staggered uptake: This approach will allow the API Centre to proactively engage with API Providers to support the enduring payment consent endpoint as a mandatory resource in future versions of the standard, when technically capable and when additional business risks and mitigation have been assessed and agreed.

Granting an enduring payment consent

Enduring payment consent represents a long lived payment-order consent that has been agreed between the Customer and the Third Party, and contains fields which describe the parameters for payment order(s) that may be initiated by a Third Party on behalf of a Customer.

The Third Party will establish with the Customer the consent attributes that they would like to be granted. The Third Party communicates the consent to the API Provider. The Customer is then authenticated by their API Provider, and are presented with the Third Party’s request to authorise an enduring payment consent.

It is important to note that the attributes of the enduring payment consent that have been agreed between the Third Party and the Customer cannot be altered by the Customer or the API Provider. This applies to both authorising a consent (the Customer reviews the consent and either rejects or authorises it as-is), and once the consent is authorised and in place (the Customer can revoke the consent at any time but cannot alter it). This also applies to the Customer's account that the consent is linked to. The account cannot be altered.

The combination of laws, the API Centre’s Terms and Conditions, and the standard itself combine to ensure the process for how the enduring payment consent is established. The Customer also needs to be compliant and manages risks. For example, the following scenarios have been assessed to ensure they are well managed and have appropriate risk mitigates in place, and complies with the law:

• Ensuring that the customer is clear about what they are putting in place when setting up the enduring payment consent.

• Ensuring that the Third Party cannot send an enduring payment consent object to the API Provider for authorisation that differs from what was agreed between the Customer and the Third Party.

• If the Customer wants to change the account that the consent is loaded against, or change the parameters of an established consent, they must revoke the existing consent and establish a new one. This ensures coordination and clarity between the Customer, API Provider and the Third Party.

Note: Adding flexibility to amend an established enduring payment consent has been identified as a potential future enhancement but for v2.0 of the standard, removing the technical complexity of this use case was considered the best approach.

Consent attributes

A 'consent attribute' reflects the specific payload parameters or conditions for what is allowable under an enduring payment consent. The enduring payment consent standard has been designed to support a very wide range of different use cases and each use case may need to draw on different consent attributes.

Accordingly, the approach being taken is to require the customer to select a small number of core (mandatory) consent attributes only. The standard supports a wide range of other non-mandatory consent attributes that API Providers and/or Third Parties have the option of offering customers in order to deliver their use cases.

The consent attributes have been split into required attributes, and optional attributes below.

The full data dictionary can be found in the enduring payment consents page of the API specifications.

Payment processing

Once an enduring payment consent has been authorised by the Customer, the Third Party is issued a token by the API Provider that represents a long lived payment-order consent. This token is then used when the Third Party initiates one-off payments under the enduring payment consent. The one-off payment is processed via the standard Payments Initiation API flow.

The enduring payment consent acts as a standing authorisation. The Customer does not need to be present for the payment to be processed. API Providers ensure that any one-off payments initiated using the authorised enduring payment consent are within the established parameters. If a Third Party initiates a payment outside of the enduring payment consent parameters, it is rejected by the API Provider. Standardised error codes provide information back to the Third Party to provide reasons why a payment was rejected.

Error code enumerations have been defined as part of the NZ Banking Data API Specifications and are available for review as part of published release candidate.

Revoking a consent

The standard requires that a Customer can revoke their enduring payment consent at any time, at either the Third Party, or the API Provider. Both the Third Party and the API Provider must provide easy pathways for the Customer to revoke their consent.

• The API Provider holds the record of the enduring payment consent.

• The Third Party can revoke the consent by using the DELETE endpoint to advise the API Provider.

If a Customer’s account is closed, all enduring payment consents linked to that account are not longer valid for use.