Payments Initiation API Specification - v2.0.0

Version Control

Version

Date

Author

Comments

Version

Date

Author

Comments

v1.0.0

Mar 1, 2019

Payments NZ API Working Group

Baseline Payment Initiation specification. 

v2.0.0-draft1

May 21, 2019

@Gavin Wong

Updated:

  • Reword payment setup to payment-order consent

  • Reword payment submission to payment-order

  • Updated v2.0-draft1-DocumentStructure to reflect new structure

  • Updated v2.0-draft1-OutofScope from "Multi-authentication flows have been designed..." to "Payments that require multiple authorisers."

  • Updated v2.0-draft1-Steps to reflect (1) renamed resources and (2) decoupled flow

  • Updated v2.0-draft1-SequenceDiagram to reflect revised v2.0-draft1-Steps

  • Section on Payment Limits renamed to v2.0-draft1-Restrictions (aligned to OBIE v3.1.2)

  • v2.0-draft1-Endpoints section to include (1) new enduring payment consent endpoints and (2) renamed resources

  • v2.0-draft1-GrantsTypes updated so that all endpoints are accessible via client credentials grant except for the POST /domestic-payments endpoint

  • Updated v2.0-draft1-ConsentAuthorisation to include "If the consent did not indicate a debtor account, the API Provider presents the Customer a list of accounts from which the Customer may an account or accounts that apply to the consent."

  • Updated v2.0-draft1-ConsentRevocation section updated to reflect new enduring payment consent as a long lived consent type

  • Updated v2.0-draft1-ConsentUpdates section updated to reflect new enduring payment consent as a long lived consent type

Added:

  • Definition of payment-order and payment-order consent in v2.0-draft1-Overview

  • Guidance in v2.0-draft1-Steps for decoupled flow

  • v2.0-draft1-ReleaseManagement section which covers how resources are accessed across versions of the Payment API (based on OBIE v3.1.2 but reworded for clarity, and extended for enduring payment consent)

  • v2.0-draft1-PaymentResources section to describe content of sub-pages

  • v2.0-draft1-ConsentRe-authentication to describe behaviour for long lived vs. short lived payment consents

Removed:

  • Removed "Payments that involve currency exchange.", "payments made in NZD - i.e., payments that are: In bulk - single debit, multiple credit; Future dated or deferred; Recurring." as duplicated statements in v2.0-draft1-OutofScope

  • Idempotency section - which is now in main NZ Banking Data specification page

  • Reference in v2.0-draft1-Endpoints regarding 501 Not Implemented and Conditional endpoints - as duplicated in main NZ Banking Data spec page

  • Optional/Mandatory field in v2.0-draft1-IdentifierFields table

  • References to payment scheme in v2.0-draft1-MerchantFlow and v2.0-draft1-PersontoPersonFlow sections

  • Transaction Status section

  • ISO 20022 mapping to schemes section

v2.0-draft2

Jul 8, 2019 

@Gavin Wong

Updates:

  • References to intent-id to ConsentId

  • Clarified in Step 3 of v2.0-draft2-Steps that the authentication device "may" be distinct from the consumption device

  • Added loop for Step 4 in v2.0-draft2-SequenceDiagram

  • Clarified in v2.0-draft2-ReleaseManagement that "An API Provider must allow an enduring-payment-consent to be used create a domestic-payment in the same version."

  • Renamed Consent Re-authentication to "Re-authorisation" in v2.0-draft2-ConsentRe-authorisation

  • Updated references to "older version" to "lower version" and "newer version" to "higher version" (from Technical Decision 006)

  • Updated v2.0-draft2-ConsentUpdates section to reflect that the debtor account details in the consent object cannot be updated (reflecting Technical Decision 008 to limit enduring payment consent to one debtor account only).

Additions:

  • Added in v2.0-draft2-GrantsTypes section the client credential grant is required to access the debtor-accounts and debtor-account sub-resources

  • in draft2-Scope clarification that "... the API specification is silent on what account types must be accessible" - reflecting Business Decision - 003 - Account Type Scope

Removed:

  • Reference to PSD2

  • Removed "GET /enduring-payment-consents/{ConsentId}/debtor-accounts" endpoint from v2.0-draft2-Endpoints as no longer relevant due to Technical Decision 008 to limit enduring payment consent to one debtor account only.

  • Removed "GET requests to the debtor-accounts sub-resource of an enduring-payment-consent." from v2.0-draft2-GrantsTypes as no longer relevant due to Technical Decision 008.

