Test a billing portal card update and the default that moves

The flow under test

Adding a card and making it the default are two operations, and a portal can perform the first while silently failing the second.

• The old default is established first - Visa ending 4242 carries the default badge before anything changes.
• The new card is added - through the dialog, with its own number and expiry.
• The confirmation is explicit - a banner naming the card and stating it was set as default.
• The old card gave up the default - the 4242 row now offers a "Make default" button instead of a badge.

That final assertion is the one that catches two cards both marked default, which is a state that renders fine and charges unpredictably. Checking only the new card would pass it.

The test file

The test establishes the starting default before touching anything, which is what makes the change provable rather than assumed.

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

# Stripey 9.4: Billing portal

Catalog objective: open the customer portal, update the card and verify the new default.
Key assertion: the new payment method is shown as the default.

## Verify the current default
Verify the "Payment methods" card shows "Visa ending in 4242" carrying a "Default" badge and "Current default" reads "Visa ending in 4242".

## Add a new card
Click "Add payment method" and verify a dialog titled "Add a payment method" opens, then type "4000 0566 5566 5556" into "New card number", type "09 / 30" into "New card expiry", and click "Add card".

## Verify the confirmation
Verify a green banner reads "Card ending in 5556 added and set as default."

## Verify the default moved
Verify "Visa ending in 5556" now carries the "Default" badge, "Current default" reads "Visa ending in 5556", and the "Visa ending in 4242" row now offers a "Make default" button instead.

The confirmation banner is asserted by its full text, including the last four digits, so a banner that fires for the wrong card fails the step.

Step by step coverage

Each of the four steps carries a distinct assertion about the same underlying state, which is the right structure for testing a transition.

Testing a transition means asserting both ends of it. A test that checks only where the state arrived cannot distinguish a clean move from a duplicate.

Running it

kane-cli testmd run tests/stripe/billing-portal_test.md

Kane CLI drives the portal dialog, the card fields and the resulting badges from the labels a customer reads, so nothing in the file depends on the portal's internal markup.

Billing portals sit behind authentication, which is where saved browser profiles save the most time. The Kane CLI introduction covers profiles and variables, and checking the UI before a pull request covers running this at review time.