SWIFT Payment Statuses

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.

How outbound statuses are determined

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.

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).

Statuses are pushed to you

Every status change - including the final outcome (Completed or Rejected) - is delivered as a Payment Status Change webhook.

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.

Outbound statuses

Success Flow
Error States

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

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

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).

Automatic confirmation
Manual confirmation
Cover method (COV)

Status	Description
`Completed`	Payment received and credited on receipt - a single webhook, no intermediate status

Completed (directly on receipt)

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

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

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

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} and read its statusReason.

Inbound status overview

Full flows with the confirmation messages sent back to the SWIFT network: Automatic confirmation / Manual confirmation.

Status-to-webhook map

Every status change of a SWIFT payment emits a 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

Webhooks are delivered with retries - treat them idempotently and upsert by trx_id + status. Cancellation progress arrives on a separate Payment Cancellation Status Change webhook.

Outbound payment flows

Standard
Returned by correspondent
Cancelled
Rejected

Create

You create the payment via the API. Status Created, webhook method=SWIFT, type=Payment.

Sent to clear

The message is forwarded to the SWIFT network and accepted for routing to the correspondent bank. Status Sent to clear.

Completed

Tracking via the SWIFT Frontend API confirms delivery to the beneficiary bank. Status Completed.

Created → Sent to clear → Completed

Payment sent

Same as the standard flow up to Sent to clear.

Return received

The correspondent bank returns the funds. The platform matches the return to the original payment by UETR.

Original completed

The original transaction is set to Completed (webhook type=Payment).

Return transaction created

A separate credit transaction is created for the returned funds, directly Completed (webhook type=Payment return).

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.

Payment sent

Same as the standard flow up to Sent to clear.

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.

Created → Sent to clear → Rejected

Status overview

API Reference

Get payment

GET /v3/payments/{id} - full payment details including statusReason

Next Steps

Cancel SWIFT payments

Stop a payment that should not go through

Statements

Reconcile with camt.052/053/054 statements

Getting Started

Integration Guide

Account Management

SEPA Instant/SCT

SEPA Direct Debit

SWIFT Payments

Payment Information

Investigations (Preview)

Nostro Accounts

Bank Information

Webhooks

How outbound statuses are determined

Outbound statuses

Inbound statuses

Hold reasons

Inbound status overview

Status-to-webhook map

What arrives when

Key payload fields

Outbound payment flows

Status overview

API Reference

Get payment

Next Steps

Cancel SWIFT payments

Statements

​How outbound statuses are determined

​Outbound statuses

​Inbound statuses

​Hold reasons

​Inbound status overview

​Status-to-webhook map

​What arrives when

​Key payload fields

​Outbound payment flows

​Status overview

​API Reference

Get payment

​Next Steps

Cancel SWIFT payments

Statements

How outbound statuses are determined

Outbound statuses

Inbound statuses

Hold reasons

Inbound status overview

Status-to-webhook map

What arrives when

Key payload fields

Outbound payment flows

Status overview

API Reference

Next Steps