Test a credit decline and the fallback it offers

The contract this flow keeps

A decline has to do three things, and only the first is about the refusal itself.

• Refuse clearly - a banner stating the purchase cannot be approved.
• Reassure accurately - wording confirming this was a soft check and does not affect the credit score, which is a factual claim the business is making.
• Offer alternatives - card and bank transfer, named and described.
• Provide a route back - a control returning to the full payment options with everything still available.

The soft check wording is asserted because it is a statement about the shopper's credit file. Getting that sentence wrong is a compliance issue rather than a copy issue, and it is the kind of string that gets edited without review.

The objective in plain English

The declining identifier is the only difference between this file and the approval file. Everything else is the same flow, which is what makes the pair readable side by side.

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

# Klarnah 14.2: Credit decline fallback

Catalog objective: trigger a declined credit decision and verify the merchant fallback.
Key assertion: the shopper is returned to the other payment options.

## Fill the quick check with the declining id
Type "Priya Nair" into "Full name", type "0000" into "Last 4 of ID number", set "Date of birth" to "1992-04-18", and click "Continue with Klarnah".

## Verify the decline
Verify a red banner titled "Klarnah can't approve this purchase" says the decision is based on a soft credit check and does not affect your credit score.

## Verify the merchant fallback options
Verify an "Other ways to pay" card offers "Card - Pay the full amount now" and "Bank transfer - Pay from your bank account".

## Return to the payment options
Click "Back to payment options" and verify the "How do you want to pay?" card is shown again with both "Pay in 4 with Klarnah" and "Card" available.

The final step asserts that both payment options are available again, not merely that the previous screen reappeared. A checkout that returns with the declined method still selected has not recovered.

Assertion by assertion

The four steps track the shopper from the refusal back to a state where they can still pay.

Recovery is the part that carries revenue. A decline handled well converts at the card step; a decline handled badly ends the session.

Putting it in CI

kane-cli testmd run tests/klarna/credit-decline-fallback_test.md

Run this alongside the approval file rather than instead of it. The two together describe what the payment method actually does.

Declines are the unhappy path most worth covering because they are common and recoverable. Generating both paths from one description keeps the pair in sync, and checking the UI before a pull request is where a copy change to that disclosure should be caught.