Turning payment rejections into recoveries

The situation

Rejections already suck. Bad rejection messages add insult to injury. At Klarna, that wasn't just a feeling — it was a measurable problem: only around 32% of recoverable payment rejections were being recovered, and over two-thirds of all support inquiries traced back to a rejection in the first place. Behind the numbers were real customers, like the one who wrote in furious that they couldn't buy a birthday present because Pay in 4 wasn't available, signing off with "you're getting a £20 Pret voucher instead xxx."

Where the opening came from

An underwriting group was already focused on simplifying rejection criteria. We saw that as a genuine opening to take ownership of the content, not just clean up copy after the fact. Our role: define a new cross-company standard for rejection messaging. Our goal: help users understand exactly why they'd been rejected and what they could do about it, while staying empathetic rather than clinical.

Getting buy-in by roasting ourselves

Before asking anyone to change anything, we held a roast — put Klarna's own existing rejection messages up next to each other and let stakeholders see, in one glance, just how inconsistent and cold they'd become.

The root cause was visible the moment they were side by side. There was no standard, so individual teams had cobbled together their own rejection copy as they shipped. Which meant the highest-stakes content in the product — the moment we tell someone their money request is denied — was being written by people who had never written UX copy before, under deadline, with no guidance and no review. Not because they were careless, but because nobody had given them anything to work from.

Once it's framed that way, it stops being a copy problem and becomes an obvious systems gap. Nobody in the room defended the status quo, because nobody had chosen it.

While the underwriting team worked on simplifying the rejection logic itself, we ran research into how other lenders and BNPL providers handled the same moment.

Acceptance criteria before adjectives

With research and stakeholder buy-in in hand, we defined explicit acceptance criteria before writing a single rejection message — must-haves every message needed, signed off by the whole team, then used as a shared checklist to assess every draft. It's the habit borrowed from my product management work that shows up across this site: judge the content against criteria, not against opinion.

The criteria looked roughly like this:

Those last three criteria weren't ours alone to set — they came out of working with legal, accessibility and localisation partners, which is the part of this project I'd underestimated going in.

Filling out the template

Every rejection case got mapped against a single annotated template — heading, the updated plan on offer, available credit, next best actions, an educational note, legal copy where required, and CTAs — so the structure stayed identical even as the specific reason for rejection changed underneath it.

Here's what that produced once filled out for real rejection cases — the same underlying structure as the roast slide, but now doing the job properly.

The messages themselves

Here's what the standard produced across the most common rejection reasons. Each one is assembled from the same template slots, so the structure holds even as the reason underneath changes completely.

Illustrative examples in the pattern of the standard — representative of the structure and voice rather than the live production strings.

Read them together and the rules become visible

None of these messages is clever, and that's the point. What they share is more instructive than any single line:

• The heading states the outcome, always. Never a greeting, never an apology, never a question. A customer scanning at a checkout should be able to read six words and know where they stand.
• Every number the customer needs is present. £120 available, £185 order, £32.50 overdue, due 14 March. Vagueness in a rejection reads as evasion, even when it isn't.
• System failures are explicitly separated from customer judgements. Three of these messages contain a sentence whose only job is "this isn't about you." That sentence has no functional content and I'd fight to keep it in every one.
• The action verb in the button matches the action in the body. If the body says pay £32.50, the button says pay £32.50. Mismatches here are the most common cause of a customer not realising they can fix it.

And the words we banned outright

A short list, but it removed most of what was wrong with the originals:

Each one fails for its own reason. "At this time" implies a future it never specifies. "Unfortunately" makes the company the injured party. "Insufficient" and "ineligible" are underwriting words, not customer words. "Oops!" is cheerful about someone's money. And "your application has been declined" is worst of all, because most customers never thought they were making an application — they thought they were buying a jumper.

Making it scale past the design file

Figma was where all of this got designed, reviewed and agreed — it's where the roast happened, where the template took shape, and where the team critiqued every draft. What a design file can't do is act as a source of truth for engineering, for translation vendors, or for the next new rejection reason someone adds six months later. We moved the finished copy into a structured variables system — 29 distinct rejection reasons, each with its own named variable and approved text — so any team could reference the right message without re-writing it from scratch or drifting from the standard.

Rejection GPT

To keep the standard alive as new rejection copy got drafted, we built a small internal tool — nicknamed Rejection GPT — that took a task prompt asking for a copy revision plus a brief explanation for each change, and returned both in a structured table: the suggested rewrite, and the specific reasoning behind it, referenced against our own guidelines.

The partners who had to sign this off

Rejection copy is not a design decision a content team gets to make alone. Klarna is a regulated credit provider, which means the moment you tell someone they can't borrow money, the message stops being product copy and becomes a regulated communication. Three sets of partners shaped every message in the standard, and building those relationships early was as much of the work as the writing.

Legal and compliance

Consumer credit communications carry obligations that don't bend for tone of voice. Certain rejection reasons require specific disclosures. Some wording implies a formal credit decision — with the rights and follow-up that come attached — and some doesn't, so the difference between "we can't approve this" and "your application was declined" is a legal distinction as well as an emotional one. Language that hints a decision might change, or suggests a customer's creditworthiness in terms we can't substantiate, isn't available to us.

That's why the template treats legal copy as its own labelled slot rather than something woven through the message. It gave legal a single, consistent place to review — they could look at one component across 29 rejection reasons instead of auditing 29 bespoke screens — and it stopped mandatory wording from being quietly rephrased by whoever wrote the next screen. Reviews got dramatically faster once there was one thing to approve rather than a moving target.

Accessibility and comprehension

The B1 reading-level criterion wasn't a stylistic preference — it was an accessibility requirement in disguise, and it did double duty. Rejections arrive at a moment of high cognitive load: someone is at a checkout, or has just been told no about money. Comprehension drops exactly when precision matters most.

So the accessibility constraints were written into the acceptance criteria rather than checked at the end:

• B1 or below, so the message is comprehensible under stress and to the very large share of our customers reading in a second or third language.
• No idiom, metaphor or humour — the first things to fail for non-native readers, screen reader users, and anyone skim-reading.
• Reason and action in text, never in colour or icon alone, so the message survives being read aloud.
• Front-loaded meaning, because a screen reader user hears the first clause before deciding whether to keep listening.

Writing to a reading level is the single highest-leverage accessibility move available to a content designer, and it's the one most often skipped because it doesn't look like accessibility work.

Localisation

Every message shipped in 12 languages. That put a hard constraint on the source English: anything that lost its reason or its action in translation was a failed message, not a translation problem. "Your application didn't quite make the cut" is fine in a London standup and useless to a reader in São Paulo or Warsaw.

Softening language is the first thing to break in translation, and what survives is usually vaguer than what you started with — which defeats the whole standard. Writing plainly here wasn't a preference. It was the only way the reason arrived intact.

Principles for rejection copy

These are the rules the standard came down to. They're the checklist I still use whenever a product has to tell someone no — a declined payment, a failed verification, a rejected application.

The outcome

The number of recoverable rejections actually recovered doubled. Inquiries about payment rejections dropped 23% in the first month alone. Angry reviews and social posts about rejections became noticeably rarer. And — we can only hope — nobody's getting a consolation Pret voucher for their birthday anymore.