Versions Compared

Version Old Version 6 New Version 7
Changes made by

Gavin Wong (Unlicensed)

Matthew Bell

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Contributor

Category

Feedback

Response

Will Maio - Miao (Deactivated)

Paymark

Payments Initiation API

Addition of refund API links to the Payment initiation V2.0 release candidate:

  • Being able to offer real time refund on transactions initiated by API links is a key requirement for merchants to keep the admin cost down, and for customers to have a streamlined payment experience.

  • For some retailers, not being able to refund means they will have to set the customer up as a “supplier” in the system, resulting in weeks of delay and a huge amount of admin effort.

Refunds are not currently an agreed part of the scope for v2.0:
/wiki/spaces/ACSC/pages/49283242

It should be noted that in the v2.0 standard - Third Parties are be able to initiate a refund to a Customer via these steps:

  • Requesting the DebtorAccountRelease as part of the Customer's original payment-consent (to identify the Customer's bank account details)

  • Agreeing a new payment-consent for the Merchant with the Third Party - to pay the Customer

  • A Merchant's payment-consent may be an enduring-payment-consent - which would mean that under agreed parameters, the Merchant would only need to authorise this refund payment-consent once.

  • Third Party initiating a payment-order with the Merchant's Bank to refund the Customer

Note that the existing v2.0 (and v1.0) standards rely on push payments initiated by the Customer's Bank. If we were to re-utilise the push payments system for refunds - then a refund must be initiated by the Merchant's Bank.

Your feedback on future functionality will be incorporated into the discussions informing the scope for pipeline activities.

David Mitchell - (Unlicensed)

BNZ

Account types

We would like to see what it would take to loosen the limitation of the accounts to only BECS identifiable accounts to include scheme card formats

Limiting the types of transactions / accounts to be able to be queried to non credit card accounts may make the Transactions API less useful as a large portion of customers to their primary transactional banking from their credit card (mainly because of things like paywave and loyalty schemes).

Hi David Mitchell (Unlicensed)

We raised this as a business decision /wiki/spaces/PaymentsDirectionAPIStandardsDevelopment/pages/22282274 - and the Business Working Group made a decision (Option 1) for v2.0 to continue with the approach taken from v1.0:

  • Only BECS identifiable accounts

  • No clarification of what account types are in scope - i.e., some API Providers will only implement current accounts, some API Providers may also implement savings accounts, some API Providers may only implement some current accounts

As this was the business decision - we have reflected this in the technical specifications.

This will be fed back to the business group for the scope for pipeline activities.

Gavin Wong (Unlicensed)

Payments NZ

Errata

Errata:

  • In both the Account Information and Payments Basics/Steps section - clarify “Once the consent has been authorised, the API Provider may make a callback to the Third Party to provide an access token.” - as the push method has been de-scoped by the FAPI working group.

  • In the Payments Initiation Basic/Steps section - update “The Customer selects the debtor account(s) at this stage (if not previously specified in Step 1)." to reflect only one debtor-account may be selected. Linking multiple debtor accounts to an enduring payment consent has been de-scoped from v2.0.

  • In the Payments Initiation Basic/Steps section - update wording for clarity from “may only create multiple” to “may create multiple”

Chris Barton

Xero

DevelopmentPipeline

Payments API - future standards:

  • V2 standards appear more suitable for consumer application

  • For business payments the addition of Batch, Multi-Auth, Enduring Consent and feasible transaction limits will be required to encourage uptake from Xero or its partners

  • Batch - users should be able to provide one authorisation for the batch payment rather than authorise individual payments

  • Enduring consent - needs to be extended to advisors / administrators to prepare payment files, with decoupled flow enabling authorised signatories to authorise payment

  • Multi-authorisation - needs to enable advisors / administrators and account signatories to prepare and approve payments

  • Transaction limits - need to be sufficient to support SMB’s end of month batch payments

Account Information API

  • A unique transaction ID should be included

  • Enduring consent should extend to account information with the same flexibility around administrators / signatories

  • Should include credit card accounts

Bills API

  • Should not include a bills API as this should be covered by Peppol / E-invoicing standards. We have some reservations about the API Centre being used to set standards for non API Providers. This seems out of scope of the API Centre's mandate.

Hi Chris Barton, Thank you for providing your thoughts and feedback on what you consider to be the high priority areas for future state standards development.

We will be incorporating all feedback received on the pipeline, through the Business and Technical working group(s) and relevant governance processes following the consultation period.