> ## Documentation Index
> Fetch the complete documentation index at: https://docs.finventi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SWIFT Payment Statuses

> What each SWIFT payment status means, how it is determined and which webhook events it produces.

Every SWIFT payment status change - outbound and inbound - is delivered to you as a webhook. **You never poll anything yourself.** For payments you send, the platform follows them across the SWIFT network via the **SWIFT Frontend API**; for payments you receive, the status is driven by the confirmation flow.

This page explains what each status **means** and which webhook events it produces. How webhooks are delivered - subscriptions, signature verification, retries - is covered once for all schemes in [Webhooks Management](/payments/integration-guide/webhooks-management).

## How outbound statuses are determined

<Steps>
  <Step title="Payment is sent">
    Once the payment message is accepted by the SWIFT network, the payment moves to **Sent to clear** and you receive a webhook.
  </Step>

  <Step title="The platform tracks the payment">
    The platform continuously tracks the payment on the SWIFT network using the **SWIFT Frontend API**, identified by the payment's **UETR** (Unique End-to-End Transaction Reference).
  </Step>

  <Step title="Statuses are pushed to you">
    Every status change - including the final outcome (**Completed** or **Rejected**) - is delivered as a [Payment Status Change](/payments/webhooks/payment-status-change) webhook.
  </Step>
</Steps>

<Note>
  The intermediate **Accepted** status is set when the debit is confirmed on the correspondent account statement. The final outcome comes from the SWIFT Frontend API tracking. **Accepted is not guaranteed**: if delivery is confirmed before the statement confirms the debit, the payment moves from `Sent to clear` straight to `Completed`.
</Note>

## Outbound statuses

<Tabs>
  <Tab title="Success Flow">
    | Status          | Description                                                                                           | Timing            |
    | --------------- | ----------------------------------------------------------------------------------------------------- | ----------------- |
    | `Created`       | Payment initiated                                                                                     | Immediate         |
    | `To sign`       | Awaiting approval (if configured)                                                                     | Until signed      |
    | `Signed`        | Approved, sent to correspondent                                                                       | Same day          |
    | `Sent to clear` | Delivered to SWIFT network                                                                            | Same day          |
    | `Accepted`      | Debit confirmed on the correspondent account statement. May be skipped if delivery is confirmed first | 1-2 business days |
    | `Completed`     | Delivery to the beneficiary bank confirmed via the SWIFT Frontend API                                 | 2-5 business days |
  </Tab>

  <Tab title="Error States">
    | Status      | Description                                                                                                        |
    | ----------- | ------------------------------------------------------------------------------------------------------------------ |
    | `Rejected`  | Any rejection coming from the SWIFT side - network validation errors, correspondent or beneficiary bank rejections |
    | `Cancelled` | Cancelled on your side (operator or API) before the message was submitted to SWIFT. Never set by SWIFT itself      |
  </Tab>
</Tabs>

## Inbound statuses

Payments you receive move through a shorter lifecycle - which path they take depends on your **confirmation mode** and on how the payment settles (direct or via a **cover**).

<Tabs>
  <Tab title="Automatic confirmation">
    | Status      | Description                                                                         |
    | ----------- | ----------------------------------------------------------------------------------- |
    | `Completed` | Payment received and credited on receipt - a single webhook, no intermediate status |

    `Completed` (directly on receipt)
  </Tab>

  <Tab title="Manual confirmation">
    | Status      | Description                                                                                                                                                                      |
    | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
    | `Accepted`  | Payment received and **held for review** - status reason `pending_review`                                                                                                        |
    | `Completed` | Operator completed the payment (funds credited) **or** returned it - a return still completes the original, and the refund goes out as a separate **Payment return** transaction |

    `Accepted (pending_review) → Completed`
  </Tab>

  <Tab title="Cover method (COV)">
    The payment instruction and the actual funds travel separately - the payment waits until the **cover settlement** arrives:

    | Status      | Description                                                                                                                                                                    |
    | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
    | `Accepted`  | Payment received, waiting for the cover - status reason `awaiting_cover`                                                                                                       |
    | `Accepted`  | Cover arrived. **Automatic mode:** skipped - the payment completes right away. **Manual mode:** the reason changes to `pending_review` and the payment enters the review queue |
    | `Completed` | Cover settled and payment credited (auto), or operator completed / returned it (manual)                                                                                        |

    Auto: `Accepted (awaiting_cover) → Completed`
    Manual: `Accepted (awaiting_cover) → Accepted (pending_review) → Completed`
  </Tab>
</Tabs>

### Hold reasons

While an inbound payment sits in `Accepted`, the **why** is carried by its `statusReason`:

