Test a tip screen and the receipt that follows

The flow under test

Tip arithmetic is where a point of sale loses money in both directions, and it is worth asserting each figure rather than only the amount charged.

• The subtotal before any tip - $9.75 for two items, which is the base the percentage applies to.
• The tip itself - $1.95, which is twenty percent of the subtotal and not of some other figure.
• The total - $11.70, matching subtotal plus tip exactly.
• The receipt - the same tip and total again, alongside a payment id.

Asserting the tip as its own line, and not just the final total, is what catches a percentage applied to a post-tax figure. Both produce a plausible total and only one of them is what the customer agreed to.

The test file

The tip option is referenced by its percentage label and the assertions quote the resulting currency values, so the relationship between the two is pinned by the file rather than assumed.

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

# Squair 12.3: Tip and receipt

Catalog objective: complete a payment with a tip selection on the web POS.
Key assertion: the total includes the tip and a receipt is offered.

## Ring up a sale
Click "Oat Latte" and "Cardamom Bun" in the items list and verify the sale shows "Subtotal" of "$9.75".

## Go to the tip screen
Click the charge button and verify a "Add a tip?" screen appears showing "Subtotal" of "$9.75".

## Choose a tip
Click the "20%" tip option and verify "Tip" reads "$1.95" and "Total" reads "$11.70".

## Charge and verify the receipt is offered
Click "Charge $11.70" and verify a green banner says "$11.70" was charged including a tip of "$1.95", with a "Send a receipt?" card showing "Payment ID" of "pay_8813", "Tip" of "$1.95" and "Total" of "$11.70".

The final step checks the banner and the receipt card together, because a charge that succeeds without offering a receipt is a complaint waiting to happen at a counter.

Step by step coverage

Each step in the file establishes one figure that the next step depends on, which keeps any failure attributable.

The subtotal is asserted twice, on the sale and again on the tip screen. That is deliberate: a tip screen reading a stale or rounded subtotal is the most common way these numbers drift apart.

Running it

kane-cli testmd run tests/square/tip-and-receipt_test.md

Run it against a local build or a deployed POS with the same file. Nothing in it is environment specific except the starting URL in the front matter.

A point of sale is also the surface where a small rounding change ships without anyone noticing. Checking the UI before a pull request is where this belongs in a review cycle, and the test.md format covers the front matter options used above.