Errata:

  • Correct "the Customer may an" to "the Customer may select an"

  • Account Information reference updated to Payments

  • Typos

v2.0-draft3

Oct 8, 2019 

@Gavin Wong

Updates:

v2.0-rc2

Dec 23, 2019

@Gavin Wong

Updates:

  • In the Steps - only one debtor account may be selected - as multiple debtor accounts linked to an enduring payment consent has been descoped.

  • In the Steps for the decoupled-flow updated “API Provider may make a callback to the Third Party to provide an access token” to “API Provider may make a callback to the Third Party to notify them of successful authorisation.“

  • Updating references to “resources” to clarify language

  • Updated third_party_client_credential scope to payments based on https://paymentsnz.atlassian.net/wiki/spaces/PaymentsDirectionAPIStandardsDevelopment/pages/97320961

Errata:

  • In the Steps section updated “The API Provider chooses either the redirection flow or a decoupled flow” to “The Third Party chooses either the redirection flow or a decoupled flow”

Overview

This Payment Initiation API Specification describes the flows and payloads for initiating a payment-order using a staged payment-consent.

The API endpoints described here allow a Third Party to:

  • Register an intent to stage a payment-order consent.

  • Subsequently submit a payment-order for processing.

  • Optionally retrieve the status of a payment-order consent or payment-order.

A "payment-order" is defined as "an instruction by a payer or payee to its payment service provider requesting the execution of a payment transaction." This Payment API specification defines a hierarchy of:

  • payment-orders (generic type)

    • domestic-payments

  • payment-order consents (generic type) - a consent to initiate payment-orders

    • domestic-payment-consents

    • enduring-payment-consents

This specification should be read in conjunction with NZ Banking Data API Specification which provides a description of the elements that are common across all the NZ Banking Data APIs.

Document Structure

This document consists of the following parts:

  • Overview: Provides an overview of the scope of the API and the key decisions that contributed to the specification.

  • Basics: The section identifies the resources, operations that are permitted on those resources, and various special cases.

  • Endpoints: Provides the list of endpoints for the API specification. The individual endpoints are documented in separate sections along with the data model that they employ.

  • Security & Access Control: Specifies the means for Third Parties and Customers to authenticate themselves and provide consent.

  • Data Model: Describes the data model for the API payloads.

  • Usage Examples: Examples for normal flows, and alternate flows.

  • Swagger Specifications: Provides links to the swagger specifications for the APIs.

Scope

The APIs in this document allow a Third Party to initiate a single, domestic, electronic credit payment-order made in NZD, using a previously authorised payment-order consent. While this version of the API specification only allows access to NZ BECS identifiable accounts, the API specification is silent on what account types must be accessible.

Out of Scope

This specification does not cater for:

  • Payments that involve currencies other than NZD.

  • Payments that are not single, domestic, electronic credit payments.

  • Payments that require multiple authorisers.

Basics

Overview

The figure below provides a general outline of a payment flow using the Payment APIs.

Overview Diagram

Steps

Step 1: Agree Payment-Order Consent

  • This flow begins with a Customer agreeing a payment-order consent for a Third Party to initiate payment-order(s) on the Customer's behalf. 

  • The consent is between the Customer and the Third Party.

  • The debtor account details may be optionally specified at this stage.

Step 2: Create Payment-Order Consent

  • The Third Party connects to the API Provider that services the Customer's payment account and creates a new payment-order consent.

  • The payment-order consent may either be an enduring-payment-consent or a domestic-payment-consent.

    • An enduring-payment-consent is a long-lived payment-order consent.

    • A domestic-payment-consent is a short-lived payment-order consent.

  • The action informs the API Provider that one of its Customers intends to initiate a payment-order.

  • The API Provider responds with an identifier for the payment-order consent (the ConsentId).

  • This step is carried out by making a POST request to a payment-order consent endpoint.

