Test a return recalculating the remaining instalments

Failure modes in this flow

The correct behaviour here is specific, and several plausible implementations get it wrong in ways that still balance.

The payment already taken stays at $45.00 and the remaining three absorb the whole reduction. An implementation that spreads the refund across all four produces a correct outstanding balance and an incorrect first payment, which is a reconciliation problem rather than a display one.

Writing the objective

The second step captures the schedule before the return, which is what turns the fourth step from a set of numbers into a verified transition.

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

# Klarnah 14.4: Return adjusts instalments

Catalog objective: register a return and verify the remaining instalments are recalculated.
Key assertion: the schedule updates to the reduced amount.

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

## Verify the schedule before the return
Verify "Order total" reads "$180.00", "Outstanding" reads "$135.00" and payments 2, 3 and 4 are each "$45.00".

## Register the return
Tick "Warm LED Bulbs (4 pack) - $60.00" in "Register a return", click "Register return", and verify a green banner reads "Return registered - your remaining payments have been recalculated."

## Verify the remaining instalments were reduced
Verify "Order total" now reads "$120.00", "Outstanding" reads "$75.00", a badge reads "Refund applied: $60.00", payment 1 is still "$45.00" and "Paid", and payments 2, 3 and 4 are each "$25.00".

The step ceiling is 55, the highest in this batch, because the flow completes a checkout, opens the management app and then performs the return before it asserts anything about the recalculation.

The assertions in detail

Two steps of setup and baseline, then the action, then the verification.

Seven separate values asserted against one action. That ratio is appropriate when the action redistributes money across a schedule the customer is contractually committed to.

Running it locally

kane-cli testmd run tests/klarna/return-adjusts-installments_test.md

This is the flow to run after any change to refund handling, since it is the one place where a rounding decision becomes a customer-visible instalment.

Money-moving recalculations deserve retained evidence. Evidence based QA for agentic runs covers what to keep, and deriving a suite from written requirements covers keeping the expected figures tied to their source.