Payment Failure Recovery

Recover a failed subscription payment by explaining the issue, updating the payment method, retrying safely, and showing access impact. This example brings Issue and Payment method together so account administrators can find the next task without losing context.

It includes representative records such as Payment failed and Update billing method. Use the screenshot to study the layout, then adapt its components and product states to your own design system.

Payment Failure Recovery
Use this template in Figr

Template facts

Screen

Form

Primary action

Retry payment

Pattern

Form

State

Default, loading, empty, error, permission, success

Design system

Configurable product UI theme

What this screen helps users do

Finance and operations teams need to retry payment while keeping amount due, attempts and exceptions visible. The interface should show what changed and who should act next.

Key elements

  • Main workspace: Issue gives users an obvious place to start.
  • Supporting view: Payment method keeps the related context close.
  • Primary action: Retry payment stays visible when people need it.
  • First signal: Amount due shows a useful value (1,240).
  • Second signal: Attempts gives additional context (2).
  • Sample record: Payment failed.
  • Next record: Update billing method.

States worth designing

  • Required field missing: say what changed, protect progress, and offer a clear next step.
  • Invalid value or incompatible data: say what changed, protect progress, and offer a clear next step.
  • Draft saved: say what changed, protect progress, and offer a clear next step.
  • Submitted for review: say what changed, protect progress, and offer a clear next step.
  • No permission to submit: say what changed, protect progress, and offer a clear next step.
  • Temporary save failure: say what changed, protect progress, and offer a clear next step.

Where this screen sits in the flow

Issue → Payment method → Retry payment → Review outcome

Patterns used

Form, Issue, Payment method, contextual actions, error recovery

Why these choices work

Show requirements beside fields and retain values after failed checks. Validate only the affected input and make the next step unmistakable.

Pay attention to issue and payment method. People need to distinguish Payment failed from Update billing method. Keep amount due visible, especially when a record changes owner or status.

Before this screen reaches handoff, verify keyboard focus, empty and permission states, and what happens after someone chooses “Retry payment”. Make error recovery as clear as the happy path.

Related screen examples to explore next: Invoice Detail, Cancellation Flow, Trial Expiry.

Start from this in Figr

Design a payment failure recovery screen inside our existing product. Use our current components, tokens and content language. Include Issue and Payment method views, credible records like Payment failed, and a clear “Retry payment” action. Use our product permissions and show loading, empty, error and success states. Keep the output editable in Figma.

Open Figr