It's not your Nigerian customers ghosting you it's your checkout
Looking into a payment problem Nigerian banks cap forex spending on cards, so international SaaS subscriptions frequently fail for Nigerian users often silently, without a support ticket, since most people just churn instead of complaining. Even Spotify has an open, unresolved thread about this on their own support forum.
Curious how many other founders have Nigerian users and have run into this, even without realizing it. Would love to hear if this has come up for anyone here.
Silent failed payments are exactly the blind spot most founders don't check for, because the natural read is "they didn't want it" rather than "the card declined and nobody told them." A quick way to sanity-check this without waiting for a forum thread: pull your payment processor's failed-charge events (not the churn events, the raw decline codes) and look at the distribution of decline reasons by country or card BIN. Card issuer FX/spending caps show up as a specific decline code cluster, distinguishable from "insufficient funds" or "expired card." If you've got a chunk of declines you've been lumping into "they cancelled," that's recoverable revenue, not lost customers — worth a dunning email that explains the real reason instead of a generic "update your payment method."
This is exactly the kind of diagnostic most founders don't know how to run appreciate you laying it out this clearly. The BIN-level decline clustering point is especially useful most people just see 'card declined' as one bucket instead of breaking out FX/spending-cap-specific codes. Curious what you've seen when founders actually do run this is the recoverable chunk usually bigger or smaller than expected? And what's your background in this are you working on something in payments/dunning yourself.
No hard recovery-rate number to share — that specific point came from general decline-code taxonomy, not something we've measured live on a production account, so I don't want to guess whether the recoverable chunk runs bigger or smaller than expected. On background: we built Revenue Leak Scanner, a free tool that reads a Stripe/Lemon Squeezy/Paddle CSV export and flags failed payments, refunds, coupon abuse, and underpriced plans that founders usually lump into unexplained churn. Same instinct as what you're describing here, but it's post-hoc analysis of an export, not live BIN-level decline clustering or automated dunning — that would be the natural next layer if the correlation holds up.
appreciate the honesty on not overstating it
Since Revenue Leak Scanner processes real Stripe/Lemon Squeezy/Paddle exports across a bunch of different merchants have you ever noticed a country-specific pattern in the failed-payment data, particularly around Nigeria? I'm specifically looking at cases where a customer's card just stops working on renewal (not insufficient funds, more like blocked/restricted transactions), and wondering if that's shown up as a visible cluster in any of the exports you've looked at.
No, honestly — Revenue Leak Scanner runs entirely client-side in the browser, we never see or store the CSVs people upload, so we don't have aggregate visibility across merchants to confirm a country-level pattern. What the tool does surface per-file is whether declines cluster on a specific BIN range or recur right at the renewal date rather than being spread randomly — that's the closest proxy to "blocked/restricted" vs "insufficient funds" without needing decline-code detail. If you run one of your own exports through it, that clustering view would tell you more than I can guess from here.