Stripe's Oct 28 Release Gave Klarna, PayPal, and Afterpay Refunds a Reference Number. "Succeeded" Can Still Land Before the Customer Sees the Money.

A subscriber cancels, asks for a refund, and you process it through Stripe. Your dashboard says succeeded. Four days later they email support asking where their money is. Nobody did anything wrong — the refund is genuinely in flight — but until October 28, 2026, if that subscriber paid with Klarna, PayPal, or Afterpay/Clearpay, you had nothing to hand them except "it's processing." No trace number, no reference, nothing a BNPL app or a PayPal account could actually match against. Stripe's latest release closes that specific gap, and it's worth understanding exactly what it does and doesn't fix, because the fix is visibility, not speed.

Sixty percent sounds like a passing grade until you notice it was up from 45% just two years earlier — meaning as recently as 2019, well over half the dollar value of BNPL returns and disputes just evaporated rather than making it back to the customer. The CFPB called merchandise-return problems one of the top sources of BNPL complaints in that same report, and more than 13% of all BNPL transactions at the five largest providers it studied involved a dispute or a return in the first place. None of that is a Stripe problem specifically. It's the structural reality of a payment method where the money doesn't move the way a card refund does — and it's exactly the reality a cancellation flow is operating inside every time a BNPL-funded subscriber asks for their money back.

What actually shipped on October 28

Stripe's Refund object has a field called destination_details — a hash with one entry per payment method, each carrying a reference and a reference_status that can be pending, available, or unavailable. For a card refund, that reference has been available for years: an Acquirer Reference Number, System Trace Audit Number, or Retrieval Reference Number your support team can hand a customer so their own bank can locate the credit. A handful of local bank-transfer methods — EU, GB, US, Brazilian, Japanese, and Mexican bank transfers among them — got the same treatment earlier. On October 28, Stripe extended it to three methods that previously had none: Klarna, PayPal, and Afterpay/Clearpay.

Before that date, a refund issued through any of those three came back with an overall status — pending, succeeded, failed, or canceled — and nothing else. You knew whether Stripe's side of the process had gone through. You had no number to give a subscriber who wanted to go check their own Klarna or PayPal account and confirm it for themselves. That's not a cosmetic gap. It's the exact moment — a canceled subscriber, expecting money back, checking their own account and finding nothing yet — where a legitimate, in-flight refund turns into a support escalation or a bank dispute against a charge you already refunded.

Status and reference are two different clocks

The detail that matters most here is one Stripe's own documentation states plainly for card refunds, and it applies just as much to the three methods that joined this system on October 28: receiving the trace reference can take up to 7 business days after you initiate the refund, delivered separately through a refund.updated event, even on a method where the overall refund itself resolves faster than that. status tells you what Stripe's financial partners confirmed. reference_status tells you whether there's something concrete the customer's own bank or account will actually show them. Those are not the same signal, and treating a succeeded status as "the customer can see it now" is the assumption that generates the support ticket.

Afterpay is the sharpest case. Its refunds are explicitly asynchronous, take up to 10 business days, and — unlike a card refund — can't be canceled once submitted. For ten business days, a canceled subscriber has a Stripe-side status that may already read succeeded or pending and, until this release, literally nothing from their own Afterpay account to check against it. Klarna is a few days faster on paper but comes with its own hard stop: Klarna won't let you refund a payment at all once it's been escalated to a dispute, which means the window to get ahead of a confused, canceling subscriber with a real refund — before they call their bank instead — is the same window this reference field now helps you work inside of.

Refunds can also fail outright, not just run long

The other thing destination_details surfaces that's easy to miss: a network_decline_code field on several of these methods, including PayPal, Afterpay, BLIK, and Swish. That field only appears when the customer's bank or payment partner actively declines the refund — a real failure, not a delay. When it fires, the Refund object's status moves to failed, the money lands back in your Stripe balance, and Stripe's documentation is explicit that you're on your own for getting it to the customer: "you need to arrange an alternative way to provide your customer with a refund." A cancellation flow that marks a refund request as resolved the moment the API call returns a 200 will never catch this. It needs to be listening for refund.failed, the same way our piece on Stripe webhook reliability argues any billing-critical event needs a listener that isn't just "assume it worked."

That two-year improvement is real, but it still leaves 40% of disputed or returned BNPL value unaccounted for as of the CFPB's most recent published figure. Some of that is legitimately contested — returns the lender or merchant determined weren't valid. A meaningful share of it is also almost certainly refunds that were in fact issued and simply never got traced back to the customer's satisfaction, which is the exact blind spot a reference number is built to close. Stripe adding one for Klarna, PayPal, and Afterpay doesn't move the CFPB's number, obviously — but it gives any merchant running on Stripe a concrete tool against the part of that gap that's a visibility problem rather than a policy dispute.

What to actually change in your cancellation and refund handling

• Surface reference_status in your support tooling, not just status. A support macro that says "your refund shows succeeded in our system" is weaker than one that says "here's the reference number — your Klarna/PayPal/Afterpay account should show it within X business days." Build the second one once this field is populated, not the first.
• Set method-specific expectations at the moment of cancellation, not after a ticket comes in. If your cancellation flow already offers a refund as part of the exit (the policy question we cover in your refund policy at cancellation), the confirmation screen should state the real window for the payment method on file — 10 business days for Afterpay, 5-7 for Klarna — instead of a generic "a few business days" that undersells how long a BNPL refund legitimately takes.
• Treat a reference as dispute evidence, not just a support convenience. Our analysis of Stripe's own dispute-evidence research found proof of a full refund was the single strongest predictor of winning a "product not received" dispute, lifting win rates 63 percentage points. A reference number is exactly the kind of concrete, attachable proof that claim needs — and until October 28, you simply didn't have one for these three methods if a dispute landed before the refund fully settled.
• Watch for network_decline_code the same way you watch for a failed charge. A refund failure on PayPal, Afterpay, BLIK, or Swish needs its own alert and its own fallback — manually reissuing via a different method, or looping in support before the customer notices on their own — not silent treatment as a resolved ticket.

What this doesn't fix

None of this shrinks the actual settlement window. Afterpay refunds still take up to 10 business days; nothing about a reference number speeds that up, it just makes the wait traceable instead of opaque. PayPal's completion time is still unpublished and dependent on the settlement preference you configured when you set up PayPal on Stripe, so "available" there tells you a reference exists, not when the money lands. And coverage is still partial: Alipay, WeChat Pay, GrabPay, Scalapay, Sofort, and several other methods Stripe supports still carry no reference field in destination_details at all, which means the visibility gap this release closes for three methods still fully exists for the rest of your payment mix. If a meaningful share of your subscribers cancel using one of those, the problem this post describes hasn't gone away for them — it just moved to a method Stripe hasn't gotten to yet.

The underlying lesson holds regardless of which payment method a given subscriber used: the moment someone cancels and asks for money back is the moment your product has the least goodwill left to spend, and a refund they can't verify themselves is goodwill you're burning for free. Our churn calculator is a quick way to check how much of your reported churn is actually arriving through disputes rather than your own cancel flow — a split that tends to get worse, not better, wherever refund visibility is weakest. Closing that gap with a real reference number is a small, specific fix. Making sure the cancellation flow itself sets the right expectation before the subscriber ever has to ask is the part CancelFlow is built to handle.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.