| `statusReason`   | Meaning                                             | Cleared when                              |
| ---------------- | --------------------------------------------------- | ----------------------------------------- |
| `pending_review` | Held for operator review (manual confirmation mode) | Operator completes or returns the payment |
| `awaiting_cover` | Waiting for the cover settlement (COV method)       | The cover arrives                         |

<Note>
  **The webhook does not carry the hold reason** - it only says `Accepted`. To distinguish a payment held for review from one awaiting a cover, fetch it via [`GET /v3/payments/{id}`](/payments/api/accounts/get-payment) and read its `statusReason`.
</Note>

### Inbound status overview

```mermaid actions={true} theme={null}
stateDiagram-v2
  state "Accepted (pending_review)" as Pending_review
  state "Accepted (awaiting_cover)" as Awaiting_cover
  state "Completed (type=Payment return)" as Return_tx_Completed
  [*] --> Completed : Credited on receipt (auto mode, direct settlement)
  [*] --> Pending_review : Held for review (manual mode)
  [*] --> Awaiting_cover : Cover method - funds not yet settled
  Awaiting_cover --> Completed : Cover arrived (auto mode)
  Awaiting_cover --> Pending_review : Cover arrived (manual mode)
  Pending_review --> Completed : Operator completes or returns
  Completed --> Return_tx_Completed : If returned - separate Payment return transaction
  Completed --> [*]
```

Full flows with the confirmation messages sent back to the SWIFT network: [Automatic confirmation](/payments/integration-guide/swift/auto-confirmation) / [Manual confirmation](/payments/integration-guide/swift/manual-confirmation).

## Status-to-webhook map

Every status change of a SWIFT payment emits a [Payment Status Change](/payments/webhooks/payment-status-change) webhook. All SWIFT webhooks carry `method=SWIFT`.

### What arrives when

