Test a stored card token paying without card entry

The flow under test

Testing a stored card properly means proving two things the interface is supposed to not do, alongside the payment it is supposed to complete.

• The stored method is preselected - the shopper does not have to find it.
• No card number field is shown - asserted explicitly, because a component that falls back to full card entry has lost the entire benefit.
• The payment authorises - from the token alone.
• The token is named on the result - so the record shows which stored instrument was charged.

A drop-in that renders card fields anyway alongside a stored method still takes the payment successfully. Every positive assertion passes, and the feature is broken.

The test file

The second step is the whole point of the file. It pairs a badge assertion with the absence of the card number field, so both the promise and the mechanism are covered.

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

# Adyeen 13.3: Stored card reuse

Catalog objective: pay again using a previously stored card token.
Key assertion: the one-click payment succeeds without card entry.

## Verify the stored card is preselected
Verify "Stored payment method" is selected and "Stored card" reads "Visa ending 1111 · exp 03/30".

## Verify no card entry is required
Verify a badge reads "No card entry needed - paying with a stored token" and no card number field is shown.

## Pay with the token
Click "Pay €129.50" and verify a green banner titled "Payment authorised" appears.

## Verify the token was used
Verify the result shows "Method" of "Stored card", "Detail" of "Visa ending 1111 (token tok_8812)" and "Amount" of "€129.50".

The step ceiling is 40 rather than the 45 used on the card entry flows, matching a shorter journey with nothing to type.

Step by step coverage

Four steps, two of which assert things that should not be on the page.

Naming the token id in the final assertion is what makes the record auditable. A payment attributed to a stored card without identifying which one is not much of a record.

Running it

kane-cli testmd run tests/adyen/stored-card-reuse_test.md

The file needs no secret variables, since nothing sensitive is entered. That is a small but real advantage of testing the tokenised path.

Stored payment methods sit behind authentication, where saved profiles remove the repeated login. The Kane CLI introduction covers profiles and variables, and how assertions resolve against a live page covers the absence checks used here.