Page Comparison

Will Maio - 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 - 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).To be confirmed

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.