Test declined card recovery and the retry that follows

Failure modes in this flow

A decline can fail in three ways, and only one of them involves an error message that is missing.

• The error is not inline - the customer is bounced to a generic failure page with no way back to the form.
• The form is destroyed - fields clear or become read-only, so retrying means starting over.
• The retry is not recorded - the payment succeeds with no trace that an attempt failed first.

The second step exists only to check the form survived, which is the assertion that separates a recoverable decline from a dead end. It costs 25.3 seconds and it is the most valuable step in the file.

Writing the objective

The decline is triggered with a dedicated test card and the error is asserted inline, under the card number field, rather than anywhere on the page.

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

# Stripey 9.3: Declined card recovery

Catalog objective: attempt a payment with a decline test card, then retry with a valid card.
Key assertion: the error is surfaced inline and the retry succeeds.

## Attempt with the declining card
Type "4000 0000 0000 0002" into "Card number", "12 / 34" into "Expiry", "123" into "CVC", click "Pay $240.00", and verify an inline error under "Card number" reads "Your card was declined. Try a different card."

## Verify the form is still usable
Verify the "Card number", "Expiry" and "CVC" fields are all still present and editable on the same page.

## Retry with a working card
Replace the card number with "4242 4242 4242 4242" and click "Pay $240.00".

## Verify the retry succeeded
Verify a green banner titled "Payment successful" appears, the receipt shows "Amount paid" of "$240.00" and "Card" of "Visa ••••4242", and a badge reads "Succeeded after 1 declined attempt".

The final assertion includes a badge reading "Succeeded after 1 declined attempt", which is the part that proves the failed attempt was recorded rather than discarded. Run the test with:

kane-cli testmd run tests/stripe/declined-card-recovery_test.md

Running it locally

Four passes. The decline attempt was the slowest step at 45.4 seconds, since it fills three fields, submits and then waits for an error to render.

---
test: ../declined-card-recovery_test.md
status: passed
started: 2026-09-21T12:40:14.067Z
duration_s: 144
session_id: 93f57139-4a39-4e3a-86ea-36d5021c5312
---

# Stripey 9.3: Declined card recovery - Result

## Attempt with the declining card ✓ passed (45.4s)
md5: ebc52471f45c76fc5922be13001a15d5
Type "4000 0000 0000 0002" into "Card number", "12 / 34" into "Expiry", "123" into "CVC", click "Pay $240.00", and verify an inline error under "Card number" reads "Your card was declined. Try a different card."

## Verify the form is still usable ✓ passed (25.3s)
md5: ceccd04e0788ae3ca6420f9131f75a12
Verify the "Card number", "Expiry" and "CVC" fields are all still present and editable on the same page.

## Retry with a working card ✓ passed (29.1s)
md5: da59bd29039b0767bcf53fa4dea56e47
Replace the card number with "4242 4242 4242 4242" and click "Pay $240.00".

## Verify the retry succeeded ✓ passed (37.9s)
md5: 4a7cd3b38f2dc8df1908423dcc5d55e2
Verify a green banner titled "Payment successful" appears, the receipt shows "Amount paid" of "$240.00" and "Card" of "Visa ••••4242", and a badge reads "Succeeded after 1 declined attempt".

Putting it in CI

The outcome is coverage on the unhappy path that actually converts, including the audit trail that lets support explain a double attempt later.

Decline handling pairs naturally with authentication challenges, since both interrupt a payment mid-flow. Generating the variants covers producing one file per decline code, and evidence based QA covers keeping the proof.