Bank Transfer transactions transition through various payment statuses and in some cases a payment may move to a status from which users are unable to complete their payment. This may happen, for example, where users:
- Discover that they have insufficient funds on a specific account (and want to choose an account that’s held in another bank).
- Lose their Internet connection before approving the payment.
- Have a mobile device that runs out of battery during the payment.
- Etc.
In these cases it is possible to retry the payment, provided:
- The retry is attempted before the payment’s timeout period is exceeded.
- The payment is in an appropriate status, which allows for a retry.
Retries are possible for payments that are in specific statuses, as summarised in the table below:
Payment Status | Can be Retried? |
PENDING |
Yes |
PENDING_APPROVAL |
Yes |
DECLINED |
Yes |
SETTLEMENT_REJECTED |
Yes |
CONSENT_API_REJECTED |
Yes |
UNEXPECTED_ERROR |
Yes |
UNKNOWN |
No |
SETTLEMENT_COMPLETE |
No |
PAYMENT_RECEIVED |
No |
TIMEOUT |
No |
AUTHORISED |
No |
SETTLEMENT_PENDING |
No |
SETTLEMENT_IN_PROGRESS |
No |
OAUTH_CALLBACK_COMPLETE |
No |
CONSENT_TIMEOUT |
No |
For more information on these payment statuses, see Payment Statuses.
Configuring the Retry Functionality
Some clients find the default retry behaviour problematic. Webhooks notify clients about changes in payment status; when a failed payment is automatically retried, it can trigger a sequence of webhook events—such as PaymentRejected
followed by PaymentCompleted
. This can be unexpected for some clients, who may prefer to handle retries themselves by starting a brand new payment process.
If you’d prefer not to allow customers to retry failed payments, you can turn off this feature in the Nuapay Console:
- Log in to the Nuapay Console.
- Go to Products > Open Banking PIS.
- Clear the Allow Failed Payments Retry option.
Please note:
- This setting is enabled by default (true), which means failed payments can be retried unless you change it.
- If you disable retries, the Retry Payment option will no longer be visible to end users (PSUs) once a payment reaches a final status.
CHECKOUT & REDIRECT Integrations
The PSU interaction is similar for both the CHECKOUT
and REDIRECT
integrations, where a payment retry is possible.
To illustrate the end user’s experience, take the following example:
- The PSU selects to pay via Bank Transfer.
- The user selects a bank and is redirected.
- When reviewing the payment, the PSU decides to cancel before authorising the payment (he/she realises that there are insufficient funds on the account for example).
- The PSU is redirected to the Nuapay TPP Fail/Cancel screen, with an option to try again:
- Once the user clicks Try Again, he/she is redirected to the Bank Selection screen (allowing the user to select another bank).
SELF-HOSTED Integrations
For SELF-HOSTED
and SELF-HOSTED-CALLBACK
integrations, merchants/partners will need to programmatically design how they want retries to be handled.
To manage a retry for a given paymentId:
- Call the Retry Payment API (Retry Payment).
- Pass the
paymentId
of the payment that will be retried. - The
bankId
is also required - this will be the ASPSP at which the PSU will approve the retried payment.
See Retry Payment for more details on this service.