"To be paid" becomes "Payout balance." Explanatory text about the calculation logic is also added. No changes whatsoever to timing, amounts, or reserve conditions — purely a labeling improvement.
"To be paid" → "Payout balance." Aligned with the terminology used in Finance (the financial screens).
The calculation logic "payments − refunds − disputes − fees" is now readable in the on-screen help.
When a reserve is in place, the amount is shown separately with an explicit note that it is "temporarily held to cover disputes, refunds, chargebacks, and risk."
When a reserve is set on the account, the reserve amount is displayed on the Payouts page separately .
Disputes, refunds, and chargeback risk. Funds are held to cover payments if these occur.
| Item | Change | Details |
|---|---|---|
| "To be paid" label | Changed | → "Payout balance" (aligned with finance terminology) |
| Formula explanation text | Added | payments − refunds − disputes − fees is now readable on the screen |
| Reserve display | Explanation added | Amount is shown separately as before. Help text explaining "why it is being held" was added |
| Payout timing | No change | Payment cycle remains the same |
| Payout amount | No change | The calculation logic itself is unchanged |
| Reserve conditions | No change | Reserve rate and release conditions are unchanged |
Only the labels and help text on the Payouts page are changing.Calculation logic, payout behavior, and the amounts themselves are untouched. Backend processing is unchanged.
Whether Admin API / Payments API field names will change is not stated in the article.It's safest to read this as "labels only". If your integration depends on names like `to_be_paid`, double-check just in case.
The article notes "matching the language used across Finance." This reads as part of a broader effort to align terminology across multiple finance-related screens. For accounting staff who hop between several screens, it reduces explanation overhead.
Reserves are not included in Payout balance and shown separately. Since the "amount that won't be deposited" is easier to identify on screen, mismatches in expected payouts are less likely.
Stock questions from owners/accounting like "why this amount?" and "why isn't everything deposited?" become easier to self-resolve on screen.There's room to compress maintenance effort by lightly swapping out just these two topics in your ops docs and FAQs.