Step 3: Authorise Consent

  • The Third Party initiates the authorisation flow for the Customer to authorise the consent.

  • The Third Party chooses either the redirection flow or a decoupled flow to authorise the Customer.

    • In a redirection flow:

      • The Third Party redirects the Customer to the API Provider.

      • The redirect includes the ConsentId (generated in Step 2).

      • This allows the API Provider to correlate the payment-order consent that was setup.

      • The API Provider authenticates the Customer.

      • The Customer selects the debtor account at this stage (if not previously specified in Step 1).

      • The Customer authorises the consent with the API Provider. The Customer will only be able to authorise or reject the consent details in its entirety.

      • The API Provider updates the state of the payment-order consent internally to indicate that the consent has been authorised.

      • Once the consent has been authorised, the Customer is redirected back to the Third Party.

    • In a decoupled flow:

      • The decoupled flow is initiated by the Third Party calling a back-channel authorisation request endpoint.

      • The back-channel authorisation request contains a 'hint' that identifies the Customer and the consent to be authorised.

      • The API Provider requests the Customer to authorise consent on an authentication device that may be separate from the consumption device on which the Customer is interacting with the Third Party.

      • The API Provider authenticates the Customer.

      • The Customer selects the debtor account at this stage (if not previously specified in Step 1).

      • The Customer authorises the consent with the API Provider. The Customer will only be able to authorise or reject the consent details in its entirety.

      • The API Provider updates the state of the payment-order consent internally to indicate that the consent has been authorised.

      • Once the consent has been authorised, the API Provider may make a callback to the Third Party to notify them of successful authorisation.

Step 4: Create Payment-Order

  • Once the Customer has authorised the payment-order consent, the Third Party creates a payment-order to indicate the payment-order should be submitted for processing.

  • This is carried out by making a POST request to the appropriate payment-order endpoint.

    • If the Customer has authorised a domestic-payment-consent, the Third Party may create a single domestic-payment

    • If the Customer has authorised an enduring-payment-consent, the Third Party may create multiple domestic-payments depending on the parameters of the enduring-payment-consent

  • The API Provider returns the identifier for the payment-order to the Third Party.

Step 5: Retrieve Status

  • The Third Party may retrieve the status of the payment-order consent (with the ConsentId) or payment-order (with the payment-order identifier) or debtor-account details (with the payment-order identifier).

  • This is carried out by making a GET request to the relevant endpoint.

Sequence Diagram

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 participant Customer participant Third Party participant API Provider Authorisation Server participant API Provider Resource Server note over Customer, API Provider Resource Server Step 1: Agree Payment-Order Consent end note Customer -> Third Party: Agree payment-order consent note over Customer, API Provider Resource Server Step 2: Create Payment-Order Consent end note Third Party <-> API Provider Authorisation Server: Establish TLS 1.2 MA Third Party -> API Provider Authorisation Server: Initiate Client Credentials Grant API Provider Authorisation Server -> Third Party: Return access-token Third Party <-> API Provider Resource Server: Establish TLS 1.2 MA Third Party -> API Provider Resource Server: POST /payment-order-consents note over API Provider Resource Server: Consent Status: AwaitingAuthorisation API Provider Resource Server -> Third Party: HTTP 201 (Created), ConsentId note over Customer, API Provider Resource Server Step 3: Authorise Consent end note alt Redirection (using authorization code grant) Third Party -> Customer: HTTP 302 (Found), Redirect (ConsentId) Customer -> API Provider Authorisation Server: Follow redirect (ConsentId) Customer <-> API Provider Authorisation Server: Authenticate Customer <-> API Provider Authorisation Server: Select debtor account if required Customer <-> API Provider Authorisation Server: Authorise consent note over API Provider Resource Server: Consent Status: Authorised API Provider Authorisation Server -> Customer: HTTP 302 (Found), Redirect (authorization-code) Customer -> Third Party: Follow redirect (authorization-code) Third Party <-> API Provider Authorisation Server: Establish TLS 1.2 MA Third Party -> API Provider Authorisation Server: Exchange authorization-code for access token API Provider Authorisation Server -> Third Party: Return access-token else Decoupled (Using CIBA) Third Party -> API Provider Authorisation Server: POST /bc-authorize (login_hint_token) API Provider Authorisation Server -> Third Party: OK Customer -> API Provider Authorisation Server: Authorise (Consent Id) Customer <-> API Provider Authorisation Server: Authenticate Customer <-> API Provider Authorisation Server: Select debtor accounts if required Customer <-> API Provider Authorisation Server: Authorise consent note over API Provider Resource Server: Consent Status: Authorised alt Using callback API Provider Authorisation Server -> Third Party: Callback (authorization-code) Third Party <-> API Provider Authorisation Server: Establish TLS 1.2 MA Third Party -> API Provider Authorisation Server: Exchange authorization-code for access token API Provider Authorisation Server -> Third Party: Return access-token else Using polling Third Party <-> API Provider Authorisation Server: Establish TLS 1.2 MA Third Party -> API Provider Authorisation Server: Poll at /token using auth-req-id API Provider Authorisation Server -> Third Party: Return access-token end alt end alt note over Customer, API Provider Resource Server Step 4: Create Payment-Order end note Third Party <-> API Provider Resource Server: Establish TLS 1.2 MA Third Party -> API Provider Resource Server: POST /payment-orders note over API Provider Resource Server: Consent Status: Consumed note over API Provider Resource Server: Payment Status: Pending note over API Provider Resource Server: Payment Status: AcceptedSettlementInProcess note over API Provider Resource Server: Payment Status: AcceptedSettlementCompleted API Provider Resource Server -> Third Party: HTTP 201 (Created), Payment-Order Id opt If Customer has authorised a long lived payment-consent loop Third Party <-> API Provider Resource Server: Establish TLS 1.2 MA Third Party -> API Provider Resource Server: POST /payment-orders API Provider Resource Server -> Third Party: HTTP 201 (Created), Payment-Order Id end end note over Customer, API Provider Resource Server Step 5: Retrieve Status end note opt payment-order-consents Third Party <-> API Provider Resource Server: Establish TLS 1.2 MA Third Party -> API Provider Resource Server: GET /payment-order-consents/{ConsentId} API Provider Resource Server -> Third Party: HTTP 200 (OK) payment-order-consent resource end opt opt accounts Third Party <-> API Provider Resource Server: Establish TLS 1.2 MA Third Party -> API Provider Resource Server: GET /payment-order-consents/{ConsentId}/accounts API Provider Resource Server -> Third Party: HTTP 200 (OK) accounts resource end opt opt payment-orders Third Party <-> API Provider Resource Server: Establish TLS 1.2 MA Third Party -> API Provider Resource Server: GET /payment-orders/{PaymentOrderId} API Provider Resource Server -> Third Party: HTTP 200 (OK) payment-order resource end opt opt accounts Third Party <-> API Provider Resource Server: Establish TLS 1.2 MA Third Party -> API Provider Resource Server: GET /payment-orders/{PaymentOrderId}/accounts API Provider Resource Server -> Third Party: HTTP 200 (OK) accounts resource end opt

