Skip to main content
This guide covers inbound payments - the ones you receive. In manual mode they are held for operator review before the beneficiary is credited - for institutions that must run sanctions, AML or KYC screening first. An interim confirmation is sent to the SWIFT network the moment the payment lands, so the Universal Confirmations deadline is always met while your operators take their time.
For outbound payments (the ones you send), see Payment statuses.
Who needs manual mode? Institutions that must screen inbound payments before releasing funds. If you credit on receipt, stay on automatic confirmation (the default).

How it works

1

Payment received and held

The inbound payment lands as Accepted and is held with the reason pending_review. The beneficiary is not credited yet. You receive an Accepted webhook (direction=INBOUND).
2

Interim confirmation sent immediately

ACSP/G002 - “accepted, credit pending internal review” - goes to the gpi Tracker at once, satisfying the confirmation deadline while the payment waits.
3

Operator review

Your operator reviews the payment in the PGW UI (or your system calls the review API) and chooses one of two actions.
4

Complete or Return

Complete: the payment is credited, moves to Completed, and the final ACCC confirmation is sent. Return: the funds go back to the sender - see the flow below.

Cover payments (COVE)

Some correspondents settle in two parts: the customer payment (pacs.008) only announces the transfer, while the actual money moves separately as a bank-to-bank cover transfer (pacs.009 COV). The payment must not be credited until the cover arrives - and in manual mode, not before the operator approves it either.
1

Payment announced, funds not yet in

The inbound payment lands as Accepted and waits with the reason awaiting_cover (visible via GET /v3/payments/{id}, not in the webhook). An interim ACSP/G004 confirmation (“awaiting cover”) is sent to the Tracker immediately.
2

Cover arrives - payment enters the review queue

The matching pacs.009 COV is matched to the waiting payment automatically. The payment switches from awaiting_cover to pending_review (readable via GET /v3/payments/{id}), an ACSP/G002 confirmation is sent, and you receive an Accepted webhook.
3

Operator decides

From here the flow is the same as for any held payment: Complete (final ACCC, status Completed) or Return (funds go back as a Payment return).

Returning a held payment

Instead of completing, the operator can return the payment to the sender - for example when a compliance review fails or the beneficiary account cannot be credited.
When the originating bank asks for the money back (an incoming camt.056), you respond through a separate flow - see Respond to cancellation requests.
1

Operator selects Return

A return reason is picked (free-text note required when the reason is NARR).
2

Original is completed first

The original inbound transaction moves to Completed - it is never left in a rejected state.
3

Separate return transaction

A distinct Payment return transaction is created and linked to the original, sending the funds back under the original payment’s UETR.
4

Tracked to completion

The return follows the standard outbound lifecycle (Created → Sent to clear → Completed, with Accepted in between when the statement confirms the debit first), tracked via the SWIFT Frontend API. Webhooks arrive with type=Payment return.

Return reasons

A payment that was already completed can be returned too - see Payment returns.

Webhooks

The webhook does not carry the hold reason - it only says Accepted. To distinguish a held payment (pending_review) or one awaiting cover (awaiting_cover) from a regular accepted payment, fetch the payment via GET /v3/payments/{id} and read its statusReason, or check it in the PGW UI. The payment stays in Accepted until the operator acts; the next webhook (Completed) tells you the outcome.

Switching to manual mode

1

Request the change

Ask your Inventi integration or account manager to enable manual confirmation for your tenant. It is a single configuration flag.
2

Takes effect for new payments

The change applies to payments received after the flag is set; in-flight payments are unaffected.
3

Reversible

You can switch back to automatic at any time.

API Reference

Review inbound payment

POST /v3/payments/{id}/review-action - COMPLETE or RETURN

Get payment

GET /v3/payments/{id} - read the statusReason (pending_review / awaiting_cover)

Next Steps

Automatic confirmation

The default mode - credit and confirm on receipt

Statements

Reconcile received funds
Last modified on August 5, 2026