Why merchant of record changes the recovery problem
Under a merchant-of-record arrangement Paddle is the legal seller. It collects the money, remits the sales tax and VAT, and owns the payment credential on file. That is a genuine operational gift — you do not register for tax in thirty jurisdictions — but it has a specific consequence for churn: when a renewal fails, the customer hears from Paddle, in Paddle's voice, on Paddle's schedule.
Most customers do not remember that the charge on their statement belongs to the merchant of record rather than to your product. A billing email from an unfamiliar sender about an unfamiliar descriptor is exactly the kind of message people ignore or report as suspicious, and it is why recovery on MoR platforms often underperforms direct-gateway recovery despite comparable retry logic.
The fix is not to replace Paddle's dunning. It is to add a branded, multi-channel layer alongside it so the customer receives one message they recognise, from the product they actually use, explaining what happened and what to do.
The Paddle event surface you build on
`transaction.payment_failed` is the anchor event. It carries the transaction ID, the subscription, the customer, the amount and currency, and the payment method details including the decline reason where the processor supplied one.
`subscription.past_due` tells you the subscription state machine has moved and Paddle's own retry schedule is now running. `subscription.updated` back to `active` is the recovery confirmation, and `subscription.canceled` is the terminal loss you are trying to prevent.
Paddle signs webhooks with an HMAC over the raw body using a per-notification-destination secret, delivered in the `Paddle-Signature` header with a timestamp. Verify exactly as you would with Stripe: raw bytes, timing-safe comparison, tight timestamp tolerance, reject before writing.
Coordinating with Paddle's retry schedule instead of fighting it
Because Paddle owns the credential, you cannot trigger the retry yourself. That makes timing coordination the central design constraint: your message must arrive before Paddle's next attempt, not after it, so the customer has time to act.
Read the next retry timestamp from the subscription payload and schedule your first touch to land several hours ahead of it, inside the customer's local business hours. A message that arrives ninety minutes before the retry converts far better than one that arrives ninety minutes after a second failure, because the customer's action and the platform's attempt line up.
For expired cards the timing logic inverts. No scheduled attempt will succeed, so the message goes out immediately with the update link and the retry is irrelevant until the credential changes.
Handling tax, currency and the amount you quote
A merchant-of-record invoice is gross of VAT or sales tax, and the tax component varies by the customer's country. If your recovery message quotes the net subscription price the customer will see a different figure on their statement and hesitate — hesitation is churn.
Always quote the exact `totals.grand_total` in the transaction currency, formatted with the correct locale separators and symbol. For a German customer that is 119,00 € and not $100.00.
Currency also affects your recovery economics. A failure on a 60,000 JPY annual plan deserves a phone-grade escalation; a failure on a 9 EUR monthly plan does not. Weight your cadence by at-risk value, not by row count.
Building the branded second channel
Send from your own domain with DKIM and SPF aligned, using a plain transactional template that names your product in the first line and mentions the merchant of record only once, as reassurance: 'the charge appears as PADDLE.NET on your statement'. That single sentence removes the most common source of confusion on MoR platforms.
Add WhatsApp Cloud API for the codes where speed dominates. Sending from your own Meta business number, an approved utility template reads in the 90%+ range with most replies inside fifteen minutes, against 18-25% opens for billing email. Meta bills the conversations to your own WhatsApp account directly, so the cost sits with you and stays transparent.
Keep the update path pointed at Paddle's hosted payment-method update page. You must never collect the card yourself — doing so would pull you into the PCI scope that the merchant-of-record model exists to remove.
Decline-code routing on a platform that abstracts the processor
Paddle abstracts several underlying processors, so the decline reason you receive is normalised rather than raw issuer text. Map it into the same four buckets you would use anywhere: temporary funds problem, dead credential, issuer block, authentication failure.
Temporary funds problems get a 48-hour rhythm and a message that states the retry date. Dead credentials get an immediate update link and no retry expectation. Issuer blocks get an alternate-card prompt early rather than a third identical attempt. Authentication failures get the fastest channel available and a 24-hour follow-up.
Where the reason is missing entirely — which happens on a minority of MoR transactions — default to the temporary-funds path. It is the most common cause and the least damaging assumption to make in copy.
How much of your involuntary churn is recoverable?
Compares a 40% single-channel baseline against the 63.8% RRLabs platform average.
- At risk / month
- $5,600
- Extra recovered / month
- $1,333
- Annualised, less $3,000 plan
- $12,994
RRLabs vs legacy dunning tools
Churn Buster, Baremetrics Recover, Stripe native dunning and Gravy compared with Revenue Recovery Labs.
| Feature | Legacy tools | Revenue Recovery Labs |
|---|---|---|
| Recovery channels | Email and basic SMS only | Native Meta WhatsApp Cloud API (your number) + email |
| Pricing architecture | $129–$629+/mo, or a percentage cut of recovered cash | Flat $100 / $250 / $500 per month — you keep 100% |
| Retry logic | Fixed calendar dunning (day 1, 3, 7) | Retry window derived per decline code, persisted at ingestion |
| Copy engine | Static templates you edit by hand | 4-tier cascade: cache → primary model → fallback model → deterministic templates |
| White-label | Unavailable or enterprise-only | Flat +$300/mo with custom domain and no vendor watermark |
| Audit trail | Send logs at best | Tier, model, latency and recovery score on every message |
Reporting: separating involuntary from voluntary churn
Most subscription dashboards blend cancellations and payment failures into one churn number, which hides the cheapest retention win in the business. Split them explicitly: voluntary churn is a customer decision, involuntary churn is a payment mechanics problem, and only the second is fixable with engineering.
On Paddle, tag every subscription that entered `past_due` in the period and track how many returned to `active` within fourteen days. That ratio is your true recovery rate, and it belongs next to gross MRR churn on the same board.
Expect a meaningful share — commonly a fifth to two fifths of total churn — to be involuntary. Recovering even half of it usually outperforms any acquisition experiment running in the same quarter.
Rollout plan without disturbing live billing
Register a notification destination for the four events, verify signatures, and run one full billing cycle in shadow mode with messaging disabled. This gives you an honest baseline of what Paddle's own dunning already recovers.
Switch on the branded email channel first and compare the same cohort. Then add WhatsApp for the authentication and funds codes only, since those are where the channel advantage is largest.
Leave Paddle's dunning emails enabled throughout unless your own recovery rate proves higher across two consecutive cycles; two coordinated messages outperform one, and turning off the platform's safety net before you have data is an avoidable risk.
Working with Paddle's customer portal
Paddle hosts the payment-method update flow, and every recovery message should terminate there. Generate the portal or transaction URL at dispatch time so signed links are fresh, and confirm the destination resolves on mobile browsers rather than only on desktop.
Do not build an intermediate page that collects any payment detail, even a card brand selector. The value of the merchant-of-record model is that card handling never touches your systems, and a well-meaning convenience form throws that away.
Where the customer needs an invoice or a VAT receipt to get internal approval — common in B2B — link that from the same message. A finance-approval blocker looks identical to churn until you remove it.
Multi-currency reporting without double counting
Paddle settles in many currencies. Report at-risk and recovered amounts in a single reporting currency using the rate at the time of the failed transaction, and store both the original and converted figures so historical reports do not drift as rates move.
Deduplicate per subscription per cycle. Three failed attempts on one annual plan are one at-risk subscription, not three, and counting attempts instead of subscriptions inflates both the problem and the apparent recovery.
Separate tax from net revenue in the recovery number. Recovering a gross invoice does not recover gross revenue to you; the tax component was never yours.
Where RRLabs fits
Revenue Recovery Labs runs the branded second channel described here: verified webhook ingestion, decline classification, timing aligned to the platform's own retry schedule, and email plus WhatsApp dispatch from your own sender identity.
Because it never charges a card and never holds a credential, it composes cleanly with the merchant-of-record model rather than competing with it. Flat pricing at $100, $250 or $500 per month means the tax-inclusive amounts flowing through Paddle never change what recovery costs you.
The white-label add-on at $300 per month is aimed at agencies running recovery on behalf of client stores, with custom domains and no vendor branding on any message.