Restrictions

The specification does not provide a uniform set of restrictions for payment-order support through this API. E.g., the maximum payment amount allowable.

  • An API Provider must determine appropriate restrictions that they support based on their individual practices, standards and limitations. These restrictions must be documented on API Provider developer portals.

  • An API Provider must reject the payment-order consent if the API Provider is unable to handle the request.

  • An API Provider must reject the payment-order if the API Provider is unable to handle the request.

Release Management

This section overviews the release management and versioning strategy for the Payment Initiation APIs.

Enduring-Payment-Consents

POST

  • An API Provider must allow an enduring-payment-consent created on a lower version, to be used to create a payment-order in a higher version.

    • E.g., a ConsentId created in v2, must be allowed be used to create a v3 DomesticPaymentId.

  • An API Provider must allow a token that is bound to a Consent in a lower version, to be used to create a payment-order in a higher version.

    • E.g., a token issued from an authorization code grant using an enduring-payment-consent ConsentId from v2 must be allowed to be used to create a v3 DomesticPaymentId.

  • An API Provider must not allow an enduring-payment-consent created on a higher version, to be used to create a payment-order in a lower version.

    • E.g., a ConsentId created in v2, must not be used to create a v1 PaymentSubmissionId.

GET

  • An API Provider must allow an enduring-payment-consent created on a lower version, to be accessed via a higher version.

    • E.g., a ConsentId created in v2 must be allowed be accessed via v3, as this is a long lived consent.

  • An API Provider must not allow an enduring-payment-consent created on a higher version, to be accessed via a lower version.

    • E.g., a ConsentId created in v3 must not be accessed via v2.

  • An API Provider must ensure the Consent object in an enduring-payment-consent is unchanged when accessed in a different version.

    • E.g., an enduring-payment-consent created in v2 will have the same Consent object when accessed via v2 and v3.

  • An API Provider may allow an expired enduring-payment-consent created on a lower version, to be accessed via a higher version.

    • E.g., an expired ConsentId created in v2 may be accessed via v3.

