# 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.

#### Do not use this pattern for:

* internal accounting or billing systems
* eligibility or fee calculation logic

## Steps 

{% @mermaid/diagram content="---
config:
theme: redux
layout: dagre
-------------

flowchart LR
A\["Start: Payment required"] --> B\["1. Understand the payment requirement<br>"]
B --> C\["2. Are options or reductions applicable?<br>"]
C -- Yes --> D\["2. Understand options and reductions<br>"]
C -- No --> E\["3. Choose how to pay<br>"]
D --> E
E --> F\["4. Review payment details<br>"]
F --> G\["5. Authorise payment<br>"]
G --> H\["6. Payment result"]
H -- Successful --> I\["7. See outcome and next steps<br>"]
H -- Pending --> J\["7. Outcome: Pending<br>"]
J --> K\["Send confirmation when resolved<br>"]
H -- Failed / cancelled / expired --> L\["7. Outcome: Not completed<br>"]
L --> M\["Retry or choose another method?"]
M -- Retry --> E
M -- Get help / alternative route --> N\["Offer support and non-digital routes<br>"]
N --> E
I --> O\["Continue service / validate payment"]
K --> O

A@{ shape: rounded}
B@{ shape: rounded}
C@{ shape: diam}
D@{ shape: rounded}
E@{ shape: rounded}
F@{ shape: rounded}
G@{ shape: rounded}
H@{ shape: diam}
I@{ shape: rounded}
J@{ shape: rounded}
K@{ shape: rounded}
L@{ shape: rounded}
M@{ shape: diam}
N@{ shape: rounded}
O@{ shape: rounded}
" %}

<details>

<summary><strong>Example user flow</strong></summary>

<figure><img src="https://content.gitbook.com/content/u8moxPbFWK9pTxPYNIyh/blobs/t8xbUPnpCrxKzIkHPzww/Make%20a%20payment.png" alt=""><figcaption></figcaption></figure>

</details>

### 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.&#x20;

### 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. &#x20;

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.&#x20;

### 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&#x20;

The service receives the payment status and shows the user the result.&#x20;

Make these details clear:&#x20;

* the payment outcome whether successful, pending, failed, cancelled, or expired&#x20;
* 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](https://specs.govstack.global/service-patterns/3.-step-patterns/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&#x20;
* Enbale users who may need to leave and return before payment completes.
* Support early notification and reminders for due payments.