Confirmation page pattern

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.

Status: v0.1.0 — Draft. Promoted from the GOV.UK parity scan (metadocsstack #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

Element Required Notes
Confirmation panel Yes Full-width success-colored panel; large heading stating the outcome ("Application complete")
Reference number Recommended Inside or directly under the panel; visually prominent and selectable; the user's claim check
Follow-up notice Recommended "We have sent a confirmation to {email}" when a message was dispatched
What happens next Yes A short ordered/unordered list of concrete next steps + timeframes
Secondary actions Optional Print/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).