Split tender needs amounts people can audit

What it is

Paying one order with balance + coupon + card, two cards, or gift card plus cash-on-delivery is split tender. People must see how much each leg takes, whether the legs sum to amount due, and how much remains. Auditable means each leg has a name, an amount, and a status, and the sum can be checked by head or calculator—not a single “combined payment” label.

Why it happens

A split turns one confirm into several authorizations; working memory must hold several numbers. If the UI only shouts “X left,” people do not know which leg will pay X, or whether the balance covers it. Auto-filling a leg (balance first) without showing it makes people expect the card to be charged in full. Partial success is worse: balance captured, card failed, the sum no longer equals due, yet the screen still says “paying.” Failed audit yields double authorization or underpayment. Fees belong on the leg that caused them, or the total matches while the parts do not.

Studying it

Use an amount that must split (balance short of due). Compare hidden auto-allocation, visible editable legs, and “amount left” only. Then fail one leg.

Independent variables: allocation visible, editable, failed leg freezes successful legs, submit blocked when the sum is wrong. Dependent variables: restating each leg, sum error at submit, wrong retry after partial success, reconciliation tickets.

Integer lab amounts understate audit failure. Live balances include pending holds; use a moving balance to catch display versus capturable mismatch.

Where it stops holding

Some rails refuse to share an order; reject the combination at selection rather than failing a split at submit. Subscription renewals usually cannot split a mandate. Expense-report cash vs invoice may require a single method; a split makes the receipt unbookable. A leg below a rail’s minimum should prompt a merge rather than mint a doomed authorization.

Applying it

• List each leg: name, amount, legal range; pin “allocated / due / remainder” at the top; remainder other than zero cannot submit.
• Write the auto-fill rule (balance then card) and let people edit each leg, recomputing immediately.
• On one-leg failure, mark which leg captured and which did not; do not fire the captured leg again.
• Verify by paying with balance plus card, covering help, and writing both amounts and the sum; then fail the card and ask what already captured and what pays next. Failure: parts do not add to due, or the captured leg is unclear.

Related

• Within the group: H7.04.1 Switching methods must not wipe the order · H7.04.2 Unavailable methods need a reason · H7.04.3 Default method from successful history, not platform preference · H7.04.4 Method surcharges belong at selection, not at settle · H7.04.5 Filter methods by region and currency before showing them
• Adjacent: H7.06 Payment failure · H3.13 Handling partial failure · H7.03 Price transparency
• Search terms: split tender · partial payment · gift card plus card