Apr 2026
13 Mon
14 Tue
15 Wed
16 Thu
17 Fri
18 Sat 09:00 AM – 06:00 PM IST
19 Sun 09:00 AM – 06:00 PM IST
Arun Raj
@jarnura
Submitted Mar 16, 2026
Every payment processor speaks its own dialect — Stripe expects nested JSON with idempotency keys, Razorpay wants base64-encoded auth and a PayU might have an entirely different vocabulary. Multiply that by 200+ payment methods, hundreds of countries, varying regulations, and you get a combinatorial nightmare where engineering teams spend more time wrestling payloads than optimising payment success rates.
At Juspay, we process 300M+ transactions daily across India’s wildly diverse payment ecosystem — cards, UPI, net banking, wallets, BNPL, EMI — routed through dozens of processors.
Our answer: build a Universal Grammar for Payments — an open-source Rust library (connector-service) that gives every payment processor a single, unified contract. We discovered that all payment APIs, no matter how different on the wire, share a common deep structure: authenticate, shape a request, parse a response, map errors. We encoded this grammar directly into Rust’s type system.
Traits as Grammar Rules: Each payment action (authorize, capture, refund) is an implementation of a combination of Traits (Grammar Rules). Stripe and Razorpay look nothing alike at the wire level, but both conform to the same trait-based contract. The compiler enforces completeness — miss a method, and it won’t build.
Native Language SDK: To ensure broad usability, we leveraged Rust’s robust support for Foreign Function Interface (FFI). This allowed us to successfully deliver this capability across a wide array of programming languages.
Macros as DSL: Procedural macros generate the boilerplate wiring, letting contributors express a new connector integration in a declarative style rather than copy-pasting hundreds of lines.
AI-Native by Design: Because the grammar is statically encoded, and hardened on production AI coding agents get deterministic contracts instead of hallucination-prone processor docs. The type system is the spec.
Extensible as a framework: The same pattern extends itself well to other commerce functions like subscriptions, authentication, payouts, fraud etc. - thereby ensuring bullet proof integrations.
Target Audiences
This session is primarily valuable for intermediate-to-advanced Rust developers who want to see traits, procedural macros, and FFI applied to a real production system at scale. Backend and platform engineers dealing with third-party API fragmentation will find the patterns directly transferable beyond payments. Finally, fintech and AI tooling engineers will find the “type system as spec” approach a concrete, working model worth taking back to their own codebases.
Bio:
Arun Raj is a software engineer at Juspay Technologies, where he works on building open-source payment infrastructure in Rust. You can find him on LinkedIn.
Hosted by
{{ gettext('Login to leave a comment') }}
{{ gettext('Post a comment…') }}{{ errorMsg }}
{{ gettext('No comments posted yet') }}