A customer authorises a payment in their banking app, returns to your website and sees a spinner. Your support team sees an order awaiting payment. The bank may have progressed the request, but the customer cannot tell whether to try again. This is where an open-banking integration becomes a business process rather than an API demonstration.
For a New Zealand software buyer, the immediate purchasing question is who owns the journey when consent, payment execution and the order disagree. The answer must be visible in the application and in the support agreement. A successful bank redirect is only one part of that journey.
A governance change is a reason to verify assumptions
Payments NZ announced that its API Centre ceased operating on 30 September 2026. The same announcement says open banking continues under the regulatory framework led by MBIE, with the future approach to standards management and support functions being worked through. The closure does not mean bank APIs have stopped operating.
It does mean an implementation brief should identify the applicable standards, current onboarding route, provider agreements and support contacts instead of copying an old checklist. Verify these with each intended provider and the relevant current framework. Do not promise a go-live date on the strength of a historical sandbox registration alone.
The API Centre's published standards overview covers payment initiation, account information, event notifications and supporting operational standards. These are useful architectural references. They are not evidence that every bank supports every optional capability in the same production environment.
Write a capability sheet for each connection
Before estimating a connector, list the exact customer journey you intend to offer. Is it a one-off payment, an account-information connection or an enduring payment arrangement? Which accounts and customer types are supported? Does the provider return status by polling, notification or both? What happens when a customer needs additional authorisation?
Record the API version, authentication flow, supported consent parameters, operational contact and evidence from a provider test. Keep the sheet under change control. A capability marked assumed should not quietly become a product requirement marked complete.
This is particularly valuable when working through an intermediary. An intermediary can simplify connectivity, but the merchant still needs to know which promises it can safely make to a customer. Ask which failures the provider handles and which arrive in your own support queue. Price the latter as software and operational work.
Consent and a payment are separate records
The published payment-initiation specification distinguishes payment consent from payment creation and describes enduring consent within approved parameters. Use the provider's currently agreed version for implementation; do not assume this particular reference is the latest version required for a new connection.
In your product, retain a consent identifier, the scope presented to the customer, the authorisation result and the relevant lifecycle events. Link payments to the consent that permitted them. Cancelling a customer subscription, revoking consent and refunding an already executed payment are different operations, even when the customer expects one button to start the overall process.
Design that button around an explicit explanation. Tell the customer what will stop now, which activity may already be in progress and how they can see the final outcome. Use authoritative provider status where available. An internal flag saying cancelled cannot establish what an external system has already done.
Give uncertainty its own screen
Consider an illustrative membership platform. The user approves a payment, the return connection fails and the website never receives the expected confirmation. A weak integration shows a red failure and invites another payment. A stronger one says it is checking the existing attempt and supplies a reference that support can find.
Create a durable payment attempt before directing the customer elsewhere. On return, recover that attempt rather than creating a new one from the browser session. Apply the provider's retry and idempotency requirements. When the response is ambiguous, reconcile with the provider before initiating a fresh business action.
The support screen should show when the attempt started, which provider handled it, the last authoritative status and what is safe to do next. Restrict sensitive account information and never log banking credentials. A support employee usually needs a useful state and reference, not a copy of every raw payload.
Test what happens after the customer leaves
The happy path is necessary but insufficient. Test a customer closing the browser, revoking consent through their bank, changing the underlying subscription and returning with an expired link. Test a delayed notification after a staff member has already opened the case. Confirm that the software does not interpret an older status as permission to overwrite a later outcome.
For account-data integrations, also specify what changes when permission ends. Separate stopping future access from handling data already received under your retention and contractual requirements. Make the responsible owner's decision explicit rather than letting an integration engineer invent policy inside a background job.
Your acceptance evidence should connect the customer view, order record, provider status and support action. If those views cannot be explained together during a test, the production team will inherit the ambiguity.
Buy a recoverable slice of the journey
A practical first release is one provider and one payment use case with clear reconciliation. Include customer messaging, consent history, a support queue, a repeatable test suite and an operational handover. Adding several banks before these work can multiply the number of uncertain states instead of increasing useful coverage.
Ask for a dependency list identifying access approvals, certificates, provider availability and decisions your team must make. Agree how API changes are monitored and who maintains the capability sheets after launch. These details make a quote comparable and prevent onboarding responsibilities from disappearing between organisations.
Our CRM and ERP integration scope guide helps define system boundaries, while the software handover guide covers operational ownership. Through custom software development, TuniCyberLabs can connect bank-facing integration to your order and support processes. Discuss a New Zealand open-banking workflow with the intended provider, customer journey and the point where your team currently loses certainty.