Enduring Payments
This guide is relevant for customers of our enduring payments API. If you would like information about making one-off payments using official open banking APIs, you can find our one-off payment API reference docs here or contact us at [email protected].
This guide includes information about transitioning to official open banking connections for developers that currently use Akahu enduring payment consents backed by classic connections.
Akahu is aiming to migrate all connectivity to official open banking connections (for banks that have an open banking API) by March 31st 2026. Once migration is complete, we will be removing support for classic connections to those banks.
We've had to make some changes to our payments service in order to support official open banking APIs. You can find a description of some of the new constraints imposed by these APIs in our Feature Support > Payments guide.
Payee bank accounts
Due to the removal of our pay-anyone consent functionality, it is now a requirement for all payee bank accounts for an enduring payment consent to be provided at the time of user consent.
For most Akahu customers, your payee bank accounts will already be configured against your application. You can check this by verifying the bank account numbers listed under the Payment Initiation section of the Akahu consent screen for your app. If you do not see any bank account numbers listed in this section, this means that you are currently relying on a pay-anyone consent, which Akahu can no longer support. Please find our communication from November 12th 2025 in your email inbox for guidance on this matter.
Until now, any restrictions on payee bank accounts have been managed by Akahu. This means that in certain exceptional circumstances it has been possible to retroactively modify the payee bank accounts attached to existing user consents. When using official open banking APIs, the payee list is managed by the user's bank, so retroactive updates will no longer be possible. This means that it's crucial that any bank accounts that you wish to make payments to, now or in the future, are included in your configuration. If these need to be updated in the future it will require each user to manually authorise an updated payment consent with their bank.
Action required: Confirm the full list of payee bank accounts that you want configured for your application.
Variable payee accounts: Our first release to support enduring payment consents via official open banking APIs requires a fixed list of payee accounts that are configured against your application. We recognise that there are some use cases that require different payee accounts for each user. We plan to introduce features to support this at a later date.
Per-account payment consents
Once official open banking connections are enabled for your application, an enduring payment consent will need to be granted by the user on a per-account basis.
This is a new process that requires the user to complete two distinct steps within Akahu's authorisation flow:
Step 1: The user will authenticate with their bank and select one or more accounts to share with your application. This step allows your application to access basic details for each account such as the account name, account number, balance, and any other information included in the scope of your request.
Step 2: Akahu will prompt the user to grant payments access to one or more of the accounts they shared in the previous step. For connections made using official open banking APIs, the user must authorise a separate consent with their bank for each account that they want to grant payment initiation for.
At the end of this process, the user will have shared data from one or more accounts to your application (step 1). They will have also granted payments access to zero, one, or many of those accounts (step 2). Akahu will actively encourage the user to grant payments access to at least one account, however the choice ultimately lies with them.
Identifying accounts that can be used for payments
Due to the introduction of per-account payment consents (described in the previous section). It will now be possible (likely, even) for users to connect accounts to your application which do not include a payment consent. Depending on your Akahu app configuration, this may not have been possible previously.
Because of this change, it is important that you update your application with the capability to identify which accounts the user has granted payments access to. Attempting to initiate payments from accounts without payment capabilities will result in a 403 error response from the POST /v1/payments API endpoint.
When this new per-account payment consent behaviour is enabled for your application, an additional payment_consents data element will become available on each account returned from our accounts API endpoint. This element contains an array describing the payment consents available for initiating payments from this account. If the user has not granted payments access for an account, this array will be empty.
{
"_id": "acc_xxxxxxxxxxxxxxxx",
// ...
"payment_consents": [
{
"single_limit": 1000,
"periodic_limit": {
"amount": 5000,
"frequency": "DAILY"
},
"payees": [
{
"name": "Frodo Baggins",
"account_number": "12-1234-1234567-12"
},
{
"name": "Gandalf the Grey",
"account_number": "12-1234-7654321-00"
},
]
}
]
}Action required: Update your application code to identify which of the user's connected accounts can be used to initiate payments. You may wish to revise certain elements of your UI/UX accordingly.
Payment limits
As described in our Feature Support > Payments guide, every enduring payment consent must now include both a single-payment limit and periodic (e.g. daily) limit.
Before official connections can be enabled for your application, you will need to provide Akahu with the limits that you want to be applied to your enduring payment consents.
Due to the variability in the limits that can be requested at each bank, we suggest that you provide Akahu with "aspirational" values for these limits. If necessary, we will then downlevel these limits to fit the constraints of the user's bank. This means that a payment consent granted by one of your users may have limits lower than you've requested.
To determine the actual limits available to your application for a given account, inspect the payment_consents value attached to the account as described in Identifying accounts that can be used for payments.
As with the list of allowed payees, the limits of an enduring payment consent cannot be modified retroactively. Updating of consent limits requires that the user authorises a new consent with their bank.
Action required: Provide Akahu with the single payment and periodic (e.g. daily) limits that you want applied to enduring payment consents requested by your application.
Variable payment limits: Our first release to support enduring payment consents via official open banking APIs requires that fixed payment limits are configured against your application. We recognise that there are some use cases that would benefit from customised payment limits per user. We plan to introduce features to support this at a later date.
Updated 3 days ago