Test a hosted checkout session end to end

The flow under test

The amount is the only thing on a checkout page that has to be identical everywhere, and it is rendered from a different source at each stage.

• The order summary - Pro plan annual at $240.00, with a matching total due.
• The pay button - reads "Pay $240.00", which is the last figure a customer sees before committing.
• The success banner - a payment successful state rather than a silent redirect.
• The receipt - payment id, amount paid, card and a status of succeeded.

Asserting the pay button label is the cheap check most teams skip. A button showing a stale amount while the charge goes through at a different one is a dispute, and it renders perfectly.

The test file

The card details are entered by field label, and the final step asserts four separate receipt values in one instruction against a page that is already rendered.

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

# Stripey 9.1: Hosted checkout

Catalog objective: complete a Stripey Checkout payment with test card 4242.
Key assertion: the success page is reached and the amount is correct.

## Verify the checkout total
Verify the order summary shows "Pro plan - annual" at "$240.00" and "Total due" of "$240.00".

## Fill in the card
Type "4242 4242 4242 4242" into "Card number", "12 / 34" into "Expiry", "123" into "CVC", and verify the pay button reads "Pay $240.00".

## Pay
Click "Pay $240.00" and verify a green banner titled "Payment successful" appears.

## Verify the receipt
Verify the receipt shows "Payment ID" of "pi_3Qb101Mx03", "Amount paid" of "$240.00", "Card" of "Visa ••••4242" and "Status" of "succeeded".

Run the test with:

kane-cli testmd run tests/stripe/hosted-checkout_test.md

The run

Four passes with unusually even timings, between 26.2 and 30.9 seconds each, which is the profile of a flow where every step acts on a page that is already loaded.

---
test: ../hosted-checkout_test.md
status: passed
started: 2026-09-21T12:36:34.838Z
duration_s: 121
session_id: 720b1736-70d6-4c64-89aa-facba53b3598
---

# Stripey 9.1: Hosted checkout - Result

## Verify the checkout total ✓ passed (30.9s)
md5: eaae43fbe22739e5705feae60bc257ab
Verify the order summary shows "Pro plan - annual" at "$240.00" and "Total due" of "$240.00".

## Fill in the card ✓ passed (29.9s)
md5: d4f78bbd7f5dfb3f9f43df1d34be7a25
Type "4242 4242 4242 4242" into "Card number", "12 / 34" into "Expiry", "123" into "CVC", and verify the pay button reads "Pay $240.00".

## Pay ✓ passed (29.2s)
md5: bff1773807d73141c5e2f4d86cdee38f
Click "Pay $240.00" and verify a green banner titled "Payment successful" appears.

## Verify the receipt ✓ passed (26.2s)
md5: 20012cece5a225f27138d192329d09ca
Verify the receipt shows "Payment ID" of "pi_3Qb101Mx03", "Amount paid" of "$240.00", "Card" of "Visa ••••4242" and "Status" of "succeeded".

At 121 seconds this is one of the shortest payment flows in the set, because a hosted checkout is a single page and the test never navigates away from it until the receipt.

Reading the evidence

What you end up with is verification of a payment surface you do not own, in a file that takes two minutes to run and can go in front of every release.

Payment pages are also where test card data most often leaks into a repository. The test.md format covers passing values as variables instead, and running Kane CLI in CI covers keeping those values in pipeline secrets.