Payment operations and recovery
Choose the next operation from payment state and preserve a reliable financial record.
Start from the current payment state
An order screen and a financial record serve different purposes. Keep fulfillment decisions separate from payment attempts, reversals and settlement. Use the gateway payment ID to connect those records. lifecycle
Choose the next operation
These documented operations have distinct prerequisites. Confirm the current record before constructing a request. Situation Next path Authorized payment ready for capture Capture the existing authorization. Unsettled payment to cancel Evaluate a void. Settled payment to return Evaluate a refund. Unknown result after interruption Investigate the existing attempt before initiating another payment.
Build a recoverable workflow
Recommended application controls should survive a browser refresh, delayed event or repeated background job. Record each intended financial action with an application attempt identifier. Persist gateway identifiers and the confirmed outcome. Keep ambiguous attempts visible to operations instead of marking them failed automatically. Deduplicate repeated events and serialize competing staff actions. Match gateway activity to your order ledger and processor settlement reports.
Support an investigation
Provide support with the merchant environment, redacted order reference, gateway payment ID, timestamps and observed result. Keep secret keys, raw card details and unrelated customer information out of support messages. Establish an owner for unresolved payments. Define who may approve refunds and voids. Test outage recovery and reporting access before the pilot.