Concurrent capture and refund

DEUNA can serialize overlapping capture or refund requests for the same payment on supported flows. Serialization protects the cumulative amount calculation: after one request updates the payment, the next request is validated against the new balance.

What serialization guaranteesAsk Athia about this#

For a concurrency-enabled flow, DEUNA processes the balance-changing section of each request one at a time for the same payment. This prevents two overlapping requests from both validating against the same stale balance.

Serialization does not guarantee that every overlapping request succeeds. After the earlier request is applied, a later request can be rejected because:

• Its amount would exceed the remaining capturable or refundable balance.
• Cutoff processing has already finalized the MPC or MPR sequence.
• An earlier request finalized the capture or refund sequence.
• The payment status no longer permits the operation.
• The processor or connection does not support the requested partial operation.

Requests for different payments can still be processed independently.

Merchant integration guidanceAsk Athia about this#

• Use the existing capture and refund endpoints; there is no separate concurrency endpoint.
• Give each intended business operation its own request identity. A client retry and a second financial operation are not the same thing.
• Do not calculate the next amount from a cached status or a single response. Retrieve the latest payment and reconcile its operation history.
• Treat partial_capturing, capturing, partial_refunding, and refunding as unresolved states.
• Process webhooks idempotently and store operation identifiers and amounts, not only the payment status.
• If two requests race, handle a balance, cutoff, final-operation, or invalid-status rejection as an authoritative revalidation result. Do not retry it as a new financial operation without retrieving the payment first.

Scope and limitationsAsk Athia about this#

This behavior applies to supported capture and refund flows. It does not make authorization or void requests part of the same serialized partial-operation sequence.

Processor calls can still be asynchronous. Serialization protects DEUNA's balance update, but it cannot turn a processor timeout or pending response into an immediate final result. Wait for a confirmed status before fulfillment or customer communication.

For capture aggregation and cutoffs, see MPC — Multiple Partial Captures. For refund aggregation and cutoffs, see MPR — Multiple Partial Refunds.