Subscribe to authorization and clearing webhook event types in your card issuing platform; for authorization events, parse the state (PENDING, CLEARED, DECLINED), the network_metadata, and the transaction token as the idempotency key
On receiving an authorization.created event, place a hold on the account for the authorized amount; do not permanently debit the account as the authorization may expire or be reversed
On receiving a clearing/settlement event (transaction.cleared or equivalent), apply the final debit using the cleared amount, which may differ from the authorized amount due to tip adjustment, currency conversion, or partial capture
Handle authorization reversal events: release the full hold immediately on reversal; for partial reversals, adjust the hold to the remaining authorized amount
Reconcile end-of-day: match each cleared transaction to its originating authorization by transaction token; any cleared transactions without a matching authorization indicate a silent authorization (force-post) and must be handled as a balance debit without a prior hold
Known gotchas
Authorization holds that are never cleared must be released after the hold expiry period (typically 7 days for most MCCs, up to 30 days for lodging/car rental); failing to release stale holds inflates apparent blocked balances
The cleared amount can be higher than the authorized amount for tip-eligible MCCs (restaurants); your hold logic must accommodate over-capture within card network tolerances (typically 20% for restaurant MCC)
Webhook delivery is at-least-once; implement idempotency on the transaction token to prevent double-debiting when duplicate events are delivered
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp