Payment status flow
The payment status represents the current state of the payment initiation process, providing detailed information about its progress. For example, the status might indicate that the payment is COMPLETED, DELAYED_AT_BANK, or another state.
The payment status is included in the payment object of every response from the Volt system during the initiation flow, specifically in API responses related to the /payments
endpoint.
{
//...
"status": "NEW_PAYMENT",
//...
}
This diagram shows the flow of a payment through the various statuses of its lifecycle.
Status meanings
Our statuses and what they mean, and whether you’ll receive a notification (webhook) when a payment transitions to that status.
Status code | Description | Notification |
---|---|---|
REFUSED_BY_RISK | Our fraud tool, Circuit Breaker, has analysed the transaction and decided not to sent to the bank for completion. | Yes |
APPROVED_BY_RISK | Circuit Breaker approved the transaction and sent it to the bank. | No |
BANK_REDIRECT | The user was redirected to the bank after submitting the payment on Volt hosted checkout page. | Yes |
ADDITIONAL_AUTHORIZATION_REQUIRED | Additional authorisation is required to be performed by the user. This is common with business accounts where more than one person must authorise a payment. |
No |
AUTHORISED_BY_USER | The payer returned from the bank, having successfully authorised the transaction. |
No |
AWAITING_CHECKOUT_AUTHORIZATION | This status is applicable to banks that require an embedded flow. It indicates that the user has entered their login credentials on Volt’s checkout page and is currently at a stage preceding either the selection of the SCA method or the input of the SCA code, assuming there is only one SCA method available. |
Yes |
REFUSED_BY_BANK | The bank has refused the payment initiation (this can happen is some cases due to insufficient funds). | Yes |
ERROR_AT_BANK | Whenever we receive an ‘error’ status we investigate with our partner network / banks directly but we do not provide here the exact reason for the error. | Yes |
DELAYED_AT_BANK | The bank is still processing the transaction and there is no outcome yet; the transaction can end up either approved or declined. | Yes |
COMPLETED | The payment has been instructed and accepted by customer’s bank; this does not guarantee receipt of funds as banks could cancel payments after the instruction stage. | Yes |
NOT_RECEIVED | If the payment was confirmed on the bank but funds have not arrived within certain number of processing days Volt updates the status to NOT_RECEIVED. | Yes |
RECEIVED | Funds have arrived (applicable only for merchants using Volt’s Connect solution). | Yes |
FAILED | The payment request could not be completed due to technical limitations in the banking network. | Yes |
CANCELLED_BY_USER | The payer clicked on “cancel” during the payment initiation process. | Yes |
ABANDONED_BY_USER |
The payment was abandoned by the payer. This status is updated automatically when a payment has been in the status NEW_PAYMENT or BANK_REDIRECT for more than 30 minutes. The 30 minute timer starts from the status of NEW_PAYMENT, meaning that if a payer takes 25 minutes to go from NEW_PAYMENT to BANK_REDIRECT then they have 5 minutes to authorise the payment before the payment is marked as ABANDONED_BY_USER and the payment will no longer be able to be completed. Note, there are exceptions where the payment may take slightly longer than 30 minutes to be updated in our system due to volume throughput. This means that some payments may be updated at to ABANDONED_BY_USER at 37 minutes for example. Therefore, please do not build any logic assuming that payments will update to ABANDONED_BY_USER exactly at 30 minutes after NEW_PAYMENT. |
Yes |
SETTLED | The funds have been transferred from the Volt Connect virtual IBAN to the merchant’s regular settlement bank account. This status applies only to merchants utilising the Volt Connect solution, when the Volt Connect partner supports a settlement model. | No |
Exceptions to the flow
Banks can return statuses outside of the normal flows described above. We suggest you handle these specific exceptions when you process payments.
Abandoned payments are actually received
Transition from ABANDONED_BY_USER
to COMPLETED
or RECEIVED
The payment was labelled as abandoned but is ultimately received. It can occur when the payer approved the payment but, for some reason, their session was interrupted and they didn’t return back to the merchant. Because the payment was approved, the funds were actually sent and subsequently received into your cash management account. We are only able to inform you about this transition if you have Connect cash management account.
Completed initiation was then cancelled
This will occur where the payer has completed the approval process at their bank and has returned to the merchant. They then have a change of mind and cancel the payment with their bank, before the funds have left their account. This will usually only happen with payments that aren’t initiated as instant.
Here, the status will change from COMPLETED
to CANCELLED_BY_USER
Australia-Specific Flow
Please note that for Australia, the flow might be slightly different in some transitions due to not integrating directly with banks but with the PayTo payment provider. For more details, please refer to the Australian payment status flow.
- On this page
- Payment status flow
- Exceptions to the flow