Reverse Transactions

Release funds from a preauthorization before they are captured.

What You Learn
  • When to reverse an authorization instead of issuing a refund
  • Request fields for partial and full reversals
  • How reversals affect downstream settlement reports
  • Response fields to audit

When to Reverse

Reverse an authorization when:

  • The customer cancels before goods or services are provided
  • You need to replace a preauth with a new transaction
  • Only part of the original hold is needed (partial reverse)

Reversals happen before capture and therefore do not move funds. After a transaction is captured, use a refund.

Endpoint

POST /v1/payments/{transaction_id}/reverse
  • transaction_id – The preauth transaction ID
  • amount (optional) – Amount to release in minor units. Omit to reverse the full authorization.
  • event_id (optional) – Idempotency key

Request Example

POST /v1/payments/txn_123/reverse
Content-Type: application/json
X-Koard-Apikey: <your-api-key>

{
  "amount": 15000,
  "event_id": "reverse-15000"
}

Partial reversals: Ensure the requested amount does not exceed the remaining authorized balance. Use Incremental Auth to increase available funds if needed.

Response

The endpoint returns the updated Transaction object:

  • status transitions to reversed when the full amount is released.
  • reversed field reflects the total reversed amount in minor units.
  • Remaining authorization (if any) stays in authorized status until captured or reversed.

Follow-Up Actions

  • Capture the remaining authorized funds.
  • Issue a new Preauth if the transaction needs to restart.
  • Monitor status updates via webhooks.