Statuses
This page describes the status values returned for Pay by Bank one-off payments, VRP mandates, and VRP payments.
When you receive a webhook from Acquired the JSON payload will contain a status field which tells you about the current state of the payment or mandate. For one-off payments, the status field is also present when Acquired delivers a form POST to your redirect_url.
The mandate and VRP payment statuses below apply to both Sweeping and Commercial VRP.
Settlement and the settled status
settled statusPay by Bank funds settle into an Acquired ledger, and payments move from executed to settled within the Acquired platform. Acquired then batch settles to your external bank account each working day.
If your account is configured to settle externally rather than into an Acquired ledger, Acquired has no visibility of the receiving account. The final status in that case is executed, and no settled webhook is sent.
One-off payment statuses
| Status | Description |
|---|---|
cancelled | The customer did not provide consent for the payment, selecting to reject it. |
declined | The payment request was declined by the bank, or the customer failed to authenticate. |
error | The payment failed due to a technical issue (see detail below). |
expired | The payment was abandoned by the customer (see detail below). |
executed | The payment request has been executed by the bank. If funds are settling outside of an Acquired ledger, the final payment status will remain at executed. |
settled | The payment has been received into your Acquired settlement account. This status only applies to merchants using Acquired-held accounts. |
Error status
An error status indicates the payment failed due to a technical issue, either at the originating bank or on the Faster Payments network.
Expired status
Customers have 10 minutes to authorise a payment after selecting their bank. If they do not complete authorisation within this window (for example they abandon the flow, encounter a redirect error, or fail authentication at their bank), the payment resolves to expired.
VRP Mandate statuses
The following statuses apply to VRP mandates, which govern the authorisation a customer grants for recurring Open Banking payments.
| Status | Description |
|---|---|
pending | The mandate has been created and is awaiting customer authorisation. |
active | The customer has authorised the mandate. Payments can now be collected within the agreed limits. |
cancelled | The mandate has been cancelled, by the customer, either directly from their banking app or through the hosted revocation flow. No further payments can be collected. |
expired | The mandate's validity period has ended (i.e. the end_date limit has passed). No further payments can be collected. |
failed | The customer's authorisation attempt was unsuccessful, or the mandate could not be created. |
Mandate lifecycle
| From | To | Trigger | Webhook |
|---|---|---|---|
| — | pending | You create the mandate via the API. | — |
pending | active | The customer authorises the mandate at their bank. | mandate_active |
pending | failed | Authorisation is unsuccessful, or the mandate could not be created. | mandate_failed |
pending | expired | The customer does not complete authorisation in time. | mandate_expired |
active | cancelled | The customer revokes consent in their banking app, or completes the hosted revocation flow. | mandate_cancelled |
active | expired | The end_date limit passes. | mandate_expired |
In short: pending → active, failed, or expired · active → cancelled or expired · failed, cancelled, expired → no further transitions.
Note: Customers can cancel a mandate at any time directly from their banking app, and merchants can offer cancellation through the hosted revocation flow. You will receive a webhook notification when either occurs. Ensure your integration handles cancelled mandate webhooks to prevent attempting payments against an inactive mandate.
VRP payment statuses
The following statuses apply to individual payments collected against an active VRP mandate. Unlike one-off payments, VRP payments do not require a customer redirect, so there is no redirect_url form POST for these.
| Status | Description |
|---|---|
pending | The payment has been initiated and is being processed. |
executed | The payment has been executed by the bank. If funds are settling outside of an Acquired ledger, the final payment status will remain at executed. |
settled | The payment has been received into your Acquired settlement account. This status only applies to merchants using Acquired-held accounts. |
declined | The payment was declined. This may occur if the payment exceeds the mandate limits, if there are insufficient funds, or if the bank declined execution. You can check funds in advance — see Checking funds before you collect. |
error | The payment failed due to a technical issue (see detail below). |
How a VRP payment status progresses
The typical successful sequence is pending → executed → settled.
| Stage | Status | Notes |
|---|---|---|
| API response | pending or error | The response to your payment request only ever returns one of these two. pending is not the final outcome. |
| Bank executes the payment | executed | Delivered by status_update webhook. |
| Funds land in Acquired ledger | settled | Delivered by status_update webhook. Acquired-held settlement only — for external settlement the status stops at executed. |
All status changes after the API response arrive via the status_update webhook. To poll instead, or to recover from a failed webhook delivery, use List variable recurring payments for payments and Retrieve an open banking mandate for mandates.
Error status
An error status indicates the payment failed due to a technical issue, either at the originating bank, on the Faster Payments network, or because the mandate was no longer active at the time of the attempt.
Updated 18 days ago