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 CENTROlink or EKS
  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