Ran into this on an order that split into two captures: warehouse shipped half the items same day, the rest three days later. Two captures against one authorization, both against the same PAN, same order ID on our side.
Customer canceled item two and asked for a refund. Sent a refund request for that amount, and the processor applied it against the first capture instead of the second, because we passed the original authorization reference, not a capture ID. Ledger on our side said item two was refunded. Processor's settlement report showed the refund reducing item one's capture. Numbers matched at the order level, so nobody would catch it until someone traced a specific item's refund status and got the wrong capture back.
Fixed it by storing capture IDs separately and always refunding against the specific capture, never the parent authorization. Some processors default to oldest-capture-first when you don't specify, some do it by remaining balance, and that behavior is rarely documented anywhere near the refund endpoint docs, usually buried in the capture section instead.
If your flow has multiple partial captures per order, are you tracking capture IDs independently for refunds, or trusting the processor to pick correctly?
