Statuses

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.

One-off payment statuses

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.

---

Mandate statuses

The following statuses apply to VRP mandates, which govern the authorisation a customer grants for recurring Open Banking payments.

Mandate lifecycle

A mandate transitions through two phases. During setup, a pending mandate will move to active if the customer authorises successfully, or to failed or expired if authorisation is unsuccessful or not completed in time. Once active, a mandate remains active until it is either cancelled by the customer or merchant, or expired when the end_date passes.

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.

How a VRP payment status progresses

A VRP payment status is not a single value you read once. It is a progression you observe over time, and you must track it through webhooks or polling rather than relying on the initial API response.

1. On submitting a collection, whether Sweeping or Commercial, the API response only ever returns pending or error. A pending response is not the final outcome.
2. All subsequent status changes arrive via the status_update webhook. Track the collection through these events, not through the response to your original request.
3. The typical successful flow is pending → executed → settled:
   • executed means the bank has accepted and executed the payment.
   • settled means the funds have landed in the Acquired ledger. This only applies to internal, Acquired-held settlement. For external settlement, Acquired has no visibility of the receiving bank account, so the status stops at executed.
4. If you do not want to rely on webhooks, or a webhook delivery fails (network issues do occur), poll the collection status directly via the relevant GET endpoint rather than assuming the pending from the API response is the final word.

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.