The symptom
Paddle's domain approval for trustfolio.dev came through on a Thursday afternoon. I flipped the environment from sandbox to production, clicked Upgrade on my own dashboard, and got an overlay saying "Something went wrong. Please try again later."
No stack trace. No meaningful Paddle.js error object — just { error: {}, meta: {} } when I tried to capture it. Production logs looked fine. Webhook endpoint responded 200 OK for test pings. All the env vars were set. All the Paddle dashboard pieces existed.
I spent an afternoon staring at this before figuring it out.
The hypothesis that was wrong
My first guess: Paddle's live API needed something the sandbox didn't. Maybe a tax category, maybe a stricter domain verification. I re-read the Paddle dashboard twice. Everything looked correct.
Then I tried Paddle.PricePreview — the client-side preview API — with the production price ID I had pulled from my Vercel env. It threw the same blank error.
So I copied the price ID directly out of the Paddle dashboard and used that string instead of the env var. PricePreview worked immediately. Subtotal $79, discount $0, total $79.
The problem was in my environment variable.
The culprit
I pulled all seven PADDLE_* env vars down with vercel env pull and inspected the raw bytes of each value's tail:
PADDLE_BUSINESS_PRICE_ID last6hex=7a 33 67 68 5c 6e
The last two bytes are 0x5c and 0x6e — a literal backslash followed by the letter n. Not a real newline (0x0a). Just the two characters \n stuck onto every value as a plain string.
I had written a defensive envTrim() earlier in the day that used JavaScript's String.prototype.trim() to strip whitespace. But trim() only removes actual whitespace — space, tab, newline, carriage return. It does not remove the two-character string \n.
So when my webhook compared priceId === process.env.PADDLE_BUSINESS_PRICE_ID, it was really comparing 'pri_01knw040zen6akf7mrncx5z3gh' to 'pri_01knw040zen6akf7mrncx5z3gh\n'. Equality test failed silently. The webhook fell back to its default branch and labeled every incoming purchase as a Pro subscription, regardless of what was actually bought.
The fix in two layers
Layer 1 — code is defensive from now on. I replaced every .trim() in the Paddle code path with a regex that handles both whitespace and literal escape sequences:
const envTrim = (v) => v ? v.replace(/(?:\\n|\\r|\s)+$/g, '').replace(/^(?:\\n|\\r|\s)+/g, '') : '';
This catches the case even if somebody copy-pastes an env var with a trailing \n again in the future.
Layer 2 — Vercel env vars are now clean. A one-shot Node script pulled each variable, stripped the trailing junk, and re-registered it with vercel env rm / vercel env add. After a redeploy, the raw bytes looked exactly as expected. PricePreview and Checkout both succeeded immediately.
How the bad characters got there
I never typed \n into a Vercel env value on purpose. My best guess is that I pasted from a terminal or a note where a line ending got escaped as the literal two-character sequence, and Vercel stored it verbatim. Vercel's UI doesn't render trailing control characters, so the value looked clean in the dashboard.
This is the kind of bug where the platform behaves correctly by any reasonable definition. The string you give it is the string it stores. The surprise is entirely in the mismatch between what you think the string is and what it actually is.
Lessons worth carrying forward
- When an API returns a blank error object, suspect your own input before suspecting the service. Especially for services like Paddle that have been running at scale for years. The bug is usually on your side.
-
Hex-inspect env vars when checkout mysteriously breaks.
vercel env pullplus a five-line Node script saved me hours. - Defensive trimming should handle literal escape sequences, not just whitespace. Especially for values that cross system boundaries — env vars, webhooks, CSV imports.
-
Keep a webhook-inspection utility ready. My DB monitor that printed every
workspacesrow change let me see exactly where the plan comparison was going wrong.
Why this matters for SaaS reliability
Checkout reliability is the whole game for a paid SaaS. A silent 5% failure rate on upgrade attempts is more expensive than any growth channel. If you run a small SaaS, take an afternoon and try to break your checkout in weird ways — paste env vars from a shell history, use a discount code for an unrelated product, hit the checkout from a Safari incognito window. You will find at least one bug. The question is whether you find it or a paying customer does.
Trustfolio collects customer testimonials, scores them with AI for conversion potential, and embeds them anywhere with a single <script> tag. Free tier, no credit card.
