Ask which balance the customer actually has
Source facts: Stripe distinguishes cash balances from customer invoice balances. Cash represents funds available for payment; invoice balance represents a liability between the business and the customer, and can offset future invoices rather than fund a payment.[1] Editorial recommendation: start every support investigation with the balance type, customer identifier and currency, not the displayed total alone. A screen labeled simply ‘balance’ leaves operators guessing whether money has arrived or a billing adjustment was created. This guide addresses that classification problem, not general order reconciliation or stablecoin deposits. The cited rules describe Stripe, not a PayIn capability or a universal rule for payment providers.
Trace cash to bank-transfer funding
Source facts: Stripe adds an overpayment, or a bank transfer not automatically reconciled with an outstanding payment, to the customer cash balance. It can be used for later payments for the same customer or returned to that customer's bank account, up to the available amount.[1] Editorial recommendation: show the origin and intended customer alongside the available cash. For example, if a customer asks why a surplus remains after paying an invoice, first inspect the cash records rather than create another billing credit. This is an illustrative support scenario, not an observed incident. Avoid treating the two balance types as interchangeable merely because both reduce what an operator thinks the customer still owes.
Keep invoice adjustments out of the cash model
Source facts: invoice balance is an Invoices feature, and Stripe says its funds cannot be used for payment. An adjustment Customer Balance Transaction can update that invoice balance.[1] Editorial recommendation: label the action ‘invoice adjustment’ rather than ‘add cash’ and give it a separate confirmation screen. An operator correcting a billing error should be able to explain which future invoice is affected without claiming that a bank transfer occurred. Keep the internal reason and accountable operator with the adjustment. This proposed audit practice is editorial guidance; the cited page does not prescribe a specific approval policy, accounting treatment or record-retention period for every merchant.
Do not market the reconciliation layer as a wallet
Source facts: Stripe explicitly says cash balance is not a digital wallet or e-money, cannot be directly funded by the merchant, and is not a customer top-up balance. Its purpose is a reconciliation layer, limited to future payments or returns for the associated customer.[1] Editorial recommendation: review product copy before exposing a balance screen. ‘Available bank-transfer funds’ is more precise than implying a general-purpose wallet. Do not promise person-to-person transfers, arbitrary withdrawals or a stored-value product on the basis of this page. This is a product-scope boundary from Stripe documentation, not a legal conclusion about whether some other service requires a financial license.
Retain the currency boundary
Source facts: a customer can have cash balances in all currencies in which the merchant accepts bank transfers, each with its own funding instruction. Listing cash-balance changes returns changes across all of that customer's cash-balance currencies.[1] Editorial recommendation: display separate currency rows and carry the currency into exports, support tickets and action confirmations. A combined list of transactions is not evidence that the balances can be freely exchanged or summed into one spendable figure. Before acting on a request, identify the currency of the relevant cash record and payment. The source does not establish that every currency is supported for every merchant location; check product eligibility separately.
Check usable cash before making a payment
Source facts: Stripe instructs merchants to enable bank transfers before creating the intent. Its cash-balance payment example uses a PaymentIntent with payment method type customer_balance; the documented payment succeeds with sufficient cash and fails otherwise.[1] Editorial recommendation: do not use a nonzero invoice credit as the precondition for that cash payment action. Separate ‘cash available’ from ‘invoice adjustment exists’ in operator checks. If cash is insufficient, follow the applicable bank-transfer funding flow instead of inventing cash by editing invoice balance. This article is a conceptual operations guide, not runnable API code or a claim that a live payment was executed during research.
Read transaction types before closing the ticket
Source facts: a funded cash-balance transaction records bank-transfer funding. If funds are automatically applied to a payment, an additional applied_to_payment transaction represents that application. Stripe also documents unapplied_from_payment when a partially funded PaymentIntent is modified or canceled and money returns to cash balance.[1] Editorial recommendation: explain the observed sequence to the customer rather than translating every positive balance change into ‘new payment received.’ Record which balance changed, why, and whether the requested next action is still pending. Before release, test your own screens with separate cash, invoice-credit and mixed-currency examples. Those are proposed acceptance cases, not tests of Stripe or PayIn reported by this article.
Sources and dates
Verified on 2026-09-20. Source dates distinguish explicitly stated publication and update dates; an unspecified date does not mean the source was published today. This is public-document research, not a live payment test, security audit or accessibility certification. Vendor facts apply to the cited vendor; proposed workflows are editorial synthesis.
More new articles
A saved payment method is not blanket permission to charge later →
Choose payment currencies by separating the customer, the charge, and settlement →
All field guides →