# Payment lifecycle and statuses (https://docs.tryacme.com/guides/payment-lifecycle-and-statuses)
> For AI agents: the documentation index is at [llms.txt](https://docs.tryacme.com/llms.txt), with every page in one file at [llms-full.txt](https://docs.tryacme.com/llms-full.txt). Each page is also available as Markdown by appending `.md` to its URL.
Every status a payment or batch can have, where approval happens, and how each bank's statuses map to Acme's.
Every payment moves through a set of statuses, from the moment you create it to the bank's final answer. This page explains:
* The single payment flow and its statuses.
* The batch payment flow and its statuses.
* Approval in your bank's portal.
* Acme maker-checker, an optional approval step at Acme.
* How each bank's own statuses map to Acme's.
## Single payment flow [#single-payment-flow]
You create a single payment with [Create a Payment](https://docs.tryacme.com/reference/post-payments) (`POST /v1/payments`). There are two ways to follow its status:
* **Webhooks.** Acme sends an event to your endpoint when the payment completes or fails, and at each maker-checker step. See [Webhooks](https://docs.tryacme.com/guides/webhooks) and the [payment events](https://docs.tryacme.com/reference/webhooks-payments#payments).
* **Get a Payment.** Fetch the payment with [Get a Payment](https://docs.tryacme.com/reference/get-payments-id) (`GET /v1/payments/{id}`) at any time.
Not every status sends a webhook. For example, `PROCESSING` and `SUBMITTED` send none. The Webhook column in each status table shows which do.
The usual path:
`PROCESSING` → `SUBMITTED` → `COMPLETED`
Other paths:
* The bank rejects the payment: `PROCESSING` or `SUBMITTED` → `FAILED`.
* Some banks give their final answer straight away, so the payment goes from `PROCESSING` to `COMPLETED` or `FAILED` without `SUBMITTED`.
* Some banks do not report that they accepted the payment, so it stays `PROCESSING` until their final answer. The [bank tables](#bank-status-mapping) show which.
### Payment statuses [#payment-statuses]
| Status | Where the payment is | What it means | Final? | Webhook |
| --- | --- | --- | --- | --- |
| `PROCESSING` | Acme or the bank | Acme is sending it to the bank, or the bank has it but has not yet reported a result. | No | None |
| `SUBMITTED` | The bank | The bank accepted it and is processing it. Acme is waiting for the final answer. | No | None |
| `COMPLETED` | The bank | The bank confirmed the payment. | Yes | `payments.succeeded` |
| `FAILED` | The bank | The bank rejected or returned the payment. `resultCode` says why. | Yes | `payments.failed` |
If your organization uses [Acme maker-checker](#acme-maker-checker), a payment can also be `PENDING_APPROVAL`, `APPROVAL_REJECTED` or `APPROVAL_EXPIRED` before it reaches `PROCESSING`.
> * `COMPLETED` and `FAILED` never change. A payment that completed is never marked failed later, and the reverse.
> * If the bank does not answer, the payment usually stays `PROCESSING` or `SUBMITTED`. Acme checks with the bank, or Acme's team confirms the result with it.
> * If Acme marks a payment `FAILED` without a rejection from the bank, for example after an error or an answer Acme cannot read, the bank may still have made it. Contact Acme before you retry the payment. Each [bank's table](#bank-status-mapping) shows where this can happen.
> * A payment can stay `SUBMITTED` with `resultCode` `REQUEST_TIMEOUT` while Acme confirms the result. This `resultCode` does not mean the payment failed.
## Batch payment flow [#batch-payment-flow]
You create a [batch payment](https://docs.tryacme.com/guides/batch-payments) with [Create a Batch Payment](https://docs.tryacme.com/reference/post-batch-payments) (`POST /v1/payment-batches`). Acme sends the batch to the bank as one file. The batch and each payment in it have separate statuses.
You can follow these statuses in two ways:
* **Webhooks.** Acme sends a [batch event](https://docs.tryacme.com/reference/webhooks-payments#batch-payments) when the file is sent or rejected. It also sends `payments.succeeded` or `payments.failed` as the bank reports on the payments. One webhook can carry up to 100 payments under `objects`, as described in [Payments in a batch](https://docs.tryacme.com/reference/webhooks-payments#payments-in-a-batch). Each payment includes its `id` and the `batchId` of its batch.
* **Polling.** [Get a Batch Payment](https://docs.tryacme.com/reference/get-batch-payments-id) (`GET /v1/payment-batches/{id}`) returns the batch status only. To poll a payment, call [Get a Payment](https://docs.tryacme.com/reference/get-payments-id) with the payment `id`.
> **Record each payment ID**
>
> - The create response is the only response that lists the payments in a batch, each with its `id`.
> - Get a Batch Payment and List Batch Payments do not return the payments, and List Payments cannot filter by batch.
> - If you poll, store each payment `id` from the create response.
> - If you use webhooks, match each payment event to its batch with `batchId`.
| Batch status | What it means | Final? | Webhook |
| --- | --- | --- | --- |
| `PROCESSING` | Acme is preparing the file, or waiting to send it. | No | None |
| `SUBMITTED` | Acme sent the file to the bank. | No | `payment-batches.submitted` |
| `COMPLETED` | Every payment in the batch is `COMPLETED` or `FAILED`. | Yes | None |
| `FAILED` | The bank rejected the whole file. Every payment in it is `FAILED`. | Yes | `payment-batches.rejected` |
Payments in a batch:
* **`PROCESSING`:** each payment starts here while Acme prepares the file. A `200` answer to the create request means Acme created the batch, not that the bank has made the payments. If a batch stays `PROCESSING` for more than an hour, contact Acme. Do not send the batch again, as the payments may be made twice.
* **`SUBMITTED`:** each payment moves here when Acme sends the file. Do not send a `SUBMITTED` payment again. Some banks hold the file for approval in their portal, and some send no further status after approval or after payment. The payment then stays `SUBMITTED` in Acme, and you can confirm it in the bank's portal or on your bank statement. See each [bank's section](#bank-status-mapping).
* **`COMPLETED` or `FAILED`:** each payment moves here as the bank reports on it, and is included in a `payments.succeeded` or `payments.failed` webhook. For a failed payment, `underlyingErrorMessage` holds the bank's reason when the bank provides one. If the bank rejects the whole file, the batch carries the reason.
* A `COMPLETED` batch can contain `FAILED` payments. Check each payment's status, not only the batch status.
* Batch payments do not go through Acme maker-checker.
### Example: a batch of 10 payments [#example-a-batch-of-10-payments]
The ACK names and the ACK that is final differ by bank. This example uses ACK1 to ACK3. See [Bank status mapping](#bank-status-mapping) for each bank.
1. You send 10 payments, 2 of them with an invalid bank code. Acme answers `400` and creates nothing.
2. You correct the 2 payments and send the batch again. Acme answers `200`. The batch and its 10 payments are `PROCESSING`, and the response lists each payment `id`.
3. Acme sends the file to the bank. The batch and its payments move to `SUBMITTED`, and Acme sends `payment-batches.submitted`.
4. The bank accepts the file in ACK1. If the bank rejects the whole file instead, Acme sends `payment-batches.rejected`, and `payments.failed` for every payment.
5. The bank checks each payment in ACK2 and rejects 2 other payments. Those payments move to `FAILED` and are reported in `payments.failed`.
6. The bank accepts the remaining 8 payments in ACK3, its final answer. Those payments move to `COMPLETED` and are reported in `payments.succeeded`.
7. No payment is waiting for the bank, so the batch moves to `COMPLETED`. Acme sends no webhook for this.
For DBS, when the bank changes a payment's date (`ACWC`), Acme updates `actualPaymentDate`. When DBS reports a charge, Acme sets `bankChargeAmount` and `bankChargeCurrency`. Acknowledgements from other banks do not change these fields.
## Approval at the bank [#approval-at-the-bank]
Your bank can ask for approval in its own portal. This is agreed between you and your bank. There are two set-ups:
* **Straight-through (pre-authorised).** The bank processes the payment as soon as it receives it. Nobody approves it in the bank's portal.
* **Re-authorisation.** The bank holds the payment until your approvers approve it in the bank's portal, for example DBS IDEAL, OCBC Velocity, HSBCnet, RHB Reflex or Maybank M2E.
While the bank holds the payment, Acme shows `SUBMITTED`, or `PROCESSING` for banks that do not report acceptance. When your approver rejects it in the portal, the payment moves to `FAILED` if the bank reports the rejection to Acme. Each [bank table](#bank-status-mapping) says how that bank handles approval.
## Acme maker-checker [#acme-maker-checker]
> Most organizations do not use Acme maker-checker. If Acme has not set it up for you, your payments follow the [single payment flow](#single-payment-flow) and you can skip this section.
Acme maker-checker is an optional approval step at Acme, before the payment goes to the bank. A payment made by a maker API key waits at Acme until a checker API key approves it. It is separate from [approval at the bank](#approval-at-the-bank), and you can use both.
How it works:
* Acme turns it on for your organization. The set-up names the maker API keys, the checker API keys, and the accounts it covers.
* If the set-up names no maker keys, every API key is a maker on the covered accounts.
* A payment created by a maker key on a covered account starts as `PENDING_APPROVAL`. It is not sent to the bank.
* A checker key approves it with [Approve a Payment](https://docs.tryacme.com/reference/post-payments-id-approve) or rejects it with [Reject a Payment](https://docs.tryacme.com/reference/post-payments-id-reject).
* When the set-up names checker keys, only those keys can approve or reject.
* The checker key cannot be the key that made the payment.
* A payment prepared in the dashboard is approved in the dashboard, not with an API key.
* Approval sends the payment to the bank in the same call. The payment moves to `PROCESSING` and follows the [single payment flow](#single-payment-flow).
* `review.expiresAt` on the payment is the approval deadline. The default is 7 days after the payment is created. A payment prepared in the dashboard has 24 hours.
* Batch payments do not go through Acme maker-checker.
| Status | What it means | Final? | Webhook |
| --- | --- | --- | --- |
| `PENDING_APPROVAL` | Waiting for a checker key to approve or reject it. | No | `payments.pending-approval` |
| `APPROVAL_REJECTED` | A checker key rejected it. It was never sent to the bank. | Yes | `payments.approval-rejected` |
| `APPROVAL_EXPIRED` | Nobody approved it before `review.expiresAt`. It was never sent to the bank. | Yes | `payments.approval-expired` |
| `PROCESSING` | A checker key approved it, and Acme is sending it to the bank. | No | None (see `payments.approved` below) |
* `payments.approved` is sent once the checker approves. It carries the payment's status at that moment, which can already be past `PROCESSING`.
* A rejected or expired payment has no `resultCode`.
* See [Maker-checker flow](https://docs.tryacme.com/reference/webhooks-payments#maker-checker-flow) for the webhook payloads.
## Bank status mapping [#bank-status-mapping]
Each bank section below describes how the bank reports on a payment and how Acme maps each report to a payment status.
* **Label:** each flow is labelled **API** for single payments or **Batch file** for batch payments.
* **Order:** each flow lists the bank's answers in the order they arrive.
* **Thick border:** marks an answer that can complete the payment. A rejection can also arrive at other steps.
* **Table:** the table under each flow gives the Acme status for each answer.
ANZ Australia
Batch payments only, by file. See the [ANZ Australia guide](https://docs.tryacme.com/guides/anz-au-payments).
**Batch file: Batch payment**
1. **File sent**: payments are `SUBMITTED`.
2. **Status file** (pain.002): final on `ACSP` or `RJCT`.
| ACK | Bank status | What it means | Acme payment status | Webhook |
| --- | --- | --- | --- | --- |
| Status file | `RJCT` (file) | ANZ rejected the whole file. | `FAILED` | `payments.failed` for each payment. `payment-batches.rejected` when the file has no status for each payment. |
| Status file | `RJCT` | ANZ rejected the payment. | `FAILED` | `payments.failed` |
| Status file | `ACSP` | ANZ accepted the payment. Final. | `COMPLETED` | `payments.succeeded` |
| Status file | Any other code | Not final. | `SUBMITTED` | None |
**Approval at the bank**
* Set up with ANZ.
* Acme shows `SUBMITTED` until ANZ reports a final status.
Banco Azteca Mexico
Single payments only, by API. See the [Banco Azteca Mexico guide](https://docs.tryacme.com/guides/baz-mx-payments).
**API: Single payment: BKTR**
1. **Submit**: final. Banco Azteca answers with the result.
| Banco Azteca answer | Acme status | What it means |
| --- | --- | --- |
| Success | `COMPLETED` | The transfer is done. |
| Error, no answer, or an answer Acme cannot read | `FAILED` | Banco Azteca rejected the payment, or did not answer. Banco Azteca may still have made the payment. Contact Acme before you retry the payment. |
**API: Single payment: MX_SPEI**
1. **Submit**: the payment stays `PROCESSING`.
2. **Status checks**: every minute, then every 5 minutes, until final.
| Banco Azteca status | Acme status | What it means |
| --- | --- | --- |
| Sent | `PROCESSING` | Banco Azteca has the payment. |
| Error, no answer, or an answer Acme cannot read, when Acme sends it | `FAILED` | Banco Azteca may still have made the payment. Contact Acme before you retry the payment. |
| `ENVIADA`, `EN PROCESO`, `RECIBIDA` | `PROCESSING` | Not final. Acme checks again every minute, then every 5 minutes. |
| `LIQUIDADA`, `COMPLETADA`, `ACEPTADA` | `COMPLETED` | The payment settled. |
| `RECHAZADA`, `CANCELADA`, `DEVUELTA`, `NO LIQUIDADA`, `NO ENCONTRADA` | `FAILED` | Rejected, cancelled, returned, not settled or not found. |
| Any other status | `PROCESSING` | Not final. Acme checks until the 24-hour limit. |
* If Banco Azteca has no final status after 24 hours, Acme marks the payment `FAILED`.
**Approval at the bank**
* Set up with Banco Azteca.
CIMB Singapore
Single payments by API and batch payments by file. See the [CIMB API guide](https://docs.tryacme.com/guides/cimb-api-payments) and the [CIMB H2H guide](https://docs.tryacme.com/guides/cimb-h2h-payments).
**API: Single payment**
1. **Submit answer**: CIMB accepts or rejects.
2. **CIMB notification**: final on a debit notification, or a TT notification `Processed`, `Executed with Failure` or `Failed`.
| Payment type | CIMB answer | Acme status | What it means |
| --- | --- | --- | --- |
| `FAST` | `ACTC` | `SUBMITTED` | CIMB accepted the payment. |
| `FAST` | `RJCT` | `FAILED` | CIMB rejected the payment. |
| `TT` | `SUCCESS` | `SUBMITTED` | CIMB accepted the payment. |
| `TT` | Any other status | `FAILED` | CIMB rejected the payment. |
| `BKTR` | `0` | `SUBMITTED` | CIMB accepted the payment. |
| `BKTR` | `1` | `FAILED` | CIMB rejected the payment. |
| Any | Any other answer, or no status | `PROCESSING` | Not final. Contact Acme to confirm the result with CIMB. |
| Any | HTTP error, or an answer Acme cannot read | `FAILED` | CIMB may still have made the payment. Contact Acme before you retry the payment. |
| Any | No answer | `PROCESSING` | Not final. Contact Acme to confirm the result with CIMB. |
| `FAST`, `BKTR` | Debit notification | `COMPLETED` | CIMB debited your account. |
| `TT` | Remittance notification `Processed` | `COMPLETED` | CIMB sent the payment. |
| `TT` | Remittance notification `Executed with Failure` or `Failed` | `FAILED` | The payment failed. |
* The final status comes from CIMB's notifications. Acme does not ask CIMB for it.
**Batch file: Batch payment**
1. **File sent**: payments are `SUBMITTED`.
2. **PSR-1**: file checks. A payment `ACSC` or `RJCT` waits for a later PSR.
3. **PSR-2 to PSR-10**: final on `ACSC` or `RJCT`.
| ACK | Bank status | What it means | Acme payment status | Webhook |
| --- | --- | --- | --- | --- |
| Any PSR | `RJCT` (file) | CIMB rejected the whole file. | `FAILED` | `payments.failed` for each payment. `payment-batches.rejected` when the file has no status for each payment. |
| Any PSR | `RCVD`, `ACCP`, `ACSP`, `PDNG` | Received, accepted or pending. Not final. | `SUBMITTED` | None |
| PSR-2 or later | `ACSC` | The payment settled. Final. | `COMPLETED` | `payments.succeeded` |
| PSR-2 or later | `RJCT` | CIMB rejected the payment. | `FAILED` | `payments.failed` |
* `ACSC` or `RJCT` for a payment in PSR-1 is not applied. Acme waits for a later report.
**Approval at the bank**
* Set up with CIMB.
Citibank (all countries)
Single payments by API for Singapore `PAYNOW` and Malaysia `MY_DUITNOW`. Batch payments by file in every Citi country. See the Citibank guides, for example [Citibank Singapore](https://docs.tryacme.com/guides/citi-sg-payments).
**API: Single payment**
1. **Submit answer**: final on `ACSP`, `ACSC` or `RJCT`.
2. **Status checks**: final on `ACSP`, `ACSC` or `RJCT`.
| Citi status | Acme status | What it means |
| --- | --- | --- |
| `ACTC`, `ACCP`, `PDNG` | `PROCESSING` | Accepted or pending. Acme keeps checking. |
| `ACSP`, `ACSC` | `COMPLETED` | The payment settled or is settling. |
| `RJCT` | `FAILED` | Citi rejected the payment. |
| HTTP error, or no answer, at submit | `PROCESSING` | Not final. Acme keeps checking with Citi. |
| No record of the payment after repeated checks | `FAILED` | Citi did not receive the payment. |
| An answer Acme cannot match to the payment, after repeated checks | `FAILED` | Acme could not confirm the payment with Citi. |
| Any other code | `PROCESSING` | Not final. Acme keeps checking. |
**Batch file: Batch payment**
1. **File sent**: payments are `SUBMITTED`.
2. **FILE**: file checks.
3. **TXN**: final on `ACSP` or `RJCT`.
| ACK | Bank status | What it means | Acme payment status | Webhook |
| --- | --- | --- | --- | --- |
| FILE | `RJCT` (file) | Citi rejected the whole file. | `FAILED` | `payments.failed` for each payment, and `payment-batches.rejected` |
| FILE | Any other code | Citi accepted the file. | `SUBMITTED` | None |
| TXN | `RJCT` | Citi rejected the payment. | `FAILED` | `payments.failed` |
| TXN | `ACCP`, `ACWC` | Accepted. Not final. | `SUBMITTED` | None |
| TXN | `ACSP` | Final acceptance from Citi. | `COMPLETED` | `payments.succeeded` |
| TXN | Any other code | Not applied. | `SUBMITTED` | None |
**Approval at the bank**
* Set up with Citi.
DBS Singapore
Single payments by API and batch payments by file. See the [DBS API guide](https://docs.tryacme.com/guides/dbs-sg-api-payments) and the [DBS H2H guide](https://docs.tryacme.com/guides/dbs-sg-payments).
**API: Single payment: FAST and PAYNOW**
1. **Submit answer**: final on `ACTC`, `ACWC` or `RJCT`.
2. **Status checks**: final on `ACTC`, `ACWC` or `RJCT`. Up to 3, 5 minutes apart.
| DBS status | Acme status | What it means |
| --- | --- | --- |
| `ACTC`, `ACWC` | `COMPLETED` | DBS accepted the payment. |
| `RJCT` | `FAILED` | DBS rejected the payment. |
| `PDNG` | `SUBMITTED` | Pending. Acme checks again, up to 3 times. |
| `RJCT` with `A005` or `A009` | `SUBMITTED` | DBS planned downtime. Acme checks again, up to 3 times. |
| No answer | `SUBMITTED` | Acme checks again, up to 3 times. |
| `ACSP`, `ACCP`, `PART` in the submit answer | `FAILED` | DBS does not send these here. Contact Acme before you retry the payment. |
* After the last check, the payment stays `SUBMITTED` and Acme's team confirms the result with DBS.
**API: Single payment: ACT, MEPS and TT**
1. **Submit answer**: `ACTC`, DBS received the payment.
2. **Status checks**: only after `PDNG` or planned downtime. Up to 3, 5 minutes apart.
3. **ACK2**: `ACCP` or `ACWC` is not final. `RJCT` is final.
4. **ACK3**: final.
| DBS status | Acme status | What it means |
| --- | --- | --- |
| `ACTC` in the first answer | `SUBMITTED` | DBS received the payment. The result comes later. |
| `RJCT` in the first answer | `FAILED` | DBS rejected the payment. |
| `PDNG`, or `RJCT` with `A005` or `A009` | `SUBMITTED` | Pending or planned downtime. Acme checks again, up to 3 times. |
| `ACWC`, `ACSP`, `ACCP`, `PART` in the first answer | `FAILED` | DBS does not send these in the first answer. Contact Acme before you retry the payment. |
| `ACCP`, `ACWC` in ACK2 | `SUBMITTED` | Accepted. Not final yet. |
| `ACSP`, `ACWC` in ACK3 | `COMPLETED` | Final acceptance from DBS. |
| `RJCT` in ACK2 or ACK3 | `FAILED` | DBS rejected the payment. |
* After the last check, the payment stays `SUBMITTED` and Acme's team confirms the result with DBS.
**Batch file: Batch payment**
1. **File sent**: payments are `SUBMITTED`.
2. **ACK1**: file checks.
3. **ACK2**: payment checks. `RJCT` is final, `ACCP` or `ACWC` is not.
4. **ACK3**: final. With approval in IDEAL, it comes after approval.
| ACK | Bank status | What it means | Acme payment status | Webhook |
| --- | --- | --- | --- | --- |
| ACK1 | `ACTC` (file) | DBS accepted the file. | `SUBMITTED` | None |
| ACK1 | `RJCT` (file) | DBS rejected the whole file. | `FAILED` | `payments.failed` for each payment, and `payment-batches.rejected` |
| ACK2 | `ACCP`, `ACWC` | Accepted. Not final. | `SUBMITTED` | None |
| ACK2 | `RJCT` | DBS rejected the payment. | `FAILED` | `payments.failed` |
| ACK2, ACK3 | `PDNG` | Pending. | `SUBMITTED` | None |
| ACK3 | `ACCP`, `ACWC` | Final acceptance from DBS. | `COMPLETED` | `payments.succeeded` |
| ACK3 | `RJCT` | DBS rejected the payment. | `FAILED` | `payments.failed` |
| ACK2, ACK3 | Any other code | Not applied. | `SUBMITTED` | None |
**Approval at the bank**
* Files are sent straight-through (STP) or for approval in DBS IDEAL. Acme sets this for your organization.
* With approval in IDEAL, DBS sends ACK2 before approval and ACK3 after it. Payments stay `SUBMITTED` until your approvers act.
* If nobody approves the payments in IDEAL, they stay `SUBMITTED`.
Deutsche Bank Singapore
Batch payments only, by file. See the [Deutsche Bank Singapore guide](https://docs.tryacme.com/guides/db-sg-payments).
**Batch file: Batch payment**
1. **File sent**: payments are `SUBMITTED`.
2. **Status file**: final. It comes before approval in Deutsche Bank's portal.
| ACK | Bank status | What it means | Acme payment status | Webhook |
| --- | --- | --- | --- | --- |
| Status file | `RJCT` (file) | Deutsche Bank rejected the whole file. | `FAILED` | `payments.failed` for each payment. `payment-batches.rejected` when the file has no rejection for each payment. |
| Status file | `RJCT` | Deutsche Bank rejected the payment. | `FAILED` | `payments.failed` |
| Status file | `ACCP` | Deutsche Bank accepted the payment. Final. | `COMPLETED` | `payments.succeeded` |
| Status file | Any other code | Not applied. | `SUBMITTED` | None |
**Approval at the bank**
* Deutsche Bank sends one status file. It arrives before your approvers act in Deutsche Bank's web portal.
* Acme marks a payment `COMPLETED` when that file accepts it. Approval in the portal happens after that.
* Deutsche Bank sends no later file for a payment that is not approved, rejected by the beneficiary bank, or returned. Check those in Deutsche Bank's portal.
HSBC Hong Kong, Malaysia, Singapore and Vietnam
Single payments by API in Hong Kong and Malaysia. Batch payments by file in Singapore, Malaysia, Hong Kong and Vietnam. See the HSBC guides for [Singapore](https://docs.tryacme.com/guides/hsbc-sg-payments), [Hong Kong (API)](https://docs.tryacme.com/guides/hsbc-hk-api-payments), [Hong Kong (H2H)](https://docs.tryacme.com/guides/hsbc-hk-h2h-payments), [Malaysia](https://docs.tryacme.com/guides/hsbc-my-payments) and [Vietnam](https://docs.tryacme.com/guides/hsbc-vn-payments).
**API: Single payment: Hong Kong**
1. **Submit answer**: final on `ACSC`, `RJCT` or a refusal.
2. **Status checks**: final on `ACSC` or `RJCT`.
| HSBC status | Acme status | What it means |
| --- | --- | --- |
| `ACSC` | `COMPLETED` | The payment settled. |
| `RJCT` | `FAILED` | HSBC rejected the payment. |
| HTTP 400, 401, 403, 405, 406 or 415, a maintenance answer (503 `RJCT`), or a 429 "API calls exceeded", at submit | `FAILED` | HSBC refused the request and did not process it. |
| `ACCP`, `ACSP`, `ACTC`, `ACWC`, `PART`, `PDNG` | `SUBMITTED` | Not final. Acme keeps checking. |
| No answer, any other HTTP error, or any other code | `SUBMITTED` | Acme keeps checking for up to 1 day (`HK_FPS`), 7 days (`HK_CHATS`) or 10 days (`TT`). Then Acme's team confirms the result. |
| HSBC answers that it has no record of the payment, 3 times in a row over at least 10 minutes | `FAILED` | HSBC did not receive the payment. Acme applies this only when it holds HSBC's reference for the payment. Without it, Acme's team confirms the result with HSBC. |
**API: Single payment: Malaysia**
1. **Submit answer**: final on `ACCP`, `ACSP`, `ACSC` or `RJCT`.
2. **Status checks**: final on `ACCP`, `ACSP`, `ACSC` or `RJCT`.
| HSBC status | Acme status | What it means |
| --- | --- | --- |
| `ACTC`, `ACWC`, `PART`, `PDNG` | `PROCESSING` | Not final. Acme keeps checking. |
| `ACCP`, `ACSP`, `ACSC` | `COMPLETED` | HSBC accepted the payment. |
| `RJCT` | `FAILED` | HSBC rejected the payment. |
| Any other code, at a status check | `PROCESSING` | Acme keeps checking. |
| Any other code, at submit | `PROCESSING` | Not final. Acme's team confirms the result with HSBC. |
| HTTP error, no answer, or an answer Acme cannot read, at submit | `FAILED` | HSBC may still have made the payment. Contact Acme before you retry the payment. |
**Batch file: Batch payment**
1. **File sent**: payments are `SUBMITTED`.
2. **ACK1**: file checks. Completes a payment only on `ACSC`.
3. **ACK2**: payment checks. Completes a payment only on `ACSC`.
4. **Interim ACK2**: only for files approved in HSBCnet, after the final approval. Completes a payment only on `ACSC`.
5. **ACK3**: final for most types.
6. **ACK4**: final for the types listed below.
The final ACK depends on the payment type:
* ACK4 is final for Singapore `FAST` and `PAYNOW`, Malaysia `MY_DUITNOW`, and every Hong Kong and Vietnam type.
* ACK3 is final for every other type.
* Singapore `FAST` and `PAYNOW` have no ACK3.
| ACK | Bank status | What it means | Acme payment status | Webhook |
| --- | --- | --- | --- | --- |
| Any ACK | `RJCT` (file) | HSBC rejected the whole file. | `FAILED` | `payments.failed` for each payment. `payment-batches.rejected` when the file has no rejection for each payment. |
| Any ACK | `RJCT` | HSBC rejected the payment. | `FAILED` | `payments.failed` |
| Any ACK | `ACSC` | The payment settled. Final. | `COMPLETED` | `payments.succeeded` |
| ACK2, interim ACK2, or an ACK before the final one | `ACCP`, `ACSP`, `ACWC` | Accepted. Not final. | `SUBMITTED` | None |
| Final ACK (ACK3 or ACK4) | `ACCP`, `ACSP`, `ACWC` | Final acceptance from HSBC. | `COMPLETED` | `payments.succeeded` |
| Any ACK | Any other code | Not final. | `SUBMITTED` | None |
**Approval at the bank**
* Hong Kong API payments are always sent pre-authorised (straight-through).
* Malaysia API payments, and files in every country, carry an authorisation type that Acme sets for each account. Approval in HSBCnet follows what you agreed with HSBC.
* For files approved in HSBCnet, HSBC sends an interim ACK2 after the final approval. Payments stay `SUBMITTED` until the final ACK.
Maybank Singapore
Batch payments only, by file. See the [Maybank Singapore guide](https://docs.tryacme.com/guides/mbb-sg-payments).
**Batch file: Batch payment**
1. **File sent**: payments are `SUBMITTED`.
2. **ACK**: file checks. Rejected lines fail.
3. **RTN**: each payment's status. Final on `Successful` or a failure status.
| ACK | Bank status | What it means | Acme payment status | Webhook |
| --- | --- | --- | --- | --- |
| ACK | No line accepted | Maybank rejected the whole file. | `FAILED` | `payments.failed` for each payment, and `payment-batches.rejected` |
| ACK | Some lines rejected | Only the payments on those lines failed. | `FAILED` | `payments.failed` |
| ACK | Every line accepted | Maybank accepted the file. | `SUBMITTED` | None |
| RTN | `Successfully Sent to Bank` | Pending processing by Maybank. | `SUBMITTED` | None |
| RTN | `New`, `Pending Verification`, `Pending Authorisation`, `Pending Releaser` | Waiting for your approvers in Maybank M2E. | `SUBMITTED` | None |
| RTN | `Returned` | Returned in Maybank M2E. Not final. | `SUBMITTED` | None |
| RTN | `Successful` | The payment succeeded. | `COMPLETED` | `payments.succeeded` |
| RTN | `Bank Rejected`, `Rejected`, `Stopped`, `Expired`, `Deleted` | The payment failed or was stopped. | `FAILED` | `payments.failed` |
| RTN | Any other status | Not applied. | `SUBMITTED` | None |
**Approval at the bank**
* Payments wait in Maybank M2E for your approvers. The statuses `New` to `Pending Releaser` are steps in that workflow.
* Payments stay `SUBMITTED` while they wait in that workflow.
OCBC Singapore
Single payments by API for `PAYNOW`. Batch payments by file. See the [OCBC Singapore guide](https://docs.tryacme.com/guides/ocbc-sg-payments).
**API: Single payment: PAYNOW**
1. **Submit answer**: final.
| OCBC answer | Acme status | What it means |
| --- | --- | --- |
| `Success` is true | `COMPLETED` | OCBC made the payment. |
| `Success` is false | `FAILED` | OCBC rejected the payment. |
| No answer (timeout) | `SUBMITTED` | `resultCode` is `REQUEST_TIMEOUT`. Acme's team confirms the result with OCBC. |
| HTTP error, or an answer Acme cannot read | `FAILED` | OCBC may still have made the payment. Contact Acme before you retry the payment. |
**Batch file: Batch payment**
1. **File sent**: payments are `SUBMITTED`.
2. **ACK1 or NACK1**: file checks. Completes a payment only on `ACSC`.
3. **ACK2 or NACK2**: payment checks. Completes a payment only on `ACSC`.
4. **RET**: final.
| ACK | Bank status | What it means | Acme payment status | Webhook |
| --- | --- | --- | --- | --- |
| Any file | `RJCT` (file) | OCBC rejected the whole file. | `FAILED` | `payments.failed` for each payment. `payment-batches.rejected` when the file has no rejection for each payment. |
| Any file | `RJCT` | OCBC rejected the payment. | `FAILED` | `payments.failed` |
| Any file | `ACSC` | The payment settled. Final. | `COMPLETED` | `payments.succeeded` |
| Any file before RET | `ACCP`, `ACSP`, `ACWC` | Accepted. Not final. | `SUBMITTED` | None |
| RET | `ACCP`, `ACSP`, `ACWC` | Final acceptance from OCBC. | `COMPLETED` | `payments.succeeded` |
| Any file | Any other code | Not final. | `SUBMITTED` | None |
* OCBC also sends NACK3 when your approvers reject a payment in Velocity. Acme does not read NACK3 yet.
**Approval at the bank**
* Files wait for your approvers in OCBC Velocity.
* OCBC sends no status file while a payment waits for approval. Payments stay `SUBMITTED` until then.
* A payment your approvers reject in Velocity stays `SUBMITTED`. Acme does not yet read OCBC's rejection file. Contact Acme to close the payment.
RHB Malaysia
Single payments only, by API through RHB Reflex. See the [RHB Malaysia guide](https://docs.tryacme.com/guides/rhb-my-payments).
**API: Single payment**
1. **Submit answer**: final on `05`, `03` or `06`, or when RHB refuses the request.
2. **Status checks**: every hour until final.
**First answer**
| RHB status | RHB meaning | Acme status |
| --- | --- | --- |
| `01` | Successful | `SUBMITTED` |
| `02` | Successful with reason | `SUBMITTED` |
| `03` | Unsuccessful | `FAILED` |
| `04` | Pending pre-authorisation | `SUBMITTED` |
| `05` | Pre-authorisation posting successful | `COMPLETED` |
| `06` | Pre-authorisation unsuccessful | `FAILED` |
| `07` | Pre-authorisation timeout | `SUBMITTED`, with `resultCode` `REQUEST_TIMEOUT` |
| Error code from RHB Reflex | RHB rejected the request | `FAILED` |
| HTTP 4xx or 503 with no RHB code | RHB refused the request | `FAILED` |
| No answer, or another HTTP 5xx | Outcome not known | `SUBMITTED`, with `resultCode` `REQUEST_TIMEOUT` |
**Later checks**
Acme checks every hour. After a timeout, the first check is after 5 minutes.
| RHB status | RHB meaning | Acme status |
| --- | --- | --- |
| `1`, `11`, `13`, `18` | Pending, transmitting, pending status update, pending authoriser | `SUBMITTED` |
| `2`, `3`, `17` | Processed, successful, cycle completed | `COMPLETED` |
| `4`, `7`, `8`, `10`, `12`, `19` | Unsuccessful, expired, aborted, stopped, rejected, rejected by authoriser | `FAILED` |
**Approval at the bank**
* Pre-authorisation (straight-through) is set for each account, on RHB's side and on Acme's.
* With pre-authorisation, RHB gives the final result in its first answer (`05` or `06`).
* Without it, the payment waits for your authorisers in RHB Reflex and stays `SUBMITTED`. An authoriser rejection (`19`) fails the payment with `resultCode` `REJECTED_BY_APPROVER`.
Standard Chartered
Single payments by API in Hong Kong, Singapore, the UK, India and the UAE. Batch payments by file in Singapore, the UK and India. See the Standard Chartered guides, for example [Singapore API](https://docs.tryacme.com/guides/scb-sg-api-payments) and [Singapore H2H](https://docs.tryacme.com/guides/scb-sg-h2h-payments).
**API: Single payment**
1. **Submit answer**: final on `Completed` or `Rejected`.
2. **Notification or status checks**: final on a completed or rejected code.
| Standard Chartered status | Acme status | What it means |
| --- | --- | --- |
| `Completed` in the first answer | `COMPLETED` | The payment is done. |
| `Pending` in the first answer | `PROCESSING` | Not final. The result comes later. |
| `Rejected` in the first answer | `FAILED` | Standard Chartered rejected the payment. |
| No answer (timeout) | `PROCESSING` | Acme confirms the result with Standard Chartered. |
| HTTP error, or an answer Acme cannot read | `FAILED` | For an HTTP 5xx or an unreadable answer, Standard Chartered may still have made the payment. Contact Acme before you retry the payment. |
| `2`, `62` | `PROCESSING` | Pending. |
| `64` | `COMPLETED` | Processed and sent to the other bank. Not for Hong Kong `FPS`. |
| `64` for Hong Kong `FPS` | `PROCESSING` | Not final. Waits for `69`. |
| `69` | `COMPLETED` | Completed. |
| `48` | `FAILED` | Returned. In Hong Kong, `resultCode` is `RETURNED`. Elsewhere it is `OTHERS`. |
| `10`, `11`, `12`, `44`, `46`, `72`, `75`, `102` | `FAILED` | Rejected or stopped. |
* Standard Chartered reports later statuses by notification.
* For some payment types, Acme also checks the status with Standard Chartered.
**Batch file: Batch payment**
1. **File sent**: payments are `SUBMITTED`.
2. **ACK1**: file checks.
3. **ACK2**: report with only `ACCP` or `PDNG` rows. Not final.
4. **ACK3**: report with any row other than `ACCP` or `PDNG`. Final for `ACCP`, `ACSP` and `RJCT` rows. `PDNG` rows wait.
| ACK | Bank status | What it means | Acme payment status | Webhook |
| --- | --- | --- | --- | --- |
| Any ACK | `RJCT` (file) | Standard Chartered rejected the whole file. | `FAILED` | `payments.failed` for each payment. `payment-batches.rejected` when the file has no status for each payment. |
| Any ACK | `PDNG` | Pending. | `SUBMITTED` | None |
| ACK2 | `ACCP` | Accepted. Not final. | `SUBMITTED` | None |
| ACK3 | `ACCP`, `ACSP` | Final acceptance. | `COMPLETED` | `payments.succeeded` |
| ACK3 | `RJCT` | Standard Chartered rejected the payment. | `FAILED` | `payments.failed` |
**Approval at the bank**
* Set up with Standard Chartered in Straight2Bank.
UOB Singapore and Malaysia
Single payments by API and batch payments by file. See the [UOB Singapore guide](https://docs.tryacme.com/guides/uob-sg-payments) and the [UOB Malaysia guide](https://docs.tryacme.com/guides/uob-my-payments).
**API: Single payment: Singapore**
1. **Submit answer**: final on `000000` or a rejection.
2. **Status checks**: debit notification, status enquiry, then transaction history search.
| UOB code | Acme status | What it means |
| --- | --- | --- |
| `000000` | `COMPLETED` | UOB made the payment. |
| A code UOB lists as rejected, an HTTP 4xx, or a request never sent | `FAILED` | UOB rejected or never received the payment. |
| A pending or unknown code, or no answer | `SUBMITTED` | Acme checks with UOB for about 2 days. Then Acme's team confirms the result. |
| UOB has no record of the payment after repeated checks | `FAILED` | UOB did not receive the payment. |
| UOB credits the debit back | `FAILED` | The payment did not go through. |
**API: Single payment: Malaysia**
1. **Submit answer**: final on `000000` or a rejection.
2. **Status checks**: status enquiry, with transaction history and debit notifications to confirm UOB has no record.
| UOB code | Acme status | What it means |
| --- | --- | --- |
| `000000` | `COMPLETED` | UOB made the payment. |
| `U000`, `U002`, `U999`, `TM9998`, `TM9999`, `ER9998`, `ER9999`, or no code | `SUBMITTED` | Not final. Acme checks with UOB. |
| No answer, or an HTTP 5xx | `SUBMITTED` | Acme checks with UOB for about 2 days. Then Acme's team confirms the result. |
| Any other code, an HTTP 4xx, or a request never sent | `FAILED` | UOB rejected or never received the payment. |
| UOB has no record of the payment after repeated checks | `FAILED` | UOB did not receive the payment. |
**Batch file: Batch payment: Singapore, and Malaysia MY_IBG, MY_RENTAS, MY_IAFT and TT**
1. **File sent**: payments are `SUBMITTED`.
2. **ACK1 to ACK4**: each payment is final on its first `ACCP` or `RJCT`.
| ACK | Bank status | What it means | Acme payment status | Webhook |
| --- | --- | --- | --- | --- |
| Any ACK | `RJCT` (file) | UOB rejected the whole file. | `FAILED` | `payments.failed` for each payment, and `payment-batches.rejected` |
| Any ACK | `RJCT` | UOB rejected the payment. | `FAILED` | `payments.failed` |
| Any ACK | `ACCP` | UOB accepted the payment. Final. | `COMPLETED` | `payments.succeeded` |
| Any ACK | Any other code | Not applied. | `SUBMITTED` | None |
**Batch file: Batch payment: Malaysia MY_DUITNOW and MY_IBFT**
1. **File sent**: payments are `SUBMITTED`.
2. **ACK1**: UOB received the file.
3. **ACK2**: file checks.
4. **ACK3**: accepted. Not final.
5. **O1 result file**: final.
| ACK | Bank status | What it means | Acme payment status | Webhook |
| --- | --- | --- | --- | --- |
| ACK1 | `RCVD` | UOB received the file. | `SUBMITTED` | None |
| ACK2, ACK3 | `RJCT` | UOB rejected the whole file. | `FAILED` | `payments.failed` for each payment, and `payment-batches.rejected` |
| ACK3 | `ACTC`, `ACCP` | Accepted. Not final. | `SUBMITTED` | None |
| O1 | Result `0` | The payment cleared. | `COMPLETED` | `payments.succeeded` |
| O1 | Result `1` | The payment did not clear. | `FAILED` | `payments.failed` |
**Approval at the bank**
* Files are sent straight-through or as interoperability files. Acme sets this for your organization.
* Approval rules in UOB Infinity are set up with UOB.
Zand UAE
Single payments only, by API. See the [Zand UAE guide](https://docs.tryacme.com/guides/zand-ae-payments).
**API: Single payment**
1. **Submit answer**: final on `COMPLETED`, `PROCESSED`, `REJECTED` or `REVERSED`.
2. **Zand notification**: final.
| Zand status | Acme status | What it means |
| --- | --- | --- |
| `INITIATED` | `PROCESSING` | Zand is processing the payment. |
| `COMPLETED`, `PROCESSED` | `COMPLETED` | The payment is done. |
| `REJECTED`, `REVERSED` | `FAILED` | Zand rejected the payment, or reversed it before it completed. |
| HTTP error, no answer, or an answer Acme cannot read | `FAILED` | Zand may still have made the payment. Contact Acme before you retry the payment. |
* Acme does not check the status with Zand. If no notification comes, the payment stays `PROCESSING`. Contact Acme to confirm the result.
**Approval at the bank**
* Set up with Zand.
### ISO 20022 status codes [#iso-20022-status-codes]
Many banks use ISO 20022 status codes:
| Code | Meaning |
| --- | --- |
| `RCVD` | Received |
| `ACTC` | Accepted after technical checks |
| `ACCP` | Accepted after customer profile checks |
| `ACSP` | Accepted, settlement in process |
| `ACSC` | Accepted, settlement completed |
| `ACWC` | Accepted with changes, for example a new date |
| `PDNG` | Pending |
| `PART` | Some payments in the file accepted |
| `RJCT` | Rejected |
When a bank rejects a whole file (`RJCT` at file level), every payment in the batch usually moves to `FAILED`. Some banks also report each payment in a rejected file. The outcome can then differ by payment.
### Batch file acknowledgements at a glance [#batch-file-acknowledgements-at-a-glance]
For batch payments, each bank sends acknowledgement files (ACKs) for the file it receives. An acceptance is final only in the ACK this table names. A rejection can come earlier, except that CIMB applies a payment rejection only in PSR-2 or later, and Standard Chartered only in ACK3.
| Bank | ACK sequence | Final acceptance comes in |
| --- | --- | --- |
| ANZ Australia | pain.002 status files | Any status file (`ACSP`) |
| CIMB Singapore | PSR-1 to PSR-10 | PSR-2 or later |
| Citibank | FILE → TXN | TXN (`ACSP`) |
| DBS Singapore | ACK1 → ACK2 → ACK3 | ACK3 |
| Deutsche Bank Singapore | One status file | The status file |
| HSBC | ACK1 → ACK2 → interim ACK2 (after approval in HSBCnet) → ACK3 and/or ACK4, by payment type | ACK3 or ACK4, by payment type |
| Maybank Singapore | ACK → RTN | RTN |
| OCBC Singapore | ACK1 or NACK1 → ACK2 or NACK2 → RET | RET |
| Standard Chartered | ACK1 → ACK2 → ACK3 | ACK3 |
| UOB Singapore and Malaysia | ACK1 → ACK2 → ACK3 → ACK4 | The first ACK with `ACCP` for the payment |
| UOB Malaysia `MY_DUITNOW` and `MY_IBFT` | ACK1 → ACK2 → ACK3 → O1 | O1 |