Test paying an invoice and the status that has to flip

The flow under test

The status lives in two places and they are updated by different code, which is the whole reason this test goes back to the list at the end.

• The list says unpaid - established before anything changes, so the flip is provable.
• The detail matches the invoice - billed to, amount due and due date, so the right invoice is being paid.
• Payment completes - a banner naming the payment id.
• Both views agree - the detail badge reads paid, and so does the row in the list.

Navigating back to the list is the step that distinguishes this from a payment test. A detail page that updates while the list does not is one of the most common and most expensive inconsistencies in billing software.

The test file

The invoice detail assertion includes the due date, which is the field most likely to be wrong after a timezone change and least likely to be noticed.

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

# Squair 12.2: Invoice pay

Catalog objective: open an emailed invoice and pay it online.
Key assertion: the invoice status flips to paid.

## Open the unpaid invoice
Verify the "INV-2041" row carries an "unpaid" badge, then click "Open" on it.

## Verify the invoice details
Verify the page title reads "Invoice INV-2041" with "Billed to" of "Northwind Software · ap@northwind.example", "Amount due" of "$480.00" and "Due date" of "2026-09-22".

## Pay the invoice
Type "4242 4242 4242 4242" into "Card number", click "Pay $480.00", and verify a green banner titled "Invoice paid" names payment "pay_8813".

## Verify the status flipped
Verify the invoice status badge now reads "paid", then click "← All invoices" and verify the "INV-2041" row carries a "paid" badge.

The final step navigates back through the all invoices link rather than reloading, because that is the path a user takes and the one where a cached list would surface.

Step by step coverage

Each step pins one view of the same invoice, and the last one closes the loop.

Returning through the navigation a user would take, rather than reloading, is what exposes a list served from cache after an update.

Running it

kane-cli testmd run tests/square/invoice-pay_test.md

What you end up with is a receivables test that checks the number a finance team reads, not only the screen where the payment happened.

Any status that appears in both a list and a detail view deserves the same treatment. Checking the UI before a pull request is where this belongs in a review cycle, and Kane CLI as a QA agent covers building a billing suite around it.