payment-idempotency

To prevent duplicate charges during gateway retries, enforce idempotency by using paymentId as the key. Store the initial response in a persistent data store and return that exact stored output when duplicate requests with the same paymentId arrive.

Payment idempotency ensures deterministic results on retries by caching responses and preventing reprocessing. A payment state machine manages valid transitions across Create Payment, Cancel, Capture, and Refund operations to enforce this behavior.

Handle requestId and cancellation retries by checking your persistent store for an existing paymentId before processing. Support gateway retry semantics within the 7-day window by preserving and returning the exact stored response for duplicate requests.

Yes, a persistent data store is required to implement idempotent payments. You must cache initial responses and use the store to return exact stored outputs when the same paymentId or requestId is retried, avoiding reprocessing.

The best way to ensure deterministic results for refund and capture operations is to apply idempotency across all endpoints using paymentId. Configure handlers to check for existing transactions and return exact stored responses on duplicates.

Your payment connector reprocesses duplicate requests because it lacks idempotency enforcement. Configure your payment handlers to check a persistent store for existing paymentId before processing and return the exact stored response on duplicates.