Test a 3D Secure challenge without breaking the payment

The flow under test

A 3DS flow has three distinct states and a test that only checks the last one cannot tell you which of the first two failed.

• The challenge is triggered - a dedicated 3DS test card produces a dialog rather than an immediate success.
• The challenge carries the right context - the amount and the card the bank is asking about, so a customer can recognise the payment.
• Approval returns cleanly - control comes back to the merchant page and the payment succeeds.
• The record says it was authenticated - a badge on the receipt, which is what shifts liability on a disputed charge.

The last point is commercial rather than technical. An authenticated payment and an unauthenticated one carry different liability, so a receipt that omits the badge is a finance problem even when the money moved.

The test file

The card number is the trigger. Using the 3DS test card rather than the standard one is what makes the challenge appear at all, and the rest of the file reads like any other checkout test.

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

# Stripey 9.2: 3DS challenge

Catalog objective: pay with a 3DS test card and approve the challenge.
Key assertion: the challenge completes and the payment succeeds.

## Use the 3DS test card
Type "4000 0025 0000 3155" into "Card number", "12 / 34" into "Expiry", "123" into "CVC", and click "Pay $240.00".

## Verify the challenge appears
Verify a dialog titled "3D Secure authentication" appears saying the bank needs to verify this payment, showing "Amount" of "$240.00" and "Card" of "Visa ••••3155".

## Approve the challenge
Click "Approve payment" and verify a green banner titled "Payment successful" appears.

## Verify the payment is marked as authenticated
Verify the receipt shows "Card" of "Visa ••••3155", "Status" of "succeeded" and a badge reading "3D Secure authenticated".

The dialog assertion names the amount and the masked card together, because a challenge showing the wrong amount is worse than no challenge: the customer approves a figure that is not the one being charged.

Step by step coverage

Each step in the file is doing one job, and the table below is the fastest way to see whether the flow covers what it should before you run it.

The assertions are written against visible text, so the file survives a change to the challenge dialog's markup. What it does not survive, correctly, is a change to the amount the customer is asked to approve.

Running it

kane-cli testmd run tests/stripe/3ds-challenge_test.md

Kane CLI resolves each sentence against the live page, so the challenge dialog is handled as an ordinary part of the flow rather than as a special case the script has to anticipate.

Authentication steps that need a real code are the usual reason a payment flow cannot be automated at all. The three Kane CLI modes covers when to run this interactively rather than headless, and running flows in CI covers the headless case.