DELETE

  • An API Provider must not allow an enduring-payment-consent created in a higher version, to be deleted in a lower version.

    • E.g., a ConsentId created in v3 must not allowed to be deleted via v2.

  • An API Provider must allow an enduring-payment-consent created in a lower version, to be deleted in a higher version.

    • E.g., a ConsentId created in v1 must be allowed to be deleted via v2.

Domestic-Payment-Consents

POST

  • An API Provider must not allow a domestic-payment-consent created on a lower version, to be used to create a payment-order in a higher version.

    • E.g., a PaymentId created in v1, must not be used to create a v2 DomesticPaymentId

  • An API Provider must not allow a domestic-payment-consent created on a higher version, to be used to create a payment-order in a lower version.

    • E.g., a ConsentId created in v2, must not be used to create a v1 PaymentSubmissionId

GET

  • An API Provider may allow a domestic-payment-consent created on a lower version, to be accessed via a higher version.

    • E.g., a PaymentId created in v1 may be allowed to be accessed via v2, as this is a short-lived consent.

  • An API Provider must not allow a domestic-payment-consent created on a higher version, to be accessed via a lower version.

    • E.g., a ConsentId created in v2 must not be accessed via a v1 PaymentId.

Domestic-Payments

POST

  • An API Provider must only allow a domestic-payment-consent to be used create a domestic-payment in the same version.

    • E.g., a ConsentId created in v3 must only be used to create a domestic-payment in v3.

  • An API Provider must allow an enduring-payment-consent to be used create a domestic-payment in the same version.

    • E.g., a ConsentId created in v3 must be allowed to be used to create a domestic-payment in v3.

  • An API Provider must allow an enduring-payment-consent created on a lower version, to be used to create a domestic-payment in a higher version.

    • E.g., a ConsentId created in v3 must be allowed to be used to create a domestic-payment in v4.

  • An API Provider must not allow an enduring-payment-consent created on a higher version, to be used to create a domestic-payment in a lower version.

    • E.g., a ConsentId created in v4 must not be allowed to be used to create a domestic-payment in v3.

GET

  • An API Provider must allow a domestic-payment created on a lower version, to be accessed via a higher version. Retention will depend on an API Provider's legal requirement for data retention. In the case where a payment-order type is the same, but the structure has changed in a higher version, sensible defaults must be used, with the API Provider's developer portal clearly specifying the behaviour.

    • E.g., a PaymentSubmissionId created in v1, must be accessible as a v2 domestic-payment (e.g., if an API Provider must make payment-orders available for 7 years).

    • E.g., a new field StatusUpdateDateTime was introduced in v2, an API Provider must populate this with the last status update time (as the StatusUpdateDateTime is a mandatory field).

  • An API Provider must not allow a domestic-payment created on a higher version, to be accessed via a lower version.

    • E.g., a DomesticPaymentId created in v2 must not be allowed to be accessed via the v1 payment-submissions endpoint.

  • An API Provider must document the behaviour on the accessibility of a payment-order in a higher version on the API Provider's developer portal.

Endpoints

This section looks at the list of available API endpoints for Payments and optionality.

  • The API Provider must implement the API endpoints in the table below that are marked as mandatory.

  • The API Provider may optionally implement the API endpoints that are marked as non-mandatory.

Endpoint design considerations:

  • Having a separate resource for the payment-order consent and payment-order means we can extend the flows in the future. 

  • Separation in the payment-order consent and the payment-order also allows for cleaner separation in updating the status of resources.

Document Section

Resource

Endpoint

Mandatory ?

Document Section

Resource

Endpoint

Mandatory ?

Enduring Payment Consents

enduring-payment-consents

POST /enduring-payment-consents

Optional

Enduring Payment Consents

enduring-payment-consents

GET /enduring-payment-consents/{ConsentId}

Optional

Enduring Payment Consents

enduring-payment-consents

DELETE /enduring-payment-consents/{ConsentId}

Optional

Domestic Payment Consents

domestic-payment-consents

POST /domestic-payment-consents

Mandatory

Domestic Payment Consents

domestic-payment-consents

GET /domestic-payment-consents/{ConsentId}

Mandatory

Domestic Payments

domestic-payments

POST /domestic-payments

Mandatory

Domestic Payments

domestic-payments

GET /domestic-payments/{DomesticPaymentId}

Mandatory

Domestic Payments

debtor-account

GET /domestic-payments/{DomesticPaymentId}/debtor-account

Mandatory

