ENGINEERING NOTE 28 / 50 · CARD
Match partial card refunds to their original charges
A refund belongs to a prior transaction, even when it arrives days later or uses a different event identifier. Preserve that relationship in the ledger and customer view.
Published by OPEN RAMBO. The engineering patterns and pseudocode illustrate designs, not a documented product API. Numerical examples are illustrative.
Use transaction references
Prefer explicit original-transaction references from the processing system. Matching only by amount and date can attach a refund to the wrong purchase. When references are absent, require a documented reconciliation path rather than silently guessing.
Track cumulative refunds
One charge can have several partial refunds. Deduplicate each refund event, then compare the cumulative amount against the eligible settled amount in the same currency. Fees and exchange adjustments may require separate entries rather than changing the original charge.
Explain the destination
Tell the customer which card or ledger received the credit and whether processing is complete. A merchant’s refund confirmation is not necessarily proof that the receiving ledger has posted it. Keep pending and completed states visibly distinct.
Illustrative implementation
net_purchase = settled_amount - sum(unique_completed_refunds)
# Match by original transaction reference, not amount alone.Acceptance check
Test two equal-value purchases and a partial refund for only one. The refund must remain attached to the correct original charge.