Lead Developer
Building Reusable 3DS Authentication Infrastructure
Built a shared authentication integration inside the core transaction path, proving it at Air India scale and shaping it for reuse across providers and payment experiences.
Details are intentionally generalized to respect confidentiality.
- Timeline
- 2025–2026
- Domain
- Authentication, payment orchestration, data pipelines
- Impact
- Supports 250K+ monthly Air India card transactions and a reusable path for additional authentication flows.
Architecture
System boundary map
The diagram preserves the major responsibilities and handoffs while omitting proprietary implementation details.
Shared 3DS Authentication Platform
Designed API contracts, authentication orchestration, reusable data-pipeline boundaries, observability, and load-test coverage for a shared integration model.
Context
Card authentication sits directly on the conversion path: every handoff must preserve state, security, latency expectations, and an explainable result for downstream systems.
Air India provided the first high-volume production use case, while the integration itself needed to remain extensible for additional authentication providers and payment experiences.
Problem
The platform needed to introduce a shared authentication service into an established transaction path without weakening existing payment behavior.
A merchant-specific implementation would have duplicated contracts and data movement each time a new authentication product was onboarded.
Constraints
Payment correctness and secure data boundaries were non-negotiable.
Authentication calls needed explicit timeout, retry, and status-mapping behavior.
The contract had to remain observable and reusable without exposing sensitive card data.
Production readiness required realistic load and failure-path validation.
My Role
Led development across the shared API contract, transaction integration, authentication orchestration, data-pipeline touchpoints, load testing, and rollout readiness.
Worked across system boundaries so the first merchant launch also established a reusable integration pattern for subsequent authentication initiatives.
Technical Design
Modeled authentication as explicit transaction stages, separating validation, provider interaction, gateway handoff, and final status mapping.
Defined stable contracts between checkout-facing systems, the core transaction layer, and authentication services, including failure semantics and auditable state transitions.
Integrated a shared data pipeline for downstream analytics and operational monitoring while keeping sensitive card data outside observable payloads.
Validated the path with load tests shaped around realistic traffic, latency, and provider-failure scenarios.
Tradeoffs
A reusable platform boundary required more contract design than a merchant-only path, but reduced the cost and risk of future authentication onboarding.
Richer status modeling added implementation work while making production debugging and incident response safer.
Impact
The integration supports 250K+ monthly Air India card transactions.
Other teams can build on the same data and orchestration boundaries for additional authentication products; the pattern is already being extended toward flows such as Mastercard Click to Pay.
What I learned
The durable output of a large integration is not only the launch; it is the contract and operating model that make the next integration safer.
Authentication quality is defined as much by failure semantics and observability as by happy-path latency.