Test a dashboard payment lookup from charge to detail

The checks that matter

The test is really about search and indexing, not about the payment. The payment is created so there is something real to look for.

The index assertion is the one worth stealing. Checking the count on the dashboard after creating a payment proves the record reached the list, which is a separate operation from the payment succeeding and fails independently.

The same flow as a test file

The search assertion checks that a single row remains, not merely that the expected row is present. A filter that matches everything still contains the right answer.

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

# Stripey 9.5: Dashboard payment lookup

Catalog objective: find the latest payment in the dashboard and open its detail.
Key assertion: the payment detail matches the amount and the paid status.

## Take a payment first
Type "4242 4242 4242 4242" into "Card number", "12 / 34" into "Expiry", "123" into "CVC", click "Pay $240.00", and verify the receipt shows "Payment ID" of "pi_3Qb101Mx03".

## Open the dashboard
Go to https://my-testing-repo-main.vercel.app/stripe-clone-app/dashboard and verify the page subtitle reads "4 payments".

## Find the latest payment
Type "pi_3Qb101Mx03" into "Search payments" and verify a single row remains, showing "$240.00" with a "succeeded" status.

## Open its detail
Click "Open" on that row and verify the payment detail shows "$240.00", "Payment ID" of "pi_3Qb101Mx03", "Description" of "Pro plan - annual", "Payment method" of "Visa ••••4242" and a status of "succeeded".

Run the test with:

kane-cli testmd run tests/stripe/dashboard-payment-lookup_test.md

Run output

Four passes in 155 seconds. Opening the dashboard was the cheapest step at 17.8 seconds, the fastest single step across the whole set, because it is a navigation and a one-string assertion.

---
test: ../dashboard-payment-lookup_test.md
status: passed
started: 2026-09-21T12:44:42.817Z
duration_s: 155
session_id: 81f84f86-9bdf-401c-b7cf-4fa592698944
---

# Stripey 9.5: Dashboard payment lookup - Result

## Take a payment first ✓ passed (39.5s)
md5: 7c86b6503396501dec4014adf8a1e084
Type "4242 4242 4242 4242" into "Card number", "12 / 34" into "Expiry", "123" into "CVC", click "Pay $240.00", and verify the receipt shows "Payment ID" of "pi_3Qb101Mx03".

## Open the dashboard ✓ passed (17.8s)
md5: bf43df0b3f18691f4762f9b5e7db324f
Go to https://my-testing-repo-main.vercel.app/stripe-clone-app/dashboard and verify the page subtitle reads "4 payments".

## Find the latest payment ✓ passed (44.6s)
md5: 9d016c062ab293a90a63cff16d84c771
Type "pi_3Qb101Mx03" into "Search payments" and verify a single row remains, showing "$240.00" with a "succeeded" status.

## Open its detail ✓ passed (47.5s)
md5: de87d0640ff678e4d4ba69ad744cc439
Click "Open" on that row and verify the payment detail shows "$240.00", "Payment ID" of "pi_3Qb101Mx03", "Description" of "Pro plan - annual", "Payment method" of "Visa ••••4242" and a status of "succeeded".

The two search-related steps cost more than the payment itself, which is a fair reflection of where the risk sits. Creating a charge is well-trodden code; the list, the filter and the detail view are not.

Taking it further

You end up with coverage on the tool your support team depends on, including the indexing step that a payment-only test would never reach.

Internal tooling tends to be where coverage is thinnest and where an agent-written change is most likely to land unreviewed. Verifying agent-written code covers that loop, and Kane CLI as a QA agent covers building this into a wider suite.