> For the complete documentation index, see [llms.txt](https://specs.govstack.global/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://specs.govstack.global/service-patterns/2.-functional-patterns/make-a-payment.md).
# 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 "]
B --> C\["2. Are options or reductions applicable? "]
C -- Yes --> D\["2. Understand options and reductions "]
C -- No --> E\["3. Choose how to pay "]
D --> E
E --> F\["4. Review payment details "]
F --> G\["5. Authorise payment "]
G --> H\["6. Payment result"]
H -- Successful --> I\["7. See outcome and next steps "]
H -- Pending --> J\["7. Outcome: Pending "]
J --> K\["Send confirmation when resolved "]
H -- Failed / cancelled / expired --> L\["7. Outcome: Not completed "]
L --> M\["Retry or choose another method?"]
M -- Retry --> E
M -- Get help / alternative route --> N\["Offer support and non-digital routes "]
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}
" %}
Example user flow
### 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](/service-patterns/3.-step-patterns/outcome.md) 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.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://specs.govstack.global/service-patterns/2.-functional-patterns/make-a-payment.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.