Skip to main content

​
Cancel Payments When Plans Change

Sometimes payments need to be stopped — a customer changes their mind, duplicate payment detected, or wrong beneficiary details. Inventi handles the cancellation protocol with the beneficiary bank on your behalf.
What happens when you cancel a payment:
  1. You submit a cancellation request via API
  2. Inventi sends a camt.056 message through CSM
  3. The beneficiary bank accepts or rejects the request
  4. You receive the outcome via webhook
Cancellation is a request, not a guarantee. The beneficiary bank may accept or reject based on whether funds have been credited.

​
API Reference

Cancel Transaction

Initiate a cancellation request

Cancellation Status Webhook

Track cancellation lifecycle

Get Cancellation Request

Retrieve cancellation details

List Cancellation Requests

Search cancellation requests

​
How It Works

  1. You submit a cancellation request via API
  2. The platform creates a cancellation record and returns a cancellationId
  3. A camt.056 message is sent to the beneficiary bank
  4. You receive webhook updates as the request progresses
The beneficiary bank can:
  • Accept: Funds are returned, original transaction is cancelled
  • Reject: Original transaction proceeds normally
  • Refuse: Request cannot be processed
Never assume cancellation succeeded until the webhook indicates CANCELLATION_COMPLETED with an accepted status.

​
Initiate Cancellation

curl -X POST https://api.pgw-sandbox.finventi.com/v1/transactions:cancel \
  -H "Authorization: Bearer {token}" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_ids": ["trx_123456"],
    "reason": "CUST"
  }'

​
Cancellation Statuses

StatusDescription
CANCELLATION_CREATEDRequest initiated
CANCELLATION_IN_PROGRESSSent to beneficiary bank

​
Track Both States

Cancellation and transaction states are independent. Monitor both via webhooks.

Cancellation Accepted

Cancellation: ACCEPTED → COMPLETEDTransaction: CancelledFunds returned to you

Cancellation Rejected

Cancellation: REJECTED → COMPLETEDTransaction: CompletedPayment settles normally

​
Data Model

​
trx_id
string
required
Original transaction reference
​
cancellationId
string
required
Cancellation request identifier
​
cancellation_status
string
required
Track separately from transaction status
​
status_history
array
required
Append-only for audit

​
Integration Checklist

1

Handle cancellation webhooks

Upsert by cancellationId to track cancellation state separately from transaction state
2

Link cancellation to transaction

Maintain the relationship between trx_id and cancellationId in your database
3

Display states separately

Show cancellation progress independently from transaction status in your UI
4

Wait for completion

Only consider a cancellation final when the webhook indicates CANCELLATION_COMPLETED

​
What’s Next?

You now understand exception handling for outbound payments. Complete your integration with inbound exceptions and reconciliation:

Respond to Cancellations

Handle incoming cancellation requests

Return Inbound Payments

Return funds when you can’t credit the beneficiary

Track and Reconcile

Monitor transactions and reconcile with statements
Last modified on February 10, 2026