Arun Raj

@jarnura

A Universal Grammar for Payments — How Rust’s Trait System, Types, and Macros Turned Fragmented Payment APIs into a Deterministic Language

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.

Comments

{{ gettext('Login to leave a comment') }}

{{ gettext('Post a comment…') }}
{{ gettext('New comment') }}
{{ formTitle }}

{{ errorMsg }}

{{ gettext('No comments posted yet') }}

Hosted by

A community of Rust language contributors and end-users from Bangalore. We have presence on the following telegram channels https://t.me/RustIndia https://t.me/fpncr LinkedIn: https://www.linkedin.com/company/rust-india/ more