Make a payment

Enable users to pay for a service securely and with confidence.

Use this pattern when:

• A service requires payment before completion or progression.

• Fees, fines, or charges are due to a government entity.

• Payment may be made online, in person, or on behalf of someone else.

• Payment outcomes may not be immediate.

Avoid this pattern for:

• purely informational services

• internal accounting or billing systems

• eligibility or fee calculation logic

Steps

1. Understand the payment requirement

Explain that a payment is required and provides context.

The user should understand:

• what the payment is for

• the amount (or how it is calculated)

• any deadline or due date

• whether payment is required now or can be deferred (some services allow payment in-person, for example on arrival for a hospital appointment)

• whether someone else can pay on their behalf

This step may come up in the service journey or be triggered by a notification, letter or a quotation.

2. Understand options and reductions (if applicable)

Explain conditions that affect payment before the user commits, to prepare them and avoid surprises later in the flow..

Examples:

• exemptions or reduced fees

• instalments or recurring payments (e.g. direct debit)

• pay now vs pay later

• online vs in-person payment

• if applicable: Refunds (possible if service fails or delivers a negative outcome)

3. Choose how to pay

The user selects a payment method or route. Use the choose option question type.

Examples:

• card

• bank transfer / faster payment

• invoice

• digital wallet

• direct debit

• in-person / kiosk

• payment by another person or organisation

• voucher/coupon

The user should understand:

• which methods are available here

• any restrictions (for example, international cards)

• what happens if a method fails

4. Review details before payment

The user confirms what they are about to pay and can go back to make any changes.

Must be clear:

• amount and currency

• who will receive the payment

• what will happen after payment

• high-level refund or adjustment expectations

Use the check answers step.

5. Authorise payment

The user authorises the payment using the selected method.

Design guidance:

• clearly signal when the user is leaving the service

• indicate when authorisation is in progress

• support save-and-return where possible

6. Handle payment outcome

The service receives the payment status and shows the user the result.

Make these details clear:

• the payment outcome whether successful, pending, failed, cancelled, or expired

• Receipt or reference, including tax receipt if applicable

• Whether the service can continue

• What to do if payment failed or is pending

Use the outcome step, and optionally send a notification for confirmation, receipt or reminder.

Outputs passed on

• payment status (success / pending / failed)

• payment reference or receipt

• timestamp and amount

• validation signal for service continuation

---

Considerations

• Users must be able to trust and verify that a payment request is legitimate.

• Failure is normal. Always offer retry, alternative methods, or support.

• Offer non-digital alternative routes such as in-person and assisted payments

• Enbale users who may need to leave and return before payment completes.

• Support early notification and reminders for due payments.