Implementation guide · Payment Reconciliation
Partial Refunds: Original Amount, Fees and Remaining Balance
Reconcile multiple partial refunds against one captured payment, retaining unique references, pending amounts, fees and the remaining refundable balance.
Published Updated
Published by FxTrusts, a supplier of brokerage and prop firm technology. Prepared with AI-assisted research and drafting; reviewed against the cited public sources. Examples are illustrative. Product links describe our services.
Quick answer
Reconcile each partial refund as a separate modification of one captured payment. Track requested, pending, successful, failed and returned amounts separately. Check the provider's current refundable balance, earlier chargebacks or principal reversals, and unresolved refund commitments before authorizing another request.

Establish the original payment boundary
Use the original captured amount and currency, not the amount typed into a customer-service form or the processor's net settlement. Net settlement may already exclude fees or reserves. Confirm that the actual payment method supports partial and multiple partial refunds; Adyen explicitly documents this support as method-dependent. Inspect prior chargebacks and other principal reversals as well: a capture-minus-refunds total can exceed the provider's remaining refundable balance.
Keep a unique internal refund ID, the original PSP reference and the new modification reference. A customer request number can group a conversation, but should not replace each individual refund's identity. Store the business reason and approving policy version so the record explains why that amount was selected.
Sources for this section
- Adyen refund requests and outcomesdocs.adyen.com
Reserve capacity for requests in progress
Suppose a payment has $300 left to refund and two agents independently request $200. A screen showing the same balance to both agents cannot protect the invariant. The application needs a controlled transition that records the pending commitment before another request can consume the same capacity.
Database isolation and retry handling help preserve concurrent invariants; external API idempotency handles a different boundary. PostgreSQL documents that stronger isolation may require retrying an entire failed transaction. Do not interpret a database retry as permission to send a new independent refund to the processor. Preserve the original business operation identity while reconciling its external outcome.
Sources for this section
- PostgreSQL transaction isolationwww.postgresql.org
Explain the remaining balance and fees
Present completed refunds separately from pending commitments and disputed or reversed principal. Start from the provider's current refundable balance and reserve unresolved requests not already reflected in that balance; never subtract the same pending refund twice. Check open disputes against the provider's procedure before returning more money. Release a reservation only after a definitive outcome; an unknown result remains under investigation.
Refundable fees require their own policy. Do not subtract a processing fee from customer principal merely to make a settlement report balance. If a fee is returned, post the fee credit separately. If the original payment currency differs from settlement currency, reconcile refund principal in its original currency and conversion effects in the settlement ledger.
Worked example: two completed partial refunds
A fictional payment captured $500 and has no disputes, chargebacks or other principal reversals. Refund R1 successfully returns $120 and R2 returns $80. The provider confirms a remaining refundable balance of $300. A later $50 request is reserved locally but not yet reflected in that provider balance, leaving operational capacity of $250. If the original processor fee was $12 and the assumed contract returns none of it, that fee remains separate; it does not make the remaining customer principal $288.
| Measure | USD |
|---|---|
| Captured principal | 500 |
| Confirmed refunds | 200 |
| Locally reserved refund, not in provider balance | 50 |
| Available refund capacity | 250 |
| Original fee, tracked separately | 12 |
Implementation checklist
- Confirm method support, captured currency, current provider balance and prior disputes or principal reversals.
- Deduplicate requests using stable operation and modification identifiers.
- Reserve unresolved requests without double-counting commitments already reflected by the provider.
- Match success, failure or return evidence before releasing or closing a request.
Sources
These documents support the reference. Check the original publication for current requirements and the limits of its scope.
- Adyen refund requests and outcomesdocs.adyen.com
- PostgreSQL transaction isolationwww.postgresql.org
Continue with the broader guides
Connect this reference to platform selection and the wider operating workflow.
