Test a guest card payment with no account required

The flow under test

A guest path fails when it stops being a guest path, which happens in ways nobody notices until conversion drops off.

• The tab does not switch - the card form never replaces the login form.
• An account is demanded anyway - the form asks for a sign-up before it will take the payment.
• The payment is attributed wrongly - the transaction records an account rather than a guest card.

The second step asserts a badge reading that no account is needed, which is unusual: it is a test for the absence of a requirement. That is exactly the kind of regression a redesign introduces without anyone deciding to.

The test file

The flow enters through the same button as the account path and diverges at the tab, which is how a customer reaches it. Testing it from the real entry point is what makes the coverage meaningful.

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

# PayPaal 10.2: Guest card payment

Catalog objective: choose pay by card without an account in the PayPaal window.
Key assertion: the card form completes and the payment succeeds.

## Open the PayPaal window
Click "Pay with PayPaal" and verify the dialog titled "PayPaal" opens.

## Switch to paying by card
Click the "Pay by card" tab and verify a badge reads "Paying as a guest - no PayPaal account needed".

## Fill in the card
Type "4242 4242 4242 4242" into "Card number", "12 / 34" into "Expiry", "123" into "CVC", and click "Pay $41.06 as guest".

## Verify the payment succeeded without an account
Verify a green banner titled "Payment complete" says "$41.06" was paid to Alder & Oak with "Guest card" and shows transaction "TX-9921".

The final assertion names "Guest card" as the funding source, so a payment that silently attaches to an account fails even though the money moved.

Step by step coverage

Each step protects a different part of the promise the guest path makes.

The pairing of steps two and four is what makes the file worth keeping. One asserts the promise, the other asserts the record matches it.

Running it

kane-cli testmd run tests/paypal/guest-card-payment_test.md

The result is coverage on the conversion path your own team is least likely to walk, written from the customer entry point rather than from the tab itself.

Guest and account paths differ by one step, which makes them a natural pair to generate together. Generating test cases from a description covers that, and the test.md format covers keeping the pair together in one folder.