Multilingual emails from a Stripe webhook — inferring language from currency

A subtle trap of taking a SaaS international: the system emails sent from your Stripe webhook. Purchase confirmation, renewal success, payment failure, plan change — four kinds of emails triggered by Stripe events. We recently discovered all four had been hardcoded to Japanese for months, sending Japanese receipts and failure notices to English-paying users overseas. The kind of bug that quietly persists forever unless you go looking. This post walks through the currency-based language inference design we landed on, plus the small mb_language trap that nearly ruined the fix. Where do you get "the user's language" from? — three options There were essentially three design options for picking the email language inside the webhook: Option A. Keep a language column in the DB. The classical answer — store language at signup, look it up when sending mail. But it requires a DB migration, leaves existing users in "language unknown" until backfill, and you still need fallback