The final price must be complete before confirm
Aliases: all-in price · total due · payable total
What it is
Before “Confirm payment,” the screen must show one amount due: goods, known extras, already-applied discounts, summed, with currency. Completeness is not “fees appeared early”—early figures can still be estimates—it is a closed number before irreversible capture, with no “top-up after settlement.” It is also not how installment interest is unpacked; here the capture amount simply has to match the total the person saw.
Why it happens
Confirm shifts attention from comparison to execution; working memory holds one number. If the total hides in a disclosure, in fine print, or only after the handoff to an issuer, the press is an unclosed promise. If the issuer then adds a fee the merchant summary omitted, people think two systems are fighting, and later reconciliation fails. Completeness is three things at once: makeup (expandable), sum (the primary figure), and match to the button (“Pay ¥X,” not just “Pay”). Missing any one, people either freeze or discover a gap after the press.
Studying it
Vary completeness at confirm: sum visible but makeup collapsed, makeup visible but sum weak, final figure only after issuer redirect.
Independent variables: sum beside the button, makeup expanded vs collapsed, merchant vs issuer amounts match. Dependent variables: can they restate the amount due before confirm, post-pay disputes, cancels because “the numbers don’t match.”
Eye tracking can show whether the sum was fixated; fixation is not understanding makeup. Having people write the capture amount in their own words before the press is harder evidence than satisfaction. Do not treat “a line-item list exists” as transparency—long lists make people read only the sum, and a wrong sum is not saved by the list.
Where it stops holding
Auctions, bids, and floating FX may still be “about” at confirm; say settlement uses the fill or the capture-time rate, and give a cap. Subscriptions whose first capture differs from the recurring amount must show both, not only period one. Cash-on-delivery charges at receipt; the confirm page still owes the amount that will be collected. Dual-currency displays that are only a conversion must mark the capture currency so two numbers are not both read as due.
Applying it
- Pin the amount due in the confirm viewport, matching the button; list makeup expandable, with goods, extras, discounts, and total visible by default.
- Write the same total into the summary before issuer redirect; if the issuer will add a fee, include it on-site first or do not redirect.
- Recompute immediately when address or coupons change, and block submit on a stale total.
- Verify by covering everything but the sum and the button and asking how much will be captured; then reconcile success page and issuer statement. Three-way mismatch fails.