Payment Resources

Each of the high level resources are documented in sub-pages of the Payment API specification with these sections:

  • Definition

  • Endpoints

  • Data Model

    • UML diagram

    • Data dictionary

  • Usage Examples

Security & Access Control

Scopes

The access tokens required for accessing the Payment APIs must have one of the following scopes:

Scopes
1 payments

Grants Types

Third Parties must use a client credentials grant to obtain a token with the scope payments to make:

  • POST requests to the enduring-payment-consents resource.

  • GET requests to the enduring-payment-consents resource.

  • DELETE requests to the enduring-payment-consents resource.

  • POST requests to the domestic-payment-consents resource.

  • GET requests to the domestic-payment-consents resource.

  • GET requests to the domestic-payments resource. 

  • GET requests to the debtor-account sub-resource of a domestic-payment.

Third Parties must use an authorisation flow using a redirect flow or decoupled flow to obtain a token with the scope payments to make:

  • POST requests to the domestic-payments resource.

consent authorisation is used to define the fine-grained scope that is granted by the Customer to the Third Party.

The Third Party must begin a single electronic credit payment request by creating a payment-order consent through a POST operation. This consent contains the consent that the Third Party claims it has been given by the Customer. At this stage, the consent is not yet authorised as the API Provider has not yet verified this claim with the Customer.

The API Provider responds with a ConsentId. This is the ConsentId that is used when initiating the authorisation flow (as described in the NZ Banking Data Security Profile).

As part of the authorisation flow:

  • The API Provider authenticates the Customer.

  • The API Provider plays back the consent (registered by the Third Party) back to the Customer - to get consent authorisation.

    • If the consent did not indicate a debtor account, the API Provider presents the Customer a list of accounts from which the Customer may select an account or accounts that apply to the consent.

  • The Customer may accept or reject the consent in its entirety (but not selectively).

Once these steps are complete, the consent is considered to have been authorised by the Customer.

An API Provider may allow a Customer to re-authorise an enduring-payment-consent (as it is a long-lived consent) if:

  • The enduring-payment-consent has a status of Authorised; and 

  • The ToDateTime of the enduring-payment-consent has not elapsed.

An API Provider must not allow a Customer to re-authorise a domestic payment consent (as it is a short-lived consent).

An API Provider must not allow a Customer to revoke a short-lived (a domestic-payment-consent) payment-order consent once it has been authorised.

An API Provider must allow a Customer to revoke a long-lived (an enduring-payment-consent) payment-order consent:

  • If the payment-order consent is valid and has not expired

A design principle for NZ Banking Data APIs is that consent must not be changed once the consent has been authorised.

An API Provider must not allow a Customer to update the parameters of a short-lived (a domestic-payment-consent) payment-order consent once it has been authorised. This includes debtor account details.

An API Provider must not allow a Customer to update the parameters of a long-lived (an enduring-payment-consent) payment-order consent. This includes debtor account details.

Data Model

Identifier Fields

This section describes the identifiers used through the Payment API flows - the direction of flow through the system, and how they are used.

The standard definitions for the elements in the API payloads are described in the Data Model section for each resource. However, this table gives further detail on the business meaning, and how they are used.

Identifier

Generated

Business Description

Identifier

Generated

Business Description

EndToEndIdentification

Third Party (or Merchant)

The EndToEndIdentification reference is a reference that can be populated by the debtor (or merchant in the ecommerce space). This reference is important to the debtor (could be an internal reference Id against the transaction), it is NOT the reference information that will be primarily populated on the statement of the creditor (beneficiary).

InstructionIdentification

Third Party (or Merchant)

Third Party generates the InstructionIdentification which is a unique transaction Id and passes it to the API Provider (this is mandatory), but this doesn’t have to go any further in the payment flow. The flow of this identifier needs to align with payment scheme rules.The expectation is that this is unique indefinitely across all time periods. The Third Party can ensure this is indefinitely unique by including a date or date time element to the field, or by inserting a unique Id.

RemittanceInformation

Third Party (or Merchant)

RemittanceInformation contains Particulars, Code and Reference for both Debtor and Creditor, along with names for both parties. This information is populated by the Third Party in the payment-order consent and payment-order.

ConsentId

API Provider

Unique identification as assigned by the API Provider to uniquely identify the payment-order consent resource.

Payment-Order Id

API Provider

Unique identification as assigned by the API Provider to uniquely identify the payment-order resource.

