How Razorpay Engineered a Future-Proof Checkout for the Cookieless Web
A System Design Deep-Dive into CHIPS, Privacy Sandbox & Distributed Identity
For over a decade, third-party cookies powered frictionless payments, cross-domain login, and personalization. If you entered your phone/email while paying on one site, Razorpay could instantly recognize you on another merchant’s site—reducing checkout time and boosting conversions.
But now, Google Chrome (with 60% browser dominance) is phasing out third-party cookies for privacy reasons.
This isn’t just a browser update—it’s a fundamental shift in how identity, state, and trust are managed across the web.
👉 For a payment gateway like Razorpay, this was an existential architectural challenge.
So how did they solve it? They adopted CHIPS (Cookies Having Independent Partitioned State)—a new browser standard—to build a privacy-first, frictionless checkout system without relying on third-party cookies.
This blog breaks down how the architecture works, what trade-offs were made, and what you can learn as a system design engineer.
1) How Razorpay Uses Third-Party Cookies Today
2) Razorpay’s Engineering Challenge
3) Solution Analysis: What Razorpay Explored
4) Razorpay’s New Checkout Architecture (System Design View)
5) Key Technical Components
6) Why This Architecture Works
7) Engineering Lessons You Can Apply
1) How Razorpay Uses Third-Party Cookies Today
Razorpay’s Standard Checkout is embedded inside thousands of merchant websites via an iframe hosted on checkout.razorpay.com. When a user enters their phone number or email during checkout, Razorpay encrypts and stores this data in a third-party cookie under its own domain.
This cookie enables:
– Autofill across multiple merchant websites using Razorpay
– OTP-less login for returning users
– Pre-filled shipping and saved payment details
– High checkout completion rates due to reduced friction
Essentially, Razorpay behaves like a central identity provider across the internet, using third-party cookies to recognize users in real time across different domains.
2) Razorpay’s Engineering Challenge
When Chrome announced the deprecation of third-party cookies, it directly threatened Razorpay’s core value proposition: fast, prefilled, trustworthy checkout.
Key risks:
Loss of shared identity across merchant domains
Increased OTP verification steps
Drop in conversion rates for merchants
Customer dissatisfaction and distrust in payment reliability
Razorpay needed to redesign identity and session management without relying on third-party cookies while keeping the merchant integration completely unchanged.
3) Solution Analysis: What Razorpay Explored
Approach
– Redirect to Razorpay.com
– Storage Access API
– Partitioned Cookies (CHIPS)
Pros
– Keeps cookies first-party
– Browser-provided permission model
– Preserves same-site memory, Zero UX interruption, No merchant changes
Cons / Reasons Rejected
– Adds extra redirect → poor UX
– Limited support & reliability
– Loses cross-site identity
4) Razorpay’s New Checkout Architecture (System Design View)
Architecture Shift:
Instead of maintaining a single third-party cookie accessible across all domains, Razorpay now stores partitioned cookies — isolated per merchant domain.
Flow:
User opens Razorpay iframe on Merchant A (foo.com)
Enters phone/email → partitioned cookie is stored tied to foo.com
Returns to foo.com → Razorpay pre-fills details using the same partition
Visits Merchant B (bar.com) → treated as a fresh session but a new cookie is created for future autofill on bar.com
Design Principles Used:
Stateless architecture at Razorpay servers
Browser-managed state isolation
Privacy-first identity storage
5) Key Technical Components
Component
– Razorpay Frontend SDK
– Partitioned Cookie Layer (CHIPS)
– Session Validation Service
– Autofill Engine
– Fallback Auth System
Purpose
– Embeds checkout iframe securely across merchants
– Stores user-session state per merchant
– Maps cookie signatures to secure token-based identity
– Pre-populates checkout forms based on CHIPS cookie
– OTP verification when no valid cookie present
7) Why This Architecture Works
✅ Zero Integration Changes: Merchants don’t need to update their code or adopt new APIs.
✅ Privacy Compliant: Fully aligned with Chrome’s Privacy Sandbox and future browser regulations.
✅ Optimized for Real User Behavior: Most repeat transactions happen on the same merchant (e.g., Swiggy, Zepto), not across different merchants.
✅ Future-Ready: Architecture is modular and can easily integrate new browser APIs like FedCM or Topics API.
✅ Performance Preserved: Cookie lookup still happens locally via the browser, with near-zero latency.
8) Engineering Lessons You Can Apply
🔹 Design for Change, Not for Assumptions
Never hardcode your architecture to rely on browser behaviors — they can change overnight.
🔹 Abstract External Dependencies
Razorpay built a separation between identity storage logic and cookie access, allowing them to swap strategies quickly.
🔹 Optimize for Backward Compatibility
Winning architectures often don’t force clients to upgrade or change their code.
🔹 User Experience Is a System Requirement
Architecture is not just about scalability; it’s also about minimizing user friction and maintaining trust.
🔹 Privacy is Now a Core System Design Constraint
Future architectures must treat user identity as partitioned, local, and consent-based — not globally shared.