MPR - Multiple Partial Refunds

Multiple Partial Refunds (MPR) lets a merchant submit several partial refund requests while DEUNA sends one accumulated refund to the processor. It is the DEUNA-managed compatibility mode for connections that cannot receive multiple refund operations or whose refund processing requires aggregation.

MPR is configured per payment-processor connection. It is different from processor-native multiple refunds: with native support, each eligible refund can be sent to the processor independently; with MPR, non-final requests remain buffered in DEUNA until the sequence closes.

MPR lifecycleAsk Athia about this#

1. Start from a payment with a confirmed refundable amount, such as processed, captured, or partial_captured.
2. Submit a partial refund amount.
3. DEUNA validates the request against the cumulative refundable balance and buffers it without calling the processor.
4. While one or more refund amounts are buffered, the payment is partial_refunding.
5. DEUNA closes the sequence when one of these conditions occurs:
   • The cumulative requested amount reaches the full refundable amount.
   • A request includes "final_refund": true.
   • The saved refund cutoff is reached.
6. DEUNA sends the accumulated buffered amount to the processor as one refund operation.
7. If the confirmed amount returns the full refundable balance, the payment becomes refunded. If it returns only part of that balance, it becomes partial_refunded.

A buffered request records refund intent; it does not prove that funds were returned to the customer.

Refund cutoff and time limitsAsk Athia about this#

The MPR refund cutoff has these rules:

• Configure a whole number from 1 through 45 calendar days.
• The clock starts when the first non-final refund is buffered.
• DEUNA saves an absolute refund_cutoff_at timestamp. Later partial refunds do not extend or reset it.
• The deadline is the end of the target calendar day, not the same clock time a fixed number of days later.
• 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 submit the accumulated refund. Processing is not guaranteed at the exact final second of the day, so do not rely on a grace period for another merchant refund.

For example, with a one-day cutoff, a first non-final refund buffered on Monday is eligible for cutoff processing after the end of Tuesday. It is not scheduled for exactly the same time on Tuesday.

Close the sequence through the APIAsk Athia about this#

Use final_refund to submit the current request and all previously buffered amounts without waiting for the cutoff. Send it as a JSON boolean:

{
  "amount": 100,
  "reason": "Item returned",
  "final_refund": true
}

Reaching the full refundable amount also closes the sequence automatically; final_refund is not required in that case.

Amount and sequence rulesAsk Athia about this#

• The cumulative requested refund amount cannot exceed the confirmed refundable amount.
• DEUNA includes prior buffered refunds when validating every new request.
• A final refund operation closes the MPR sequence. Later refund requests for that sequence are rejected.
• DEUNA does not impose a request-count limit on buffered MPR requests. The refundable balance and cutoff are the effective platform limits.
• Do not calculate the remaining balance from the last response alone. Use the latest payment, its operation history, and confirmed amounts, especially when requests can overlap.
• If capture activity is still pending, refund eligibility is connection-specific. Do not refund an unconfirmed amount unless DEUNA has approved concurrent capture-and-refund behavior for the connection.

Status and failure handlingAsk Athia about this#

If cutoff processing or the processor call fails, do not mark the payment as refunded locally. DEUNA can retry eligible cutoff work, while repeated unresolved failures require operational review. Retrieve the payment and consume webhooks until the operation reaches a confirmed status. A timeout alone is not a final refund result.

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

Configure MPRAsk Athia about this#

Work with your DEUNA TAM to configure the connection:

In the Admin, use the order detail and refund operation history to monitor buffered requests, the accumulated refund amount, the remaining refundable amount, and the scheduled cutoff when available.

MPC and MPR can be enabled on the same connection. Their capture and refund cutoffs are independent; updating one does not change the other.