Test Buy It Now checkout with a saved card

The flow under test

A one-click purchase has only four things worth asserting, and the value is in checking the price at each of them rather than at the end.

• The listing price and shipping - $129.99 with free shipping, which is the figure the buyer decides on.
• The payment method on file - Visa ending in 4242, shown before the purchase rather than assumed.
• The amount charged - $129.99 on the confirmation, matching the listing.
• The purchase record - the same item, the same amount, and the same card in the account history.

Checking the card before and after is what catches a purchase charged to the wrong saved method, which is a defect that produces a correct-looking confirmation and an incorrect charge.

The test file

The Buy It Now button is referenced with its price in the label, exactly as it renders, so a button showing a stale price fails on the click rather than on the total afterwards.

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

# eBid 6.2: Buy It Now checkout

Catalog objective: purchase a Buy It Now listing with saved payment.
Key assertion: order confirmation shows the correct item and price.

## Open a Buy It Now listing
Click "Studio Monitor Headphones" and verify the listing shows a price of "$129.99" and shipping of "Free".

## Confirm the saved payment method
Verify the buy panel shows "Paying with Visa ending in 4242".

## Buy it now
Click "Buy It Now - $129.99" and verify the page shows "Order confirmed" for "Studio Monitor Headphones" with a total paid of "$129.99".

## Confirm the purchase is recorded
Click "My eBid" and verify the purchases list shows "Studio Monitor Headphones" at "$129.99" paid with "Visa ••••4242".

Run the test with:

kane-cli testmd run tests/ebay/buy-it-now_test.md

The run

Four passes in 152 seconds. Confirming the saved payment method was the cheapest step at 23.2 seconds, since it is a single assertion on a page already loaded.

---
test: ../buy-it-now_test.md
status: passed
started: 2026-09-21T12:20:12.449Z
duration_s: 152
session_id: f785481f-b7dc-493e-8d95-5a1a83439f1a
---

# eBid 6.2: Buy It Now checkout - Result

## Open a Buy It Now listing ✓ passed (47.4s)
md5: 24ef456152e6e04eae44a94051a61fa3
Click "Studio Monitor Headphones" and verify the listing shows a price of "$129.99" and shipping of "Free".

## Confirm the saved payment method ✓ passed (23.2s)
md5: 5a12870d48decd6d4639f59f9d99ddf5
Verify the buy panel shows "Paying with Visa ending in 4242".

## Buy it now ✓ passed (37.2s)
md5: 8792cf4b0b6b9fb79fe739cb4f3720c5
Click "Buy It Now - $129.99" and verify the page shows "Order confirmed" for "Studio Monitor Headphones" with a total paid of "$129.99".

## Confirm the purchase is recorded ✓ passed (38.6s)
md5: 0a0252ac85639258b688d634763ff7ba
Click "My eBid" and verify the purchases list shows "Studio Monitor Headphones" at "$129.99" paid with "Visa ••••4242".

This run is dated 21 September, four days after most of the set. Re-running a file against a newer build is the whole point of keeping the test, and the result file carries its own timestamp and session id so the two runs stay distinguishable.

Reading the evidence

You end up with a revenue-path test that needs no card details, no fixtures and no maintenance beyond the day the listing price changes. It is cheap enough to run on every build.

Pair it with the offer flow, since the two share a listing page and diverge only at the action. Checking the UI before a pull request covers running both at review time, and Kane CLI in CI covers running them on every merge.