| | | |
|---|
v1.0.0 | Mar 1, 2019 | Payments NZ API Working Group | Baseline Payment Initiation specification. |
v2.0.0-draft1 | May 21, 2019 | @Gavin Wong (Unlicensed) | 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 (Unlicensed) | 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: |
v2.0-draft3 | Oct 8, 2019 | @Gavin Wong (Unlicensed) | Updates: |
v2.0-rc2 | Dec 23, 2019 | @Gavin Wong (Unlicensed) | 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 Technical Decision - 021 - OAuth Scopes in API Standard
Errata: |
v2.0.0 | Mar 31, 2020 | @Gavin Wong (Unlicensed) | No updates |
v2.0.1 | Jul 17, 2020 | @Gavin Wong (Unlicensed) | Patch update to Swagger specification to include documented query parameters. |
v2.0.2 | Nov 5, 2022 | @Nigel Somerfield | Patch update to Swagger specification to BECSRemittance - DebtorReference and CreditorReference - specify additionalProperties: false |
