Auth Reversal vs. Void
Two distinct operations for cancelling before settlement — what each actually does.
Both cancel a payment before settlement, but they are two distinct transaction types you choose between — not one endpoint that routes on timing — and they do mechanically different things.
AUTH_REVERSAL — release the hold at the issuer
A rails-level processor message (0420-equivalent) that actively releases the issuer hold.
| Property | Value |
|---|---|
| Wire | POST /api/v1/transactions with "type": "AUTH_REVERSAL" |
| Valid against | AUTHORIZED or CAPTURED parents, pre-settlement |
| Effect | The issuer is told to release the hold |
amount | Omit for a full reversal of the remaining hold; send one for a partial reversal |
| Use case | Customer cancels, order changes, authorization created in error — anywhere the cardholder's available balance matters |
A partial reversal (amount strictly less than the remaining authorized amount) leaves the parent AUTHORIZED for the remainder and records a PARTIAL_AUTH_REVERSAL child. Partial support is processor-gated — an unsupported processor declines through the normal decline_code surface.
VOID — cancel in the ledger only
An offline, ledger-only cancel. No processor message is sent.
| Property | Value |
|---|---|
| Wire | POST /api/v1/transactions with "type": "VOID" |
| Valid against | AUTHORIZED, or CAPTURED but not yet SETTLED |
| Effect | The transaction is cancelled on Cresora's books; the issuer hold expires on the issuer's own schedule |
amount | Ignored — lifted from the parent |
| Use case | Back-office correction where the hold's visibility to the cardholder doesn't matter |
How to choose
curl -X POST https://api.cresoracommerce.ai/api/v1/transactions \
-H "Authorization: Bearer csk_ab12cd34_xxxxxxxxxxxxxxxxxxxxxxxx" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: idem_$(uuidgen)" \
-d '{
"type": "AUTH_REVERSAL",
"merchant_id": "0190a1b2-c3d4-7e5f-8901-23456789abcd",
"parent_transaction_id": "0190d8a1-2b3c-7d4e-9f12-7a8b9c0d1e2f"
}'The response is a normal transaction object (transaction_id, state, …) — there is no reversal_type discriminator field, because you picked the operation.
- The cutoff is settlement, not the clock. Voidability is gated by "settled at processor", not by a same-day/next-day window. Once the parent is
SETTLED, the only remaining operation is a refund. - For customer-initiated cancellations, prefer
AUTH_REVERSAL— it is the operation that actually tells the issuer to release the funds. This matters most on debit cards, where the hold directly reduces available balance. - A
VOID's hold lingers until the issuer expires it on its own schedule (issuer-dependent, often days) — set expectations accordingly if you use it on customer-facing flows.