Backend-Driven Localization for Payment Pages
Sujal Vijayvargiya
SDE-1
How I built a backend HTML translation framework at Juspay that enabled instant multilingual rollout across all payment page products without per-language frontend deployments.
The Problem With Frontend Localization
Standard frontend i18n requires separate builds per locale — adding a new language means a new deployment, new QA cycle, and new release. For a product serving dozens of markets with different pace-of-change requirements, this was untenable.
The insight was that payment page HTML is relatively static per merchant session. A server-side transformation pass could substitute translation keys before delivery, making the frontend entirely locale-agnostic.
Middleware Translation Layer
The framework intercepts the rendered HTML payload and walks the DOM tree, substituting known translation keys with locale-specific strings resolved from a centralized key store. Merchant language preference is resolved from gateway config and session metadata.
Unknown keys fall through to a defined fallback hierarchy: merchant-locale → product-locale → English. No missing translation silently breaks the page.
The Tradeoff
Server-side HTML transformation adds processing overhead per request, which required careful profiling and caching of rendered bases. For payment pages — where latency directly impacts conversion — this was a genuine constraint that shaped the implementation significantly.
— END OF TRANSMISSION —
RETURN TO BLOG