Test the payment schedule after an order is placed

The flow under test

The outstanding balance is a derived figure, and deriving it wrongly is easy when one payment has already been taken.

• Order total - $180.00, the full value of the purchase.
• Outstanding - $135.00, which is the total less the payment taken at checkout.
• Payment one - $45.00, marked paid.
• Payment two - $45.00, marked scheduled rather than paid or overdue.

Asserting the badges alongside the amounts is what makes the balance verifiable. An outstanding figure of $135.00 with all four payments marked scheduled is arithmetically consistent and factually wrong.

The test file

The step ceiling is raised to 50 here, since the flow has to complete a full checkout before it reaches the surface it is actually testing.

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

# Klarnah 14.3: Payment schedule

Catalog objective: verify the placed order appears with its payment schedule.
Key assertion: the first instalment date and amount are correct.

## Place the order
Type "Priya Nair" into "Full name", type "4417" into "Last 4 of ID number", click "Continue with Klarnah", then click "Confirm and pay $45.00 today".

## Open the Klarnah app
Click "Open it in the Klarnah app" and verify the order card title reads "Studio Lamps · KL-3301".

## Verify the balances
Verify "Order total" reads "$180.00" and "Outstanding" reads "$135.00".

## Verify the first instalment
Verify the schedule table shows Payment 1 of 4 due "2026-09-15" at "$45.00" with a "Paid" badge, and Payment 2 of 4 due "2026-09-29" at "$45.00" with a "Scheduled" badge.

The order card is identified by both the product and the order reference, so the app opening on a different order fails immediately rather than producing confusing balance mismatches.

Step by step coverage

One setup step and three assertions, which is the right shape for a post-purchase flow.

A third of this run is setup. That is the normal price of testing anything post-purchase, and the strongest argument for automating it rather than clicking through a checkout by hand every time.

Running it

kane-cli testmd run tests/klarna/payment-schedule_test.md

Once the flow runs, the same file covers the schedule after any change to how instalments are generated.

Setup-heavy flows are the ones worth running unattended. Running flows asynchronously covers not waiting on them, and the test.md format covers the step ceiling used here.