Confirmation page pattern

patterns specs/patterns/confirmation-page.kmd

The receipt surface shown AFTER a user successfully completes a transaction or submission: a prominent success panel with a reference number, an explicit "what happens next" section, and confirmation that any follow-up (email/SMS) was sent. Closes the loop on a journey so the user knows it worked and what to expect. Modeled after the GOV.UK Design System "Confirmation pages" pattern.

When this pattern applies

Primary triggers

All triggers

Pattern — Confirmation page

Status: v0.1.0 — Draft. Promoted from the GOV.UK parity scan (meta/docs/stack #096). Live URL once rendered: kds.koder.dev/<locale>/patterns/patterns-confirmation-page.html. Source: https://design-system.service.gov.uk/patterns/confirmation-pages/

R1 — When to use

Use a confirmation page when a user completes a discrete transaction with a meaningful outcome the user may need to reference later: a submission, an application, a payment, a booking, a signature.

Do NOT use a confirmation page for:

  • Trivial, reversible actions (a saved setting → use a transient specs/components/snackbars.kmd).
  • Errors or partial success (→ specs/errors/user-facing-messages.kmd).

R2 — Anatomy

ElementRequiredNotes
Confirmation panelYesFull-width success-colored panel; large heading stating the outcome ("Application complete")
Reference numberRecommendedInside or directly under the panel; visually prominent and selectable; the user's claim check
Follow-up noticeRecommended"We have sent a confirmation to {email}" when a message was dispatched
What happens nextYesA short ordered/unordered list of concrete next steps + timeframes
Secondary actionsOptionalPrint/save (R5), give feedback, return to a dashboard

R3 — The confirmation panel

  • Uses the success semantic color from Verge tokens (never raw green); meets contrast for large text on the panel fill.
  • The heading states what was achieved in past tense, plain language ("Payment received", not "Success").
  • The panel is a distinct visual region, not a snackbar/banner (it is the page's primary content, persistent, not dismissible).

R4 — Reference number

  • Rendered as selectable text (the user can copy it); not inside an image.
  • Labeled ("Your reference number is HDX-4827-PLQ").
  • When the same value is emailed (R6 follow-up), the on-page and emailed values are identical.

R5 — What happens next

  • Always present, even when the answer is "nothing — you do not need to do anything else."
  • Concrete and time-bound where possible ("We will review within 5 working days and email you the outcome").
  • Links here open the relevant surface; this page itself does NOT offer a path back INTO the just-completed flow (the journey is done — see R7).

R6 — Email/SMS follow-up

  • State whether a follow-up was sent and to which (masked) destination.
  • If no follow-up is sent, do not imply one.
  • The follow-up content mirrors the on-page reference + next steps so the record survives the user leaving the page.

R7 — Navigation & history

  • The confirmation page is a journey terminus: it does not surface a "back" affordance into the completed flow, and re-submitting (browser back + resubmit) must be idempotent server-side (no double-charge / double-application — see policies/always-on.kmd idempotency).
  • A clear exit exists (to a dashboard / home), distinct from the flow.

R8 — Accessibility & i18n

  • On load, focus moves to the confirmation heading and the outcome + reference are announced (<h1> + live region) so non-visual users get the result immediately.
  • Success is conveyed in words, not color alone (WCAG 1.4.1).
  • All strings are separate i18n keys per specs/i18n/contract.kmd; reference numbers and dates are formatted per locale.

Não-escopo

  • The transactional backend (payment capture, application persistence).
  • Email/SMS template design (owned by the relevant product + brand).
  • Downloadable PDF receipts (optional product-level addition).

References