The tables below identify the actor that initially creates each of the message identifiers and their transmission and visibility to other actors.

These flows are indicative - and will be dependent on what payment schemes or agencies are able to support.

Key

O indicates the actor that creates the identifier.

=> downstream direction of flow

<= upstream direction of flow

Merchant Flow

Identifier

Customer

Merchant

Third Party

API Provider

Beneficiary

Identifier

Customer

Merchant

Third Party

API Provider

Beneficiary

EndToEndIdentification



O

=>

=>

=>

RemittanceInformation



O

=>

=>

=>

InstructionIdentification





O

=>



ConsentId





<=

O



Payment-Order Id





<=

O



Person to Person Flow

Identifier

Customer

Merchant

Third Party

API Provider

Beneficiary

Identifier

Customer

Merchant

Third Party

API Provider

Beneficiary

EndToEndIdentification





O

=>

=>

RemittanceInformation

O



=>

=>

=>

InstructionIdentification





O

=>



ConsentId





<=

O



Payment-Order Id





<=

O



Enumerations

Common Enumerations

This section gives the definitions for enumerations shared by the Payment API resources.

Code Class

Name 

Definition 

Code Class

Name 

Definition 

OBExternalAccountIdentification2Code

BECSElectronicCredit

An identifier used to uniquely identify the account of a customer at a financial institution, structured in the form of 12-1234-1234567-12 where:

  • the first two digits are the bank number, which tells us which bank the account resides with;

  • the next four digits indicate the branch number, which tells us which branch of that bank the account is domiciled;  

  • the next seven digits indicate the account number; and

  • the last two digits indicate the account number suffix.

Alternative and Error Flows

Idempotent Behaviour

In this scenario a failure has meant the Third Party needs to retry creating a payment-order consent, and does so with the same idempotency key.

This has been generalised for all payment-order consents.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 participant "Customer" as Cx participant "Third Party" as 3P participant "API Provider\nAuthorisation Server" as APIProviderAS participant "API Provider\nResource Server" as APIProviderRS note over Cx, APIProviderRS Step 2: Setup payment-order consent end note 3P <-> APIProviderAS: Establish TLS 1.2 MA 3P -> APIProviderAS: Initiate Client Credentials Grant APIProviderAS -> 3P: Return access-token 3P <-> APIProviderRS: Establish TLS 1.2 MA 3P -> APIProviderRS: POST /payment-order-consents (x-idempotency-key={third-party-guid-1}) APIProviderRS -> APIProviderRS: Create new resource (ConsentId=1001) alt unexpected failure 3P -> APIProviderRS: POST /payment-order-consents (x-idempotency-key={third-party-guid-1}) note right of APIProviderRS The resource server recognises that this is the same request as earlier. A new resource is not created. The ConsentId remains the same (e.g. 1001) as above. The status of the resource may be different if it has changed. This operation can be retried multiple times if required. end note end APIProviderRS -> 3P: HTTP 201 (Created), ConsentId=1001 3P -> Cx: Redirect (ConsentId}

Create Payment Order

In this scenario a failure has meant the Third Party needs to retry creating a payment-order, and does so with the same idempotency key.

This has been generalised for all payment-orders.



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 participant "Customer" as Cx participant "Third Party" as 3P participant "API Provider\nAuthorisation Server" as APIProviderAS participant "API Provider\nResource Server" as APIProviderRS note over Cx, APIProviderRS Step 4: Create payment-order end note 3P <-> APIProviderRS: Establish TLS 1.2 MA 3P -> APIProviderRS: POST /payment-orders ConsentId = 1001, x-idempotency-key={third-party-guid-2} alt Third Party attempts to POST to /payment-orders with same ConsentId 3P -> APIProviderRS: POST /payment-orders ConsentId = 1001, x-idempotency-key={third-party-guid-2} APIProviderRS -> 3P: HTTP 201 (Created), PaymentOrderId note right of APIProviderRS The resource server recognises that this is the same request as earlier. A new resource is not created. The PaymentOrderId remains the same as above. The status of the resource May be different if it has changed. If the status of the resource has changed, the API Provider will return the up to date status. The operation can be retried multiple times if required. end note end

Swagger Specifications

The Swagger Specification for the Payments Initiation APIs can be downloaded from the Payments NZ API Centre GitHub repo:

https://github.com/PaymentsNZ/API-Payments-Initiation/tree/master/dist/v2.0.0