MPC - Multiple Partial Captures

Multiple Partial Captures (MPC) lets you authorize an amount once and capture it in several requests. Use it when fulfillment happens in stages, for example as tickets are confirmed, products ship, or service milestones are completed.

MPC is configured per payment-processor connection. The connection must support authorization and capture, and DEUNA must activate the appropriate operating mode for that connection.

To use MPC, integrate with Create Payments V2 and create the payment using authorization rather than automatic capture.

Choose an operating modeAsk Athia about this#

Online mode is only appropriate when the processor connection supports multiple captures natively. Offline mode is the DEUNA-managed compatibility mode and can also be selected for a processor with native MPC when the business needs batching.

Offline MPC lifecycleAsk Athia about this#

1. The payment reaches authorized.
2. Each non-final capture is validated against the remaining authorized amount and stored without calling the processor.
3. While one or more capture amounts are buffered, the payment is partial_capturing.
4. DEUNA closes the sequence when one of these conditions occurs:
   • The cumulative requested amount reaches the authorized amount.
   • A request includes "final_capture": true.
   • The saved capture cutoff is reached.
5. DEUNA sends the accumulated net capture amount to the processor as one capture operation.
6. If the confirmed total equals the authorization, the payment becomes captured. If the confirmed total is lower, it becomes partial_captured.

Closing a sequence below the authorized amount marks the DEUNA capture sequence as final. Later capture requests are rejected. Confirm with your DEUNA Technical Account Manager (TAM) how the remaining authorization is released by the selected processor.

Close the sequence through the API

Send final_capture as a JSON boolean, not a string:

{
  "amount": 100,
  "final_capture": true
}

The amount is the amount of this capture request. In offline mode, DEUNA adds it to the previously buffered capture amounts before sending the consolidated processor request.

Capture cutoff and time limitsAsk Athia about this#

The offline capture cutoff has these rules:

• Configure a whole number from 1 through 45 calendar days.
• DEUNA saves an absolute capture_cutoff_at timestamp for the payment. Treat that timestamp, when returned, as the source of truth rather than calculating the deadline locally.
• In authorization flows that establish the cutoff when authorization completes, the clock starts at authorization. If no cutoff exists yet, the capture flow establishes it when the first non-final capture is buffered.
• The deadline is the end of the target calendar day, not an exact number of 24-hour periods after the request.
• Later partial captures do not extend or reset the saved deadline.
• Changing the connection configuration does not rewrite a deadline already saved on an existing payment.
• When the saved cutoff is reached, the payment becomes eligible for the cutoff worker to close the buffered sequence. Processing is not guaranteed at the exact final second of the day, so do not rely on a grace period for another merchant capture.

Online MPC has no DEUNA capture cutoff. The processor's authorization validity period and capture limits still apply.

Amount and sequence rulesAsk Athia about this#

• The cumulative capture amount cannot exceed the authorized amount, after any reversals that affect the available balance.
• Reaching the full authorized amount automatically makes the request final; final_capture is not required in that case.
• A final offline capture below the authorized amount requires the processor connection to support partial capture.
• After a final capture operation exists, DEUNA does not accept another capture for that sequence.
• DEUNA does not impose a request-count limit on buffered offline captures. The amount, cutoff, connection, and processor rules are the effective limits.

Always calculate fulfillment from confirmed amounts. A buffered capture is not money collected from the processor.

Status and failure handlingAsk Athia about this#

A timeout or accepted asynchronous request does not prove that the capture succeeded or failed. Retrieve the payment and process DEUNA webhooks until a confirmed status is available. A failed online capture preserves the previously confirmed payment state while the failed operation remains visible in the transaction history.

For the complete transition table, see Payment Workflow & Statuses. For overlapping requests, see Concurrent capture and refund.

Configure MPCAsk Athia about this#

Work with your DEUNA TAM to configure the connection:

In the Admin, use the order detail to monitor capture requests, the accumulated amount, the remaining authorized amount, and the saved cutoff when available. Activation, credentials, and processor limits can vary by country and connection.