Your Upgrade Screen Hides the Total Until After the Card Number
Your Upgrade Screen Hides the Total Until After the Card Number
A trial user clicks Upgrade. They pick a plan. They land on a payment step that starts with "Card number." The total — the one fact they came to this screen to find — is a 12px gray line under the CVC field, or inside the button label, or nowhere at all.
They close the tab. Not because the price is wrong. Because they never saw it.
This is the most common thing we flag on in-app upgrade screens, and it's also one of the cheapest to fix. You don't add a step, a modal, or a screen. You move one block. Here's the flow moment, the case, the rewrite, and the fix list.
Where the money hides on an in-app upgrade screen
Most teams ship the same sequence:
- User clicks Upgrade inside the app.
- Plan picker: three cards, prices in a row.
- Payment step: a "Payment details" heading, then card number, expiry, CVC, then a button.
- The total shows up in the button label, or in small gray text under the CVC, or only in the confirmation email.
Why it happens is boring. The payment step gets built from a payment provider's embed or a template, and those components are designed to collect card data, not to answer "how much." The plan picker is treated as the pricing screen and the payment step is treated as "the form." So the number gets stranded on the wrong screen — or on no screen at all.
The result: your pricing page did its job, your plan picker did its job, and the buyer still can't answer the only question that matters at that moment.
What a trial user is actually asking on that screen
Three questions, in this order:
- What gets charged today, and how much? Trial days remaining, proration, tax.
- What gets charged later, and when? First full invoice amount and date, renewal cadence.
- What happens if I'm wrong? Cancel, downgrade, refund.
Card fields answer none of these. Every one of them is a clarity and trust problem, not a taste problem. If someone has to open a calculator, a pricing page, or a support chat to answer question one, you've added friction at the exact moment of highest intent — the second after they decided to pay you.
One trap worth naming: the plan picker price ("$49/mo") is not the answer. The answer is the number on the invoice they're about to authorize. Those are different numbers, and buyers know it.
The case: one team moved one block
This is a composite of upgrade screens we've reviewed — details changed, shape intact. It's the same shape almost every time.
Before: plan picker with three cards → payment step with card fields first, total buried below in small gray text. Button: "Start subscription."
The change: they took the total block that was already rendering below the card fields and moved it above them. That's it. No new step, no new screen, no redesign of the plan picker. They also made the button repeat the number.
After: the payment step opens with a two-line total block. Card fields sit below it. The button says the amount.
Trial-to-paid on that step moved enough that the team stopped arguing about plan card copy entirely. The mechanism is unglamorous: they answered question one before asking for a credit card. That's information hierarchy doing its job — the most decision-critical fact goes first, not last.
Nothing about the price changed. Same plan, same amount, same trial length, same cancellation policy.
If you want to know whether your upgrade screen has this specific defect before you touch anything, run a free audit on your upgrade flow and read the ordering flags first — they're usually the cheapest points on the list.
The rewrite, line by line
Here's the payment step, before and after. Same fields, same provider.
Before
Payment details
[ Card number ]
[ MM / YY ] [ CVC ]
Starts at $49/mo after your trial. Cancel anytime.
[ Start subscription ]
After
You're upgrading to Pro
Due today: $0.00
Your trial runs through Mar 14.
Then $49/mo starting Mar 15. Cancel anytime,
no email required.
[ Card number ]
[ MM / YY ] [ CVC ]
[ Start Pro — $49/mo after Mar 14 ]
Three things changed and nothing else:
- The total moved above the inputs, and it's a labeled amount, not a sentence fragment.
- The future charge got a specific date instead of "after your trial."
- The button repeats the number, so the last thing they read before clicking is the thing they'll be charged.
If you're upgrading mid-cycle rather than converting a trial, swap the top block for plain proration language: "$18.40 today, prorated for 11 days left in this cycle. Your next full invoice is $49 on Apr 1." Same principle — the buyer should never have to compute anything.
The P0/P1/P2 fix list for your upgrade screen
P0 — do these this week
- Exact amount due today, above the card fields.
- First full charge amount and date, on the same screen.
- Button label that repeats the amount.
- One line stating how to cancel or downgrade, without a support ticket.
P1 — next sprint
- Proration explained in plain language for mid-cycle upgrades.
- Tax/VAT note, or an honest "calculated at checkout" line if you can't show it yet.
- Saved card, Apple Pay, or Google Pay surfaced above manual entry for returning users.
- Error states that keep the total visible when a card is declined. A failed payment that wipes the price off screen is a second drop-off.
P2 — once the above is live
- Default the plan selection to the plan that matches the user's current usage, not your highest-ARPU plan.
- Replace the full feature comparison grid with a delta view: what changes from their current plan.
- A receipt preview so the post-purchase email isn't the first place they see a breakdown.
How to tell it worked without a real A/B test
Most small teams don't have the traffic for a clean split test on one step. You don't need one to know if the total moved the right way.
Instrument and compare a clean pre/post week:
- Drop-off between plan picker and submit. The primary number. If this doesn't move, nothing else matters.
- Time on the payment step. It should get shorter. People were spending that time hunting for a number.
- Visits to your pricing page during checkout. If buyers are tab-hopping to /pricing mid-payment, your total placement is still wrong.
- Support messages asking what they'll be charged. This one is free signal and usually shows up before the metric does.
- Repeated focus or clicks on the total line. Instrument it if you can. It tells you people are re-reading it, which is fine — they're confirming, not searching.
One caveat: keep the change isolated. If you move the total and rewrite the plan cards and change the trial length in the same week, you'll never know which one did the work — and you'll be back to guessing on the next iteration.
We've broken down other flow-level fixes like this on the FlowAudit blog if you want the pattern library rather than a single screen.
If you're still deciding what a fair monthly number even is before you fix the screen, that's a separate problem — sort that on your pricing page first, then come back and move the block.
Start a free FlowAudit on your own upgrade screen and you'll get a prioritized P0/P1/P2 list in minutes — the ordering and total-placement issues are usually the first two items, and they're the two you can ship today without touching your payment provider.