Explaining enduring payment consent
Content
Introduction
The v2.0 Payments Initiation specification includes functionality to support Third Parties and API Providers that are bilaterally partnering to offer new services using an enduring payment consent. Enduring payment consent offers the customer a blend of having a high level of control over the circumstances that a payment may be made, with the convenience of automating payments that fit those circumstances.
An overview of the enduring payment consent process is:
The Third Party agrees the terms of the enduring payment consent with the customer. The parameters of the consent may be limited by a combination of payment frequency and value.
The Third Party uses one of the authentication flows, 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(s) on behalf of the customer when necessary. The API Provider then processes the payment, as long as it is within the parameters of the authorised enduring payment consent.
The customer may 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 authorise the enduring payment consent with their API Provider.
The customer does not need to be present to authenticate future one-off payments that are within the parameters of the enduring payment consent.
Endpoints
The enduring payment functionality has three API endpoints within the Payments Initiation API specification.
POST /enduring-payment-consents - this is used to set up a new enduring payment consent.
GET /enduring-payment-consents/{ConsentId} - this is used by Third Parties to obtain the status of an established enduring payment consent.
DELETE /enduring-payment-consents/{ConsentId} - this is used by Third Parties to revoke an established enduring payment consent.
It was agreed by all Standards Users that the provision of the enduring payment consent endpoints is an optional feature of the v2.0 Payments Initiation API standard. This optionality allows Standards Users to phase their deployment of the v2.0 standard, and provides sequencing options on how to implement the additional technical development efforts required to develop and implement enduring payment consent.
Update for v2.3 (June 2022)
The Enduring Payment Consent function has been phased from Optional to Mandatory in v2.3 of the API Standards. This means that an API Provider supporting any version of the API Standards from v2.3 onwards, must be able to support the Enduring Payment Consent function as part of their implementations.
Lifecycle
There are three main stages in the lifecycle of an enduring payment consent. They are:
The customer granting an enduring payment consent, i.e. setting it up.
Payment processing.
Revoking a consent (or its expiry).
Granting
Enduring payment consent represents a long-lived payment order that has been agreed between the customer and the Third Party. It contains specific parameters, or attributes, that set the boundaries for when payment(s) may be initiated by a Third Party on behalf of a customer. A combination of laws, the API Centre’s Terms and Conditions, and the API standard itself combine to ensure a robust process is in place for how the enduring payment consent is established. The API Centre is also developing customer experience guidelines to illustrate what the customer interactions might look like.
The first stage is for the Third Party to interact with the customer to agree the consent attributes that the customer would like to grant. The Third Party communicates this consent to the API Provider - this consent must not be altered by the Third Party when they submit it to the API Provider for customer authorisation. The customer is then authenticated by their API Provider, and they are presented with the Third Party’s request to authorise an enduring payment consent.
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 (i.e. the customer decision is to either accept/reject the consent, and it is not an accept/amend/reject decision); and
once the consent is authorised and in place, the customer may revoke the consent at any time but may not alter it.
This also applies to the accounts that the consent is linked to, if specified in the enduring payment consent by the Third Party. The customer's account that funds are debited from cannot be altered once the consent is granted. Also, the account(s) that payments are credited into must be set when the customer grants the consent. If the customer wants to change an account, 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.
Once the consent is established, the API Provider will provide the ability for the customer to view all of their current enduring payment consents. This is to help ensure the customer is in control and informed of the enduring payment consents they have live.
Consent attributes
Each consent attribute in an enduring payment consent reflects a condition for what payment(s) may be initiated using an enduring payment consent. The enduring payment consent specification has been designed to support a wide range of use cases, and each use case may need to draw on different consent attributes.
The customer is required to select a small number of core (mandatory) consent attributes. The specification also 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 https://paymentsnz.atlassian.net/wiki/spaces/PaymentsNZAPIStandards/pages/294486684 .
Required / Optional | Consent attribute | Attribute definition |
|---|---|---|
Required | FromDateTime | Start date time for which the enduring payment consent remains valid. |
Required | MaximumAmount | Maximum amount of money to be moved between the debtor and creditor for an individual payment, before deduction of charges, expressed in the currency as ordered by the initiating party. |
Required | Frequency | The payment limits for a specified period. |
Required | Frequency/Period | Period for which the number of instructions are to be created and processed. |
Optional | ToDateTime | The ToDateTime is optional as the enduring payment consent may be valid for an indefinite period (open ended), or the consent could lapse as at a specific date/time (expiry date). |
Optional | Frequency/TotalCount | Maximum number of instructions to be created and processed during the specified period. |
Required | Frequency/TotalAmount | Maximum amount of money to be moved between the debtor and creditor during the period specified, before deduction of charges, expressed in the currency as ordered by the initiating party. |
Optional | TotalCount | Maximum number of instructions to be created and processed during the specified period. |
Optional | TotalAmount | Maximum amount of money to be moved between the debtor and creditor during the period specified, before deduction of charges, expressed in the currency as ordered by the initiating party. |
Optional | DebtorAccount | Unambiguous identification of the account of the debtor to which a debit entry will be made as a result of the transaction. |
Required | CreditorAccount | Unambiguous identification of the account of the creditor to which a credit entry will be posted as a result of the payment transaction. |
Optional | DebtorAccountRelease | Flags whether the customer has consented with the third party to release their debtor account information. |
Payment processing
Once an enduring payment consent has been authorised by the customer, the Third Party is issued with a token(s) by the API Provider that represent a long-lived payment-order consent. These tokens are then used when the Third Party initiates one-off payments under the enduring payment consent. The one-off payment is processed via the one-off domestic payment flow.
The enduring payment consent acts as a standing authorisation. The customer does not need to be present for the payment to be processed, as long as each domestic payment is within the enduring payment consent parameters. API Providers ensure that any payments initiated using the enduring payment consent are within the established attributes of the consent. The Third Party ensures each one-off payment is within the attributes of the customer’s enduring payment consent. If a Third Party initiates a payment outside of the enduring payment consent attributes, the payment will be rejected by the API Provider.
API Providers have the ability to step up any payment initiated under the enduring payment consent, and require the customer to authenticate and authorise that payment before it is processed, by linking the ID token returned from the enduring payment consent authorisation with a one-off payment request.
Standardised error codes provide information back to the Third Party to provide reasons why a payment was rejected. Error code enumerations have also been defined as part of the API standard.
Revoking
The specification allows a customer to revoke their enduring payment consent at any time, with 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. Note that:
The API Provider holds the record of the enduring payment consent.
The Third Party may revoke the consent by using the DELETE endpoint to advise the API Provider.
The API Provider also has the ability to revoke an enduring payment consent, e.g. if they identify a risk.
If a customer’s account is closed, all enduring payment consents linked to that account are not longer valid for use.