Published and sources checked: 2026-09-24. Scope: Stripe invoice overpayments that create customer invoice credit, using Customers v1 terminology. This is public-document research and an editorial operating procedure, not a live payment test.
The decision: is the excess still available to return?
A customer asks for the extra money back after paying an invoice twice or completing overlapping payment attempts. Do not start with the refund button. Stripe says multiple open payments can overpay an invoice; it automatically credits the excess to the customer’s credit balance in a transaction of type invoice_overpaid.[1] Returning money while leaving that credit available creates a double-benefit risk: the customer receives the refund and can also receive an invoice reduction. That risk is the operational implication of the documented credit and refund sequence, not a reported incident.
The narrow question is therefore not “does the invoice show an overpayment?” but “does the corresponding unused credit remain, and can we remove that credit before refunding?” Stripe’s example explicitly checks the customer’s invoice_credit_balance, subtracts the overpayment credit, and only then creates a refund.[1]
Build one case before changing either ledger
Recommended case fields are the customer, invoice, currency, account context, original payment identifiers, overpayment amount, originating credit transaction, existing refunds and owner. Record the requested outcome: retain credit or return the excess. This checklist is editorial guidance, not a Stripe-mandated approval policy.
Use invoice.overpaid as a trigger to inspect the invoice and use amount_overpaid to establish the excess amount. Stripe documents both in its overpayment refund example.[1] Treat the event as the beginning of an investigation, not permission for an unconditional refund. Inspect the payment history and match the proposed refund to an actual payment; do not confuse the entire invoice amount with the surplus.
Read usable credit, not an unsigned screen total
Retrieve the current invoice credit balance and inspect the transactions that explain it. The invoice balance automatically applies to the next finalized invoice, so a credit visible when the overpayment occurred may no longer be available when support handles the request.[2] Stripe’s example says not to refund the overpayment when the balance is insufficient because the credit might already have been applied to another invoice.[1]
Be careful with signs: negative invoice-balance values represent credit; positive values represent a debit, increasing the amount owed.[2] Do not translate the documentation’s prose about “less than the refund amount” into a raw signed-number comparison. As an implementation recommendation, compare the magnitude of available credit in the matching currency and reconcile its history. A total that includes unrelated goodwill credits does not by itself establish that this overpayment is unspent.
If the corresponding credit was already consumed, stop the automatic excess-refund path. Identify the receiving invoice and have the billing owner resolve the allocation before deciding on reimbursement. Do not manufacture a replacement credit, or silently refund only what remains, without an explicit reviewed decision. These are proposed exception controls; the cited documentation does not define a universal business policy for this case.
Remove the credit, then refund the excess
Stripe’s documented order is to adjust the customer balance and subtract the overpayment credit before creating a refund.[1] The invoice-balance ledger is immutable: undoing a transaction requires a corresponding reversing transaction. Stripe illustrates a 10 USD credit being reversed with a new 10 USD debit.[2] Thus, removing credit is not deleting its history and is not creating an additional credit note that grants more credit.
For a hypothetical case, a 100 USD invoice receives 120 USD in successful payments and produces a 20 USD overpayment credit. If the full 20 USD remains unused, the proposed controlled path records a 20 USD reversing debit and then a 20 USD refund against an eligible original payment. The numbers are an invented reconciliation drill. If another invoice has used 15 USD of that credit, a remaining 5 USD is not evidence that a 20 USD automatic refund is safe.
Handle the gap between adjustment and refund
The documented sequence is not a claim that balance adjustment and refund creation form one atomic operation. Recommended implementation controls include a single case owner, a durable record of each completed step, duplicate-action prevention, and a fresh balance review before execution. Coordinate competing billing jobs where your integration permits it; this guide does not claim a Stripe locking guarantee.
If credit removal succeeds but refund creation fails or its response is uncertain, inspect existing adjustment and refund records before retrying. Record “credit removed; refund unresolved,” not “refunded.” An exception owner should decide whether to complete the refund or restore credit with a traceable compensating entry after resolving the refund’s actual state. Blindly restoring credit while a refund can still complete recreates the original risk.
A customer invoice credit is also not proof that the merchant has funds to send a refund. Stripe refunds draw on the merchant’s available balance, excluding pending funds; insufficient balance leaves card refunds pending, while refunds for other payment-method types fail.[3] That is a separate downstream funding check. Do not issue a second reimbursement simply because the first refund remains unresolved.
Close the case with both outcomes reconciled
Recommended closure evidence links the original overpayment, its credit transaction, the reversing adjustment, and the refund’s current outcome. Customer communication should distinguish “credit removed and refund initiated” from a confirmed successful refund, without promising a bank-arrival date. Review unnecessary open payments to reduce recurrence: Stripe identifies canceling payments that are not needed as an overpayment-prevention measure.[1]
This guide is not a general comparison of cash balance and invoice credit, and it does not repeat the separate refund-funding investigation. Its release condition is narrower: the excess is still represented by available invoice credit, that credit is removed once, and the corresponding money-return action is tracked once.
Sources and limits
Checked 2026-09-24. Source publication dates are not stated; retrieval is not publication. Country, account, currency and payment-method eligibility need separate checks. No financial, legal, tax or refund-arrival assurance is offered.
- [1] Accept partial payments for invoices — Published: not stated; checked: 2026-09-24.
- [2] Customer credit balance — Published: not stated; checked: 2026-09-24.
- [3] Refund and cancel payments — Published: not stated; checked: 2026-09-24.