Test an express checkout button and its approval window

The flow under test

The handoff is where express checkout fails, and it fails in ways that leave both sides looking correct in isolation.

• The amount changes across the boundary - the basket says one figure and the approval window asks for another.
• The merchant is wrong - the approval window names a different business than the one the customer is buying from.
• The return never happens - approval succeeds and the merchant page never learns about it.

The test asserts $41.06 on the basket and again inside the approval dialog, then a third time on the completion banner. Three assertions on one number is not redundant when the number crosses a trust boundary twice.

The test file

The approval window is described by what it shows, the merchant name, the amount and its two tabs, rather than by being a popup. The test does not need to know how the window was opened.

---
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.1: Express checkout

Catalog objective: pay on a merchant store via the PayPaal button and approve in the popup.
Key assertion: the popup approval returns and the order completes.

## Verify the basket
Verify the basket shows "Heavyweight Cotton Tee" and an "Order total" of "$41.06".

## Open the PayPaal approval window
Click "Pay with PayPaal" and verify a dialog titled "PayPaal" opens showing "Alder & Oak" at "$41.06" with "Log in" and "Pay by card" tabs.

## Log in and approve
Type "priya.nair@example.com" into "Email", type "demo1234" into "Password", and click "Agree and pay $41.06".

## Verify the order completed
Verify a green banner titled "Payment complete" says "$41.06" was paid to Alder & Oak with "PayPaal balance" and shows transaction "TX-9921".

The final assertion names the funding source as well as the amount, because a payment taken from a card when the customer chose a balance is a different transaction with different fees.

Step by step coverage

The value of the flow is in what each step proves about the boundary between the two sites.

Asserting the transaction id on the merchant page is what proves the two sides agree on a single payment rather than each believing something separate happened.

Running it

kane-cli testmd run tests/paypal/express-checkout_test.md

Because Kane CLI holds one browser session across the whole run, the popup and the merchant page stay connected in the same way they do for a customer.

Handoff flows are among the hardest things to cover in a conventional framework, which makes them worth the setup. How browser agents interpret a page is useful background, and the three modes covers running a multi-window flow interactively first.