Payment method:
one component,
every dollar
AT&T collects.

The list, and the default that matters

For a returning customer, the component never opens as a form. It opens as a confirmation — the saved method is already chosen, named, and shown with its last four digits, with Change payment method as a quiet secondary link rather than a required step.

That in-page summary is the whole argument. Most people pay with the same card every month, so the default path should be reading one line and pressing Pay $1,000.00. Only the minority who need to switch ever open the full list.

When they do, the modal carries the states that decide whether a payment succeeds. A selected card gets a filled border and tint — not just a checkmark. An expiring card carries an amber warning icon and “Your card is about to expire!” inline, where the customer is choosing, rather than as a decline three days later. Card networks are shown by logo so the list is scannable by recognition instead of reading.

Two details worth naming. Long nicknames truncate rather than wrap, which keeps every row the same height and the list scannable at a glance. And Add a new payment method sits below a divider marked OR, deliberately separated from Continue and Cancel — it's a different kind of decision and shouldn't compete with committing to a choice already made.

The Norton Secured badge beside the label answers the trust question our FastPay research surfaced: customers hesitated at handing over financial details without visible reassurance.

Handing off without losing the customer

Adding a bank account is the hardest continuity problem in the component. The customer leaves our interface for a third-party verification partner — and if that handoff feels like being dumped onto another company's website, the payment doesn't happen.

So the handoff is designed, not defaulted. Every step here happens inside our modal, over our page, with our close control. The partner does the verification; we keep the frame.

The fork comes first. Before any credentials are requested, the customer chooses: Sign in to your bank for instant verification, or Enter details manually for anyone unwilling to hand bank credentials to a third party. Offering both is what keeps the reluctant customer in the flow instead of abandoning it.

Verification returns data, not a dead end. Routing and account numbers come back pre-filled and masked, and the only thing left is to name the account. The nickname field carries its own reason — “Please enter a nickname to save your bank details” — so the ask never feels arbitrary.

Back, not Cancel. The escape hatch returns to method selection rather than dropping the customer out of the payment entirely. Someone who opens bank entry and changes their mind is still trying to pay us.

The contextual message slot at the top of every step is deliberate component architecture: one reserved region rendering info, warning, or alert states — attempt limits, verification failures, maintenance notices — so those messages never get bolted on later in an inconsistent spot.

It doesn't always go well — and that's the design work

A payment component is judged on its worst day, not its best one. Cards expire. Deletions fail. Someone tries to remove the only method keeping their service on. None of that is exceptional — at this volume it's daily, and every one of these states had to be drawn, written, and specified rather than left to a generic error page.

The colour system does the triage. Amber means act soon — a card approaching expiry, still usable today. Red means act now — already expired, will not process. Green means done, nothing more needed. A customer scanning this list should know the severity before reading a single word.

Warnings live inside the row they describe. “Your card is about to expire!” sits under the card it belongs to, not in a banner at the top of the modal. Global banners get dismissed and forgotten; a warning attached to the object survives scrolling and still makes sense three cards down.

The last-card state is the one most teams miss. Deleting your only saved method isn't the same action as deleting one of five — so it gets different copy: “You have only one payment method saved.” Same button, materially different consequence, and the interface says so before the tap rather than after.

And when the system itself fails, the message stays useful: “We were not able to delete your card at this moment. You can try again now or later.” It names what happened, offers a next step, and keeps the confirmation in place so nobody loses their position in the flow.

The same component, six different jobs

The payoff of component work is only visible when you line up the contexts. Every screen here is the same payment method module — same Norton badge, same card summary, same Change payment method affordance — doing a materially different job each time.

What changes is the authority around it. A SplitPay payer sees Your balance and a fixed date, because they control one line and nothing else. An account holder sees Total balance, an account switcher and an editable date. An installment payoff adds reward points and a plan balance; TXT-2-PAY attaches the method to a text channel instead of a button. The component absorbs every one of those without forking.

That consistency is the product. A customer who learns to read the card summary once never relearns it — and because the pattern is shared, the expiring-card warning from the edge cases appears automatically in a flow nobody rebuilt to support it. Fix one state, improve every journey.