# Receipt

> The receipt is the last screen of the checkout. It is shown when the submission was accepted — not when the money has arrived. Reaching this screen means the pa

The receipt is the last screen of the checkout. It is shown when the submission was accepted — **not when the money has arrived**. Reaching this screen means the payment was submitted, or an agreement was set up; whether it has been authorised, is still being confirmed, or was never a payment at all is what the status line at the top exists to say.

Your platform can skip the screen entirely (`skip_receipt`) and send the customer straight back to your own confirmation page.

### Where to find it

There is no way for a customer to navigate here on their own: the link carries the checkout session, so it works only for the customer who just paid.

The checkout arrives here from several places, and they are not equivalent:

| How they got here | What actually happened |
|---|---|
| A payment was submitted and the processor answered | A transaction exists. Its status decides the wording below — it may be settled, or still being confirmed |
| A payment was submitted and the processor has not answered | A transaction exists, unresolved. Nothing is known yet about the money |
| The customer returned from bank verification or a processor-hosted page | A transaction exists, completed on return; same as either of the above |
| An agreement was set up with nothing due today | No transaction at all. There is a contract, and the first collection is in the future |
| The customer reopened a checkout they had already paid | Nothing new happened. The form recognised the nonce and brought them here rather than taking a second payment |

A dropped connection does not bring the customer here. The screen is reached only when the submission returned; if the connection goes before that, the customer is left on the payment form, while the payment may well have been taken — see [When a payment is interrupted](/platforms/user-guides/checkout-checkout-interrupted/).

### What you see

- A **status line**, which is the only thing on the screen that says what actually happened. Every one of these is shown with a green tick, including the two that are not finished:

  | Line | What it means |
  |---|---|
  | **Payment Processed Successfully** | The processor approved it |
  | **Payment In Progress** | Submitted, not yet resolved. Either the processor has not answered, or it has answered pending and will settle later |
  | **Payment In Progress (action required)** | The customer has something left to do, such as approving in their banking app. The processor's instructions are shown underneath |
  | **Recurring Payment Created** | An agreement was set up. No payment was taken today |
  | **Schedule Created** | The same, for an agreement with an explicit list of charges |
  | **Payment Scheduled** | A single payment was agreed for a future date |

The payment lines and the agreement lines can appear together: a recurring agreement whose first collection is due now shows both.
- Any **mandate wording** the gateway requires the customer to see, for a bank debit agreement.
- Any **mandate wording** the gateway requires the customer to see, for a bank debit agreement.
- The **amount**, with the frequency for recurring agreements.
- The **date** the payment was taken, or the date the first payment is due for an agreement or a scheduled payment.
- The **number of payments** for a fixed-length agreement.
- The **reference** the customer should quote if they contact the merchant.
- The **payment method** used, shown as the card type and its last digits.
- The **description** of what was paid for.

### What you can do

| Control | What it does |
|---|---|
| **Copy to Clipboard** | Copies a plain-text summary of the receipt for pasting into your own system, one item per line; the exact content is listed under Things to note. Shown when a member of staff, rather than the customer, is completing the checkout. |
| **Done** / **Continue** | Closes the checkout and returns the customer to your page. The button reads "Continue" when your request supplied a page to send them on to. Not shown in embedded mode, where your page controls what happens next. |

### What exists at this point

The status line is also a fair description of what Shuttle now holds, which is worth knowing before you decide what your own confirmation page should say.

| | When it exists |
|---|---|
| **The payer** | Always. The checkout resolves or creates them before the form is shown |
| **The payment method** | Always. Whatever the checkout was for, it either took a payment or saved a method, and both record one |
| **The agreement** | Whenever a payment was involved — a one-off is an agreement with a single charge, so this is not only for recurring |
| **The payment attempt** | Only when something was due to be collected there and then |

That last row is the one that catches people, and there is a single rule behind it: **a payment is attempted while the customer waits only if a charge already exists and is already due.** Everything else follows from when the charges get created.

| What the checkout set up | Charges created then and there | Payment attempted now |
|---|---|---|
| A payment with no date on it | One, dated now | Yes |
| A payment with a scheduled date | None — the charge is raised when the date comes round | No |
| A recurring agreement with a start date | None — the first charge is raised at the start date | No |
| An agreement with an explicit list of charges | All of them, each on its own date | Yes, if one of them is already due |

Only the last of those creates charges ahead of time, which is why it is the only one other than a plain payment that can collect immediately.

The recurring case holds even if you back-date the start: a start date may be up to 48 hours in the past and still collects nothing at the checkout, because the charge is not raised until the scheduler reaches it. A scheduled date cannot be back-dated at all — the checkout refuses one less than a minute ahead.

So a customer can finish the checkout, see a green tick, and have no payment against their name yet. That is correct, and the status line says as much: "Payment Scheduled" rather than "Payment Processed Successfully".

### Things to note

- **What Copy to Clipboard copies.** For a payment: a first line reading **Payment Processed Successfully** followed by the amount and currency, or **Payment In Progress** while the payment is still being confirmed (with **(action required)** and the provider's message when the customer must complete a step); then **Date:** the date and time the payment was processed; **Reference:** the receipt reference; **Method:** the payment method as saved, for example the card type and last four digits; and **Reason:** the payment description, when there is one. For an agreement set up without an immediate payment: **Recurring Payment Created** followed by the amount, then **Start Date:** the date of the first charge, **Method:** and **Reason:** as above. Nothing else is copied: no customer details, no address, no full card number. If the browser does not allow copying, a prompt shows the same text so it can be copied by hand.
- **Pending payments.** Bank debits and some wallets settle later. The receipt shows the payment as submitted or in progress rather than successful, and the merchant is notified when it clears.
- **If the receipt cannot be loaded.** When the connection drops after the payment was taken, the receipt is rebuilt from the payment result so the customer still gets their reference.

### Related tasks

- Taking a payment
- Setting up a recurring payment