Test an online checkout link and the receipt it sends

The flow under test

The receipt is the part that matters after the payment, and it is the part most likely to be tested loosely.

• The link identifies itself - seller name, link id, item and amount, so the buyer knows what they are paying for.
• The payment completes - a confirmation naming the amount received.
• The receipt is specific - payment id, item and total paid rather than a generic thank you.
• The receipt reaches the right address - the email the buyer entered, echoed back on the confirmation.

That last assertion is unusual and worth keeping. Echoing the receipt address back to the buyer is what lets them catch a typo while they still care, and asserting it catches a form that sends the receipt somewhere else entirely.

The test file

The link is identified by its id as well as its amount, which matters because a seller may have several live links with the same price.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/square-clone-app/link?reset=true
max_steps: 40
tags: [square, payments, checkout]
---

# Squair 12.1: Checkout link

Catalog objective: complete a Squair checkout link with a test card.
Key assertion: the receipt page shows the correct amount.

## Verify the checkout link
Verify the page shows "KilnAndClay Studio" with the checkout link "chk_7K21", the item "Pottery workshop - single seat" and an amount of "$65.00".

## Fill in the details
Type "sam@riverfield.test" into "Email for receipt" and "4242 4242 4242 4242" into "Card number".

## Pay
Click "Pay $65.00" and verify a green banner titled "Payment complete" says the payment of "$65.00" was received.

## Verify the receipt
Verify the receipt shows "Payment ID" of "pay_8813", "Item" of "Pottery workshop - single seat", "Total paid" of "$65.00" and "Receipt sent to" of "sam@riverfield.test".

The item description is carried from the link through to the receipt and asserted in both places, so a payment that completes against a generic line item fails.

Step by step coverage

The four steps follow the link from what it claims to be through to what the buyer is left holding.

Asserting the item description on both the link and the receipt is what proves the description travelled with the payment rather than being regenerated.

Running it

kane-cli testmd run tests/square/checkout-link_test.md

The result is coverage on a payment surface with no fallback, checked through to the artifact the buyer keeps.

Links and invoices share most of their behaviour and differ in their lifecycle, which makes them a sensible pair to cover together. Generating the pair covers that, and evidence based QA covers retaining proof of a payment run.