| Event                                                 | `status`             | `type`           | `direction`   |
| ----------------------------------------------------- | -------------------- | ---------------- | ------------- |
| Payment created via API                               | `Created`            | `Payment`        | `OUTBOUND`    |
| Held for signature (if signing configured)            | `To sign` → `Signed` | `Payment`        | `OUTBOUND`    |
| Message accepted by the SWIFT network                 | `Sent to clear`      | `Payment`        | `OUTBOUND`    |
| Debit confirmed on the account statement              | `Accepted`           | `Payment`        | `OUTBOUND`    |
| Delivery confirmed via the SWIFT Frontend API         | `Completed`          | `Payment`        | `OUTBOUND`    |
| Rejection received                                    | `Rejected`           | `Payment`        | `OUTBOUND`    |
| Inbound payment held (manual review / awaiting cover) | `Accepted`           | `Payment`        | `INBOUND`     |
| Inbound payment credited                              | `Completed`          | `Payment`        | `INBOUND`     |
| Return created (yours or correspondent's)             | lifecycle statuses   | `Payment return` | per direction |

### Key payload fields

| Field                 | Meaning for SWIFT                                                     |
| --------------------- | --------------------------------------------------------------------- |
| `trx_id`              | Transaction ID - use it to correlate with API queries                 |
| `end_to_end_id`       | End-to-end reference (`NOTPROVIDED` if you did not supply one)        |
| `type`                | `Payment` for the original, `Payment return` for a return transaction |
| `direction`           | `OUTBOUND` for payments you send, `INBOUND` for received ones         |
| `status`              | See the table above                                                   |
| `amount` / `currency` | Amount in minor units                                                 |

<Note>
  Webhooks are delivered with retries - treat them idempotently and upsert by `trx_id` + `status`. Cancellation progress arrives on a separate [Payment Cancellation Status Change](/payments/webhooks/payment-cancellation-status-change) webhook.
</Note>

## Outbound payment flows

<Tabs>
  <Tab title="Standard">
    <Steps>
      <Step title="Create">
        You create the payment via the API. Status **Created**, webhook `method=SWIFT`, `type=Payment`.
      </Step>

      <Step title="Sent to clear">
        The message is forwarded to the SWIFT network and accepted for routing to the correspondent bank. Status **Sent to clear**.
      </Step>

      <Step title="Completed">
        Tracking via the SWIFT Frontend API confirms delivery to the beneficiary bank. Status **Completed**.
      </Step>
    </Steps>

    `Created → Sent to clear → Completed`

    ```mermaid actions={true} theme={null}
    sequenceDiagram
      autonumber
      participant C as Your System
      participant P as Payments Platform
      participant N as SWIFT Network
      participant B as Correspondent Bank

      C->>P: Create SWIFT payment
      P-->>C: Webhook (Created, type=Payment, method=SWIFT)
      P->>N: Payment message
      N-->>P: Message accepted
      N->>B: Route to correspondent
      P-->>C: Webhook (Sent to clear)
      P-->>C: Webhook (Accepted)
      P->>N: Track delivery (SWIFT Frontend API)
      N-->>P: Delivery confirmed
      P-->>C: Webhook (Completed)
    ```
  </Tab>

  <Tab title="Returned by correspondent">
    <Steps>
      <Step title="Payment sent">
        Same as the standard flow up to **Sent to clear**.
      </Step>

      <Step title="Return received">
        The correspondent bank returns the funds. The platform matches the return to the original payment by **UETR**.
      </Step>

      <Step title="Original completed">
        The original transaction is set to **Completed** (webhook `type=Payment`).
      </Step>

      <Step title="Return transaction created">
        A separate **credit** transaction is created for the returned funds, directly **Completed** (webhook `type=Payment return`).
      </Step>
    </Steps>

    <Info>
      A return never moves the original payment to `Rejected`. The original ends `Completed`, and the returned money is a distinct **Payment return** transaction, so both the outgoing payment and the incoming return are visible and reconcilable.
    </Info>

    ```mermaid actions={true} theme={null}
    sequenceDiagram
      autonumber
      participant C as Your System
      participant P as Payments Platform
      participant N as SWIFT Network
      participant B as Correspondent Bank

      C->>P: Create SWIFT payment
      P->>N: Payment message
      N->>B: Route to correspondent
      P-->>C: Webhook (Sent to clear)
      B->>N: Return
      N->>P: Return (carries original UETR)
      P->>P: Match original by UETR
      P-->>C: Webhook (Completed, type=Payment)
      P->>P: Create credit transaction
      P-->>C: Webhook (Completed, type=Payment return)
    ```
  </Tab>

  <Tab title="Cancelled">
    <Steps>
      <Step title="Cancellation requested">
        Before or after sending you request cancellation. If the payment has not yet gone to the network, it is cancelled locally (status **Cancelled**). If already sent, a cancellation request goes to the correspondent.
      </Step>

      <Step title="Correspondent decides">
        Accepted: funds come back as a return (separate **Payment return** transaction; original completes). Rejected: the payment settles normally.
      </Step>

      <Step title="Webhooks">
        Cancellation progress arrives on the [Payment Cancellation Status Change](/payments/webhooks/payment-cancellation-status-change) webhook; transaction changes on the Payment Status Change webhook.
      </Step>
    </Steps>

    See [Cancel SWIFT payments](/payments/integration-guide/swift/cancellation) for the full flow.
  </Tab>

  <Tab title="Rejected">
    <Steps>
      <Step title="Payment sent">
        Same as the standard flow up to **Sent to clear**.
      </Step>

      <Step title="Rejection received">
        The network or correspondent rejects the payment (invalid/unknown BIC, insufficient funds, sanctions/compliance hit, formatting errors, regulatory restrictions). Status **Rejected**, webhook `type=Payment`.
      </Step>
    </Steps>

    `Created → Sent to clear → Rejected`

    ```mermaid actions={true} theme={null}
    sequenceDiagram
      autonumber
      participant C as Your System
      participant P as Payments Platform
      participant N as SWIFT Network

      C->>P: Create SWIFT payment
      P-->>C: Webhook (Created)
      P->>N: Payment message
      N-->>P: Message accepted
      P-->>C: Webhook (Sent to clear)
      N-->>P: Rejection (validation / compliance)
      P-->>C: Webhook (Rejected, type=Payment)
    ```
  </Tab>
</Tabs>

### Status overview

```mermaid actions={true} theme={null}
stateDiagram-v2
  state "Sent to clear" as Sent_to_clear
  state "Completed (type=Payment return)" as Return_tx_Completed
  [*] --> Created
  Created --> Sent_to_clear : Message accepted by the network
  Created --> Cancelled : Cancelled before submission
  Sent_to_clear --> Accepted : Debit confirmed on statement
  Accepted --> Completed : Delivery confirmed via SWIFT Frontend API
  Sent_to_clear --> Completed : Delivery confirmed first (Accepted skipped)
  Sent_to_clear --> Completed : Return received via UETR
  Sent_to_clear --> Rejected : Rejection received
  Completed --> Return_tx_Completed : Separate credit transaction (type=Payment return)
  Completed --> [*]
  Rejected --> [*]
  Cancelled --> [*]
```

## API Reference

<Card title="Get payment" icon="magnifying-glass" href="/payments/api/accounts/get-payment">
  `GET /v3/payments/{id}` - full payment details including `statusReason`
</Card>

## Next Steps

<CardGroup cols={2}>
  <Card title="Cancel SWIFT payments" icon="ban" href="/payments/integration-guide/swift/cancellation">
    Stop a payment that should not go through
  </Card>

  <Card title="Statements" icon="file-lines" href="/payments/integration-guide/swift/statements">
    Reconcile with camt.052/053/054 statements
  </Card>
</CardGroup>