DEV Community: Hyperswitch

Prism: A stateless payment integration library extracted from 4 years of production

Neeraj Kumar — Thu, 16 Apr 2026 15:40:55 +0000

The Problem

If you have ever integrated a payment processor, you know the drill. You read through a PDF that was last updated in 2019, figure out what combination of API keys goes in which header, discover that "decline code 51" means something subtly different on this processor than the last one you dealt with, and then do it all over again when your business decides to add a second processor.

We have been living in this world for years building Juspay Hyperswitch, an open-source and composable payments platform. At some point we had integrations for 100+ connectors. The integrations worked well — but they were locked inside our orchestrator, not usable by anyone who just needed to talk to Stripe or Adyen without adopting an entire platform.

And we always felt the payment APIs are not more complicated than database drivers. It is just that the industry has not arrived at a standard (and likely never will) for payments.

Hence, we decided to extract the integrations into a lightweight open interface for developers and AI agents to use, rather than recreate it every time.

This post is about how we did that: unbundling those integrations into a standalone library called Prism, and the engineering decisions we made along the way. Some of them are genuinely interesting.

Why unbundle at all?

The connector integrations inside Hyperswitch were not designed to be embedded in an orchestrator forever. They were always a self-contained layer: translate a unified request into a connector-specific HTTP call, make the call, translate the response back. The orchestrator was just the first thing to use them.

The more we looked at it, the more it seemed wrong to keep that capability locked behind a full platform deployment. If you just need to accept payments through Stripe, you should not have to adopt an orchestrator to get a well-tested, maintained integration. And if you want to switch to Adyen later, that should be a config change, not a rewrite.

So we separated the integration layer out. The result is a library with a well-defined specification — a protobuf schema covering the full payment lifecycle — that can be embedded directly in any application or deployed as a standalone service.

Why protobuf for the specification?

Q: JSON schemas exist. OpenAPI exists. Why protobuf?

The core requirement was multi-language client generation. We needed Python developers, Java developers, TypeScript developers, and Rust developers to all be able to consume this library with first-class, type-safe APIs — without anyone hand-writing SDK code in each language. Protobuf has the most mature ecosystem for this: prost for Rust, protoc-gen-java for Java, grpc_tools.protoc for Python, and so on. It also doubles as our gRPC interface description when the library is deployed as a server, which turned out to be a natural fit for the two deployment modes we wanted to support.

The specification covers the full payment lifecycle across nine services:

Service	What it does
`PaymentService`	Authorize, capture, void, refund, sync — the core lifecycle
`RecurringPaymentService`	Charge and revoke mandates for subscriptions
`RefundService`	Retrieve and sync refund statuses
`DisputeService`	Submit evidence, defend, and accept chargebacks
`EventService`	Process inbound webhook events
`PaymentMethodService`	Tokenize and retrieve payment methods
`CustomerService`	Create and manage customer profiles at connectors
`MerchantAuthenticationService`	Access tokens, session tokens, Apple Pay / Google Pay session init
`PaymentMethodAuthenticationService`	3DS pre/authenticate/post flows

Everything is strongly typed. PaymentService.Authorize takes a PaymentServiceAuthorizeRequest — amount, currency, payment method details, customer, metadata, capture method — and returns a PaymentServiceAuthorizeResponse with a unified status enum, connector reference IDs, and structured error details. No freeform JSON blobs. No stringly-typed status fields. The spec is the contract.

The implementation: Rust at the core

Q: Why Rust? Wouldn't Go or Java be simpler?

A few reasons. First, we already had 50+ connector implementations in Rust from Hyperswitch, so starting there was practical. But more importantly: the library needs to be embeddable in Python, JavaScript, and Java applications without a separate process or a runtime dependency like the JVM or a Python interpreter. The only realistic way to distribute a native library that loads cleanly into all of those runtimes is as a compiled shared library — .so on Linux, .dylib on macOS. Rust produces exactly that, with no garbage collector pauses, no runtime to ship, and memory safety that does not require a GC.

The Rust codebase is organized into a handful of internal crates:

connector-integration — The actual connector logic: 50+ implementations translating unified domain types into connector-specific HTTP requests and parsing responses back
domain_types — Shared models: RouterDataV2, flow markers (Authorize, Capture, Refund, ...), request/response data types
grpc-api-types — Rust types generated from the protobuf spec via prost
interfaces — The trait definitions that connector implementations must satisfy

The two-phase transformer pattern

The single most important design decision in the Rust core is that the library never makes HTTP calls itself. Every payment operation is split into two pure functions:

┌─────────────┐    req_transformer      ┌──────────────────┐
│  Unified    │ ──────────────────────▶ │ Connector HTTP   │
│  Request    │                         │ Request          │
│  (proto)    │                         │ (URL, headers,   │
└─────────────┘                         │  body)           │
                                        └────────┬─────────┘
                                                 │  you make this call
                                                 ▼
┌─────────────┐    res_transformer      ┌──────────────────┐
│  Unified    │ ◀────────────────────── │ Connector HTTP   │
│  Response   │                         │ Response         │
│  (proto)    │                         │ (raw bytes)      │
└─────────────┘                         └──────────────────┘

req_transformer takes your unified protobuf request and returns the connector-specific HTTP request — the URL, the headers, the serialized body. You make the HTTP call however you like. res_transformer takes the raw response bytes plus the original request and returns a unified protobuf response.

Q: Why not just have the library make the HTTP call for you?

Mostly because it makes the library genuinely stateless and transport-agnostic. It does not own any connection pools. It does not have opinions about TLS configuration, proxy settings, or retry logic. When this code runs inside a Python application, the Python application's httpx client handles the HTTP. When it runs inside the gRPC server, the server's client handles it. This also turns out to be quite testable — you can unit test transformers by feeding them request bytes and asserting on the resulting HTTP request structure, without standing up any network infrastructure.

Each flow is registered using a pair of Rust macros:

// Register the request transformer for the Authorize flow
req_transformer!(
    fn_name: authorize_req_transformer,
    request_type: PaymentServiceAuthorizeRequest,
    flow_marker: Authorize,
    resource_common_data_type: PaymentFlowData,
    request_data_type: PaymentsAuthorizeData<T>,
    response_data_type: PaymentsResponseData,
);

// Register the response transformer for the Authorize flow
res_transformer!(
    fn_name: authorize_res_transformer,
    request_type: PaymentServiceAuthorizeRequest,
    response_type: PaymentServiceAuthorizeResponse,
    flow_marker: Authorize,
    resource_common_data_type: PaymentFlowData,
    request_data_type: PaymentsAuthorizeData<T>,
    response_data_type: PaymentsResponseData,
);

The macros generate the boilerplate: connector lookup, trait object dispatch, RouterDataV2 construction, serialization. A new flow means adding the connector trait implementation and one pair of macro invocations. The code generator handles everything else.

Two ways to use it

We wanted the library to work both as an embedded SDK (loaded directly into your application process) and as a standalone gRPC service (deployed separately, called over the network). Same Rust core, same proto types, same API — two completely different deployment topologies.

┌──────────────────────────────────────────────────────────┐
│                    Your Application                      │
└─────────────────────┬────────────────────────────────────┘
                      │
         ┌────────────┴────────────┐
         ▼                         ▼
 ┌──────────────┐         ┌─────────────────┐
 │   SDK Mode   │         │   gRPC Mode     │
 │  (FFI/UniFFI)│         │ (Client/Server) │
 └──────┬───────┘         └────────┬────────┘
        │                          │
        │  in-process call         │  network call
        ▼                          ▼
 ┌──────────────────────────────────────────────┐
 │              Rust Core (Prism)               │
 │  req_transformer → [HTTP] → res_transformer  │
 └──────────────────────────────────────────────┘

Mode 1: The embedded SDK

In SDK mode, the Rust core compiles into a native shared library (.so / .dylib) and is exposed to host languages via UniFFI — Mozilla's framework for generating language bindings from Rust automatically. When your Python code calls authorize_req_transformer(request_bytes, options_bytes), that call crosses the FFI boundary directly into the Rust binary running in the same process.

Data crosses the language boundary as serialized protobuf bytes. This is intentional — every language already has a protobuf runtime, so there is no custom serialization protocol to maintain, and the byte interface is completely language-neutral.

Q: Does this mean I need to compile Rust to use the Python SDK?

For development, yes — you run make pack, which builds the Rust library, runs uniffi-bindgen to generate the Python bindings, and packages everything into a wheel. For production use, we ship pre-built binaries for Linux x86_64, Linux aarch64, macOS x86_64, and macOS aarch64 inside the wheel. The loader picks the right one at runtime. You install the wheel and never think about Rust again.

Mode 2: The gRPC server

In gRPC mode, the grpc-server crate runs as a standalone async service built on Tonic (Rust's async gRPC framework). It implements all nine proto services, accepts gRPC connections from any language's generated stubs, makes the connector HTTP calls internally, and returns unified proto responses over the wire.

The gRPC server calls the same Rust core transformers as the FFI layer — just from a different entry point. The transformation logic is literally the same code path.

Each language SDK ships both deployment modes:

sdk/python/
├── src/payments/           ← FFI-based embedded SDK
│   ├── connector_client.py
│   └── _generated_service_clients.py
└── grpc-client/            ← gRPC stubs for server mode

sdk/java/
├── src/                    ← FFI-based embedded SDK (JNA + UniFFI)
└── grpc-client/            ← gRPC stubs for server mode

sdk/javascript/
├── src/payments/           ← FFI-based embedded SDK (node-ffi)
└── grpc-client/            ← gRPC stubs for server mode

Q: When would you actually choose gRPC over the embedded SDK?

The embedded SDK is great when you have a single-language service and want zero network overhead — serverless functions, edge deployments, or situations where adding a sidecar is painful. The gRPC server shines in polyglot environments: if your checkout service is in Java, your fraud service is in Python, and your reconciliation job is in Go, deploying one gRPC server gives all of them a shared, consistent integration layer without each one shipping a native binary.

The important point is that the choice is not a migration — your PaymentServiceAuthorizeRequest looks identical in both modes. You change a config flag, not your application code.

	SDK (embedded)	gRPC (network)
Latency	Microseconds (in-process)	Milliseconds (network)
Deployment	Library inside your app	Separate service to run
Language support	Python, JS, Java/Kotlin, Rust	Any language with gRPC
Connector HTTP	Your app makes the calls	Server makes the calls
Best for	Serverless, edge, single-language	Polyglot stacks, shared infra

Code generation: the glue that holds it together

Prism supports many payment flows and many SDK languages. Hand-maintaining typed client methods for each flow in each language is exactly the kind of work that introduces drift and bugs. So we don't do it.

The code generator at sdk/codegen/generate.py reads two sources of truth and emits all the SDK client boilerplate automatically.

Q: What are the two sources of truth?

services.proto compiled to a binary descriptor — this tells the generator every RPC name, its request type, its response type, and its doc comment.

crates/ffi/ffi/src/services/payments.rs — this tells the generator which flows are actually implemented, by scanning for req_transformer! invocations.

The generator takes their intersection. A flow in proto but not implemented in Rust? Warning, skipped — we don't ship unimplemented APIs. A transformer in Rust with no matching proto RPC? Also a warning — the spec is the authority, not the implementation.

Running make generate produces typed client classes across all languages. For example, in Python:

class PaymentClient(_ConnectorClientBase):
    async def authorize(
        self,
        request: PaymentServiceAuthorizeRequest,
        options=None
    ) -> PaymentServiceAuthorizeResponse:
        """PaymentService.Authorize — Authorizes a payment amount on a payment method..."""
        return await self._execute_flow(
            "authorize", request, _pb2.PaymentServiceAuthorizeResponse, options
        )

And in Kotlin:

class PaymentClient(config: ConnectorConfig, ...) : ConnectorClient(config, ...) {
    fun authorize(
        request: PaymentServiceAuthorizeRequest,
        options: RequestConfig? = null
    ): PaymentServiceAuthorizeResponse =
        executeFlow("authorize", request.toByteArray(), PaymentServiceAuthorizeResponse.parser(), options)
}

Here is the full pipeline:

services.proto
    │
    ├── prost (Rust build.rs)      → grpc-api-types crate (Rust types)
    ├── grpc_tools.protoc          → payment_pb2.py (Python proto stubs)
    ├── protoc-gen-java            → Payment.java (Java/Kotlin proto stubs)
    ├── protoc (JS plugin)         → proto.js / proto.d.ts (JS proto stubs)
    └── protoc (binary descriptor) → services.desc
                                            │
payments.rs (transformer registrations) ───┤
                                            ▼
                                      generate.py
                                            │
        ┌───────────────────────────────────┼──────────────────────┐
        ▼                                   ▼                      ▼
_generated_ffi_flows.rs    _generated_service_clients.py    GeneratedFlows.kt
                           connector_client.pyi             _generated_connector_client_flows.ts


cargo build --features uniffi
    └── uniffi-bindgen
              ├── connector_service_ffi.py   (Python native bindings)
              ├── ConnectorServiceFfi.kt     (Kotlin/JVM native bindings)
              └── ffi.js                     (Node.js native bindings)

The practical result: add a new flow to services.proto, implement the transformer pair in Rust, run make generate — and every language SDK gets a typed, documented method for that flow. No one writes boilerplate by hand.

Walking through a real authorize call

Let's trace what actually happens when a Python application calls client.authorize(...) in SDK mode:

① App builds PaymentServiceAuthorizeRequest (protobuf message)

② PaymentClient.authorize() → _execute_flow("authorize", request, ...)

③ _ConnectorClientBase._execute_flow():

   a. request.SerializeToString() → request_bytes

   b. authorize_req_transformer(request_bytes, options_bytes)
      ──── FFI boundary: Python → Rust shared library ────
      Rust: build_router_data! macro
        ├── ConnectorEnum::from("stripe")   ← look up connector
        ├── connector.get_connector_integration_v2()
        ├── proto bytes → PaymentFlowData + PaymentsAuthorizeData
        ├── construct RouterDataV2 { flow, request, auth, ... }
        └── connector.build_request(router_data) → Request { url, headers, body }
      serialize Request → FfiConnectorHttpRequest bytes
      ──── returns bytes across FFI boundary ────

   c. deserialize FfiConnectorHttpRequest → url, method, headers, body

   d. httpx AsyncClient.post(url, headers=headers, content=body)
      ← this is the actual outbound HTTP call to Stripe

   e. raw response bytes received

   f. authorize_res_transformer(response_bytes, request_bytes, options_bytes)
      ──── FFI boundary: Python → Rust shared library ────
      Rust: connector.handle_response(raw_bytes)
        ├── parse Stripe's JSON response format
        └── map → PaymentServiceAuthorizeResponse (unified proto)
      serialize → proto bytes
      ──── returns bytes across FFI boundary ────

   g. PaymentServiceAuthorizeResponse.FromString(bytes)

④ App receives unified PaymentServiceAuthorizeResponse

In gRPC mode, steps ③b through ③f happen inside the grpc-server process. The app sends the protobuf request over the network and gets the protobuf response back. The connector lookup, HTTP call, and response transformation are identical — just running in a different process.

Where we go from here — together

We want to be upfront about what this is and what it is not.

What it is: a working implementation with 60+ connectors, a protobuf specification that covers the full payment lifecycle, and SDKs in four languages. It is ready to use today.

What it is not: a finished standard. The spec reflects our understanding of what payment integrations need to look like. That understanding is incomplete, and we know it. Payment APIs have a very long tail of edge cases — 3DS flows that differ between processors, webhook schemas that change without notice, authorization responses that technically succeeded but should be treated as soft declines. There is no team small enough to have seen all of it.

That is why community ownership matters here, not as a marketing posture, but as a practical necessity.

If you want to use it: install the SDK, run make generate to see what flows are available, and point it at your test credentials. When something breaks — and something will — open an issue. The more connectors and flows get exercised in real environments, the faster the rough edges get found.

If you want to contribute a connector: implement a Rust trait in connector-integration/. The FFI layer, gRPC server, and all language SDKs pick it up automatically. You do not need to write Python or JavaScript or maintain anything outside that one crate.

If you want to contribute a flow: start with a discussion on the services.proto shape — that is the community contract, so it deserves a conversation before code gets written. Once there is agreement, implement the transformer pair in Rust, run make generate, and every SDK gets the new method in every language.

If you disagree with a spec decision: open a discussion. The whole point of making this community-owned is that no single team's assumptions should be baked in permanently. If you have seen payment edge cases that the current schema cannot express, that is exactly the kind of feedback that shapes a standard.

The longer arc here is for services.proto to evolve into something the payments community — developers, processors, orchestrators, and everyone else in the stack — maintains collectively. The same way OpenTelemetry's semantic conventions emerged from broad input, not from one company's opinions. The same way JDBC worked because it was simple enough to implement and strict enough to actually abstract.

GitHub: juspay/hyperswitch-prism

Open-Source Payments: Modular, Flexible, and Built for You

Gorakhnath Yadav — Tue, 11 Mar 2025 06:57:19 +0000

Imagine a Linux-like foundation for payments. A unified and open-source intelligence that transforms payment agility into a competitive advantage.

Introducing Hyperswitch, a modular, open-source, and interoperable full-stack payments platform engineered to put control back in your hands.

Why Hyperswitch?

Enterprises can build, augment, or customize their payment stack with modular solutions. Whether it's enabling alternate payment methods, streamlining operations across multiple providers and acquirers, or optimizing payment routing—Hyperswitch provides the flexibility businesses need.

With advanced analytics on processing costs, seamless authentication, token storage, and reconciliation, it simplifies and secures global payments.

Backed by a Global Engineering Force

Hyperswitch is powered by 1,000+ payment engineers globally, enabling infrastructure that processes up to 175 million transactions a day with 99.999% availability.

Engineered with robust system design principles, its open-source architecture ensures transparency, security, and enterprise-grade reliability with PCI compliance, tokenization, and security certifications.

Freedom from Closed-Loop Systems

With Hyperswitch, merchants gain rapid integration capabilities and freedom from vendor lock-ins. The open-source model allows for risk-free due diligence, eliminating the need for lengthy and costly RFP cycles.

Merchants can deploy Hyperswitch in local or cloud environments or leverage Juspay’s hosted sandboxes for seamless experimentation.

Take Control of your Payments

Whether you aim to optimize costs, expand into new markets, or reduce vendor reliance, Hyperswitch empowers you to build what you want, how you want.

🔗 Learn more about open-source payments and Juspay Hyperswitch.

Transitioning from Kubernetes to EC2 for Enhanced Kafka Performance

Gorakhnath Yadav — Thu, 06 Feb 2025 14:07:56 +0000

Scaling distributed systems is never just about performance, it's also about cost and operational efficiency. While Kubernetes provided us with a solid foundation for container orchestration, we hit unexpected roadblocks when running Kafka clusters at scale.

Costs were rising due to inefficiencies in resource allocation.
Auto-scaling wasn’t handling our stateful workload well.
Kafka node management with Strimzi led to operational complexity.

After months of firefighting, we decided to move from Kubernetes to EC2, a transition that improved performance, simplified operations, and cut costs by 28%.

Here’s the story of that journey, what worked, and the lessons we learned.

Why Kubernetes wasn’t working for us?

1. Resource Allocation Inefficiencies

Kubernetes dynamically manages resources, but in our case, it led to hidden inefficiencies.

For example, when allocating 2 CPU cores and 8GB RAM, we observed that the actual provisioned resources were often slightly lower (1.8 CPU cores, 7.5GB RAM). This discrepancy may seem trivial, but at scale, it resulted in significant wasted resources and unexpected cost overruns.

Imagine paying for a full tank of fuel, but your car only gets 90% of it. Over time, those missing liters add up.

2. Auto-Scaling Challenges for Stateless Applications

Kubernetes’ auto-scaling mechanism works well for stateless applications, but Kafka isn’t stateless. When resources ran out, Kubernetes would restart our Kafka application instead of efficiently scaling it.

This resulted in:

15-second delays in message processing.
Increased latency during scaling events.
Operational headaches managing stateful workloads.

3. Kafka Node Management with Strimzi

Initially, we relied on Strimzi for managing Kafka clusters. However, it had major drawbacks:

New Kafka nodes often failed to integrate properly.
Manual intervention was required for every scaling event.
Overall Kafka performance was unpredictable.

Managing our Kafka clusters felt like playing whack-a-mole every time we solved one issue, another would pop up.

Decided to move to EC2

After evaluating various alternatives, we decided to move Kafka from Kubernetes to EC2. This gave us more control over resource allocation, auto-scaling, and cluster management.

Here’s what changed:

1. Replacing Strimzi with a Custom Kafka Controller

Instead of relying on third-party tools, we built an in-house Kafka Controller tailored to our needs.

Seamless integration of new Kafka nodes
Automated scaling based on real-time workload analysis
Better cluster management with minimal manual intervention

Result? Kafka nodes were now automatically recognized and integrated instantly.

2. Precise Resource Allocation

Unlike Kubernetes, where we had limited control over resource provisioning, EC2 allowed us to:

Allocate exactly the CPU and memory we needed.
Avoid wasted resources and over-provisioning costs.

Example: Previously, we paid $180/month per instance on Kubernetes. After transitioning to EC2, this dropped to $130/month, saving 28% on infrastructure costs.

3. Streamlined Kafka Node Support

With EC2, we could now:

Scale up Kafka nodes seamlessly without restarts.
Perform vertical scaling (switching to more powerful machines) with zero downtime.
Ensure predictable performance under peak loads.

Last month, we moved from a T-class instance to a C-class instance in EC2 without downtime. If we had been on Kubernetes, this would have required:

Creating a new node group.
Rebalancing partitions manually.
Managing potential downtime.

Instead, on EC2, it was a simple instance upgrade with zero complexity, zero downtime.

The Impact: Cost Savings & efficiency gains

Key lessons & Takeaways

Not all workloads are ideal for Kubernetes – It’s great for general-purpose container orchestration but not always the best for stateful applications like Kafka.
Custom solutions can be worth it – Building an in-house Kafka Controller gave us better control and reliability.
Cost inefficiencies add up – Even small inefficiencies in resource allocation can result in thousands of dollars lost at scale.
EC2 provides better flexibility – We gained granular control over scaling and performance with EC2.

Conclusion

If you’re running Kafka on Kubernetes and experiencing similar issues, EC2 might be a better fit.

Who should consider moving? Teams struggling with stateful workloads on Kubernetes.
Who should stick with Kubernetes? Those managing stateless, highly dynamic applications.

Every infrastructure decision should be guided by workload needs, not just industry trends. Kubernetes is powerful, but for Kafka, EC2 provided the right balance of cost, performance, and operational efficiency for us.

🚀 Hyperswitch Plugin Development Hackathon: Build, Compete, and Win Big! 🚀

Gorakhnath Yadav — Wed, 09 Oct 2024 10:48:02 +0000

Hey developers! 🔥

We’re excited to announce the Hyperswitch's Plugin Development Hackathon, running from October 9th to October 31st, 2024. It’s your chance to develop plugins for Hyperswitch, collaborate with fellow developers, and win big rewards!

What’s the Hackathon About?

You'll be building plugins for platforms like MedusaJS, CommerceTools, or Prestashop, helping to extend Hyperswitch’s payment orchestration platform. Participate individually or as a team (up to 4 members) and tackle real-world payment challenges while competing for awesome prizes!

Key Dates:

Registration Deadline: October 14th, 2024
Approach Submission: October 14th, 2024 (EOD IST)
Final Submission: October 31st, 2024
Demo Day: First week of November 2024 (TBA)

How to Participate:

Sign Up: Register before October 14th to get started.
Submit Your Approach: Outline the core features, integration with Hyperswitch’s API, and edge case handling by October 14th.
Get Shortlisted: The Hyperswitch team will review your submission and notify shortlisted teams.
Develop Your Plugin: If selected, you’ll have two weeks to complete your plugin.
Demo Day: Showcase your plugin in early November, dates to be announced!

Prizes:

MedusaJS Plugin: $2000
CommerceTools Plugin: $2000
Prestashop Plugin: $2000

Ready to showcase your skills? Register today and start building your plugin! Let’s code, collaborate, and win together. 💻

Good luck to all participants! 🎉

Star Us on GitHub
Follow us on twitter

Hacktoberfest 2024 with Hyperswitch

Gorakhnath Yadav — Fri, 27 Sep 2024 09:07:40 +0000

Join the Celebration of Open Source!

Hyperswitch is excited to participate in Hacktoberfest 2024! Join us in building a robust payment infrastructure that serves billions of people worldwide. Contribute to our open-source projects and earn exciting rewards.

How to Get Involved

1. Explore Hyperswitch Repository:

Visit our GitHub page.
Star and watch the repositories to stay updated with new issues.

2. Find Issues to Work On:

Look for issues tagged with "hacktoberfest".
If you have ideas for improvements, feel free to create new issues, and inform us using community channels.

3. Make Your Contribution:

Comment on the issue you want to work on: "I would like to work on this. Can you assign it to me?"
Ensure you follow up within 3-4 days to show you are actively working on it.
Submit your pull request (PR) and link it to the issue. Tag a maintainer for review.

4. Get Support:

Our maintainers are here to guide you. Join our Community for support and to connect with fellow contributors.

5. Earn Swag:

Get one PR merged to earn exclusive Hyperswitch swag.
Get 3 or more PRs merged to receive a special swag kit from Hyperswitch.

Why Contribute?

Learning Opportunities: Enhance your skills by working on real-world projects.
Networking: Connect with a global community of developers.
Rewards: Earn cool swag for your contributions.

Join the Hyperswitch Community

Star Us on GitHub

Happy Contributing!🎉

Securing Digital Transactions: How Hyperswitch makes Payment Protection a Priority

Gorakhnath Yadav — Thu, 01 Aug 2024 09:26:44 +0000

Security is not a product, but a process - Bruce Schneier

In today's digital landscape, data security is paramount, especially when it comes to online payments. At Hyperswitch, we've built our platform with security as a fundamental principle. Let's explore the robust measures we've implemented to ensure a safe and secure payments infrastructure.

Our Top Priority: Customer Security

When a customer makes a payment through Hyperswitch, their card information is immediately encrypted at the source. We use the SSL/TLS 1.2 protocol for transmission, adhering to PCI standards for handling card data.
For customers who opt to store their card details, we've developed a secure Card Vault. This system employs multiple layers of protection:

SSL/TLS 1.2 encryption
JWE + JWS for secure data transmission
Double encryption for stored data
A two-key custodian system for enhanced security

Additionally, all customer Personally Identifiable Information (PII) is TLS encrypted in transit and AES encrypted at rest.

Keeping Your Business Secure

For our merchant, we know that not everyone needs to be in on all the secrets. That's why we've built up an access control system that's more discerning. API credentials? We treat those with more care than a rare vintage car, wrapping them in layers of AES encryption. Also, we mask the sensitive merchant details in the dashboard.

Hyperswitch's Approach to Security

At Hyperswitch, we're not just building a payment system; we're crafting a digital fortress. Our multi-tenant system comes with unique data encryption keys for each business, creating a security layer that's both impressive and effective.
We've also enlisted Rust as our companion, using its robust type system to keep sensitive information under wraps. It's like having a very diligent, slightly obsessive assistant who never lets a secret slip.

Serious Security with a Smile

In the end, we're not just developing an application; we're creating a secure future for digital transactions. Our goal is to allow businesses to focus on their core competencies while we ensure the protection of their customers' financial information.
With Hyperswitch, security isn't just a feature—it's a cornerstone of our service. We're dedicated to maintaining the highest standards of data protection, giving both merchants and customers peace of mind in their digital transactions.

Want to contribute? Check out some of our good first issues here.
Try Hyperswitch. Get your API keys here. Happy reading!

Scaling to 125 Million Transactions per Day: Juspay's Engineering Principles

Gorakhnath Yadav — Wed, 19 Jun 2024 14:32:56 +0000

At Juspay, we process 125 million transactions per day, with peak traffic reaching 5,000 transactions per second, all while maintaining 99.99% uptime. Handling such enormous volumes demands a robust, reliable, and scalable system. In this post, we'll walk you through our core engineering principles and how they've shaped our engineering decisions and systems.
When designing systems at this scale, several challenges naturally arise:

Reliability vs Scale: Generally, as you scale, you tend to exhaust resources, which can affect system availability.
Reliability vs Agility: Frequent releases and system changes can impact system reliability.
Scale vs Cost-Effectiveness: Scaling requires more resources, leading to higher costs.

Core Engineering Pillars

We've been able to strike the right balance between these challenges by anchoring our tech stack on four pillars:

Build zero downtime stacks: Solve reliability by building redundancy at each layer to achieve almost 100% uptime.
Horizontally scalable systems: Solve scalability by building systems that can scale horizontally by removing bottlenecks.
Build agile systems for frequent bug-free releases.
Build performant systems for low latency, high throughput transaction processing.

Adopting Haskell Programming Language

To achieve our goals, we've made a critical investment: adopting the Haskell programming language. Haskell, a functional programming language, offers performance akin to C, which is closer to the machine and processes transactions much faster. With Haskell, we've reduced our transaction processing time to less than 100 milliseconds.

Here's an example of a Haskell function that adds two numbers:

-- Define the add function
add :: Int -> Int -> Int
add x y = x + y

-- Main function to test the add function
main :: IO ()
main = do
    let sum = add 3 5
    putStrLn ("The sum of 3 and 5 is " ++ show sum)

This function showcases Haskell's concise and readable syntax.

Additionally, Haskell's readability, like English, enables non-technical folks to read the code easily, verify business logic, and sign off on features during development itself. As a strong-typed language, Haskell enforces a set of rules to ensure consistency of results, helping us preempt failures and achieve zero technical declines.

Cache-based Shock Absorber

To handle scale and remove database bottlenecks, we introduced a horizontally scalable caching layer where real-time transactions are served from this cache layer and later drained to the database.

Scaling up and down the cache layer is relatively easy and cost-effective compared to scaling databases.

Rapid Deployment and Release Frameworks

With rapid development comes the challenge of frequent production releases. To achieve agility through frequent releases without compromising reliability, we've built internal tools for automated releases with minimal manual effort. These tools monitor the performance of the release by benchmarking error codes against the previous stable version of the codebase:

ART (Automated Regression Tester): A system that records production payloads and runs them in the UAT system against a new deployment to identify bugs early.
Autopilot: A tool that creates a new deployment and performs traffic staggering from 1% onwards.
A/B testing framework: A system that monitors and benchmarks the new deployment's performance against the previous stable version. Based on this benchmark, the system automatically decides to scale up the traffic or abort the deployment.

Hyperswitch: An Open-Source Payments Switch

We're carrying these learnings forward to our latest product, Hyperswitch, an open-source payments switch. Every line of code powering our stack is available for you to see. With Hyperswitch, our vision is to ensure every business has access to world-class payment infrastructure.

Conclusion

Through these investments, we've built reliable, agile, and scalable systems, enabling our engineers to solve exciting new problems and fostering a culture of systems thinking within the company. We encourage developers to engage with the open-source Hyperswitch project and explore the principles and technologies we've adopted to handle massive scale and high-volume transaction processing.

RFC 003: Quantum Entangled Payment Methods

Vedant Khairnar — Mon, 01 Apr 2024 13:45:08 +0000

I. Objective

This RFC presents an approach for reducing application latency using quantum entanglement. Currently Hyperswitch is optimized for sub 30ms application overhead. By integrating advanced quantum mechanics with traditional networking principles, Hyperswitch aims to revolutionize payment processing speeds, security, and inter-dimensional commerce.

II. Proposal

Modern networking technologies have reached their limits in terms of speed and efficiency, often constrained by the limitations of spacetime. Hyperswitch proposes the use of quantum entangled wormholes to bypass these limitations entirely. This approach allows for instantaneous data transfer and transaction processing across the multiverse.

Data Transmission

In this approach, payment method data is transformed into qubits and transmitted through PCI compliant quantum entangled wormholes. These wormholes act as portals between different points in spacetime, allowing for instantaneous data transfer without the constraints of traditional networking protocols.

Payment Processing

Similarly, Hyperswitch leverages these wormholes for payment processing, enabling instant and secure transactions across multiple dimensions. Users can simply select the Hyperswitch payment option during checkout, and the transaction will be processed through a quantum entangled wormhole to the merchant's account in their respective dimension. This is made possible through Hyperswitch’s direct connection to major wormholes across dimensions.

Security and Reliability

Quantum entangled wormholes offer unparalleled security and reliability. Any attempt to intercept or tamper with the data or transaction would collapse the quantum state, rendering the information unreadable and invalidating the transaction. Additionally, the self-healing nature of the entangled wormholes ensures persistent delivery retry and automatic audit trails.

III. Open Questions

What are the ethical implications of interdimensional commerce?
How can we ensure backward compatibility with existing payment systems across different dimensions?
How will payments be routed through wormholes?
How many direct connections will be necessary?

Frame Format

Data and transactions are encoded into qubits and transmitted through quantum entangled wormholes. The bandwidth and MTU (Maximum Transmission Unit) of the wormholes are theoretically unlimited, allowing for high-speed data transfer and large-scale transaction processing across multiple dimensions.

Security Considerations

While security is inherently robust due to the principles of quantum mechanics, additional measures such as quantum encryption and multi-dimensional authentication protocols may be required to protect against advanced threats from alternate realities or parallel dimensions.

IV. Conclusion

Hyperswitch's proposal to use quantum entangled wormholes for data transmission and payment processing represents a significant leap forward in the field of networking and commerce. By overcoming the limitations of traditional spacetime-based technologies, Hyperswitch aims to create a truly interconnected and secure global marketplace across the multiverse.

Possible Implementation

Read and understand the general guidelines on contributing to Hyperswitch
Import postman collection of hyperswitch from here
Understand the implementation of all different payment flows and how to add a connector
Test the following flows - Payment, Capture, Void and Refund using postman for your local implementation and generate relevant screenshots of the test cases.

Embark on an enlightening journey through the intricate world of payments. These blogs are your compass to navigate the complexities of the payment galaxy.

As developers, we create a lot of value through the applications we build. Payments are the means to capture some of that value for ourselves. Surprisingly, the effort to set up a payments stack is often exaggerated. This is what we aim to solve at Hyperswitch by building a free and open payments switch. If you resonate with this vision, you can join the movement to help build an open payments ecosystem!

Learn more about how you can set up your own payments stack in minutes with Hyperswitch

On a serious note, Hyperswitch is Hiring:

Go to GitHub Discussions and bookmark our Hiring Challenge.

Why we're changing our hiring process 🚀🎸

NarsGNA — Tue, 19 Mar 2024 15:12:15 +0000

Identifying high potential talent

The Beatles are probably one of the greatest bands to have ever existed and they have produced timeless albums for almost a decade. A lot has been said about each of the band members John, Paul, Ringo, and George but there’s very little coverage on their manager Brian Epstein and producer George Martin. These guys were instrumental in channeling the raw talent and energy that the Beatles radiated. Perhaps there's a lot to learn from how these guys decided to work with the Beatles even while they were just a very small band in Liverpool.

Brian was running his family’s music store when we heard of the Beatles for the very first time from a customer requesting their music. He followed them for a while at their local performances and really seemed to like what he describes as their “presence”. This is how he describes his first meeting with the band:

“….like they were fresh and they were honest and they had what I thought was a sort of presence and this is a terrible word, a vague star quality…” ⭐🎶

Initially, even the band's producer wasn't particularly captivated by their sound since it diverged significantly from what he was accustomed to. However, he notes that what ultimately persuaded him to produce their music was their charisma and attitude, rather than solely their skill level at the time. 🌟🎵💫

While knowledge and skills can be taught, it can be really hard to change traits like curiosity or passion for building stuff. It might seem fuzzy but I’ve come to realize that it’s ultimately these characteristics that differentiate good developers from the great ones. This became even more apparent for our team during Hacktoberfest. We asked ourselves some fundamental questions: What actually gets measured in an interview? Do resumes really matter? It set off a series of events that made us completely redesign our hiring process. 🎉💡💼

What we learnt from Hacktoberfest

Hacktoberfest was a wild experience. We got the opportunity to work with 70+ new contributors from across 7 countries 🇫🇷🇩🇪🇮🇳🇺🇸🇺🇦🇲🇾🇳🇱. We had created a pool of 110+ issues, closed 110+ PRs and gained 3k+ stars over the course of the month. The energy and enthusiasm were nothing like we had ever seen before. Given that our project requires significant payments domain knowledge, we were pleasantly surprised to see participation at this scale. In fact, this momentum continued even after Hacktoberfest was over. It’s super satisfying to interact with a developer from the other side of the globe, especially when they're asking the right questions, speaking your language and really understanding the essence of what you are building. 🌍🌟👨‍💻

That’s when it clicked. Why don’t we redesign our entire hiring process to fully leverage the open-source nature of our project? While we might come from diverse cultural backgrounds, open source presents a unique opportunity to communicate through code. And our code is open for you to see! We wanted to make sure that the process gives each applicant a clear picture of what it is like to work at Hyperswitch, what problems we are solving and what exactly it feels like to collaborate with our team! 💻👥🔍

What we look for in a developer

That is why we want to spend more time understanding what you can do rather than who you are. Are you a fresher or have very few years of experience? Are you completely new to Rust? Are you overwhelmed by all the payment domain buzzwords? You do not have to worry because we have designed the process to be fair for everyone across levels. ✨🤝💡

“Even a billion dollars of capital cannot compete with a project having a soul.” - Vitalik Buterin

Ultimately, we believe that payments should be a basic utility like water or air. This is important because the payment ecosystem is full of closed systems and walled gardens. It is also extremely diverse (as it should be). In order to enable this diversity, payments need a trusted unifier like Linux. The road to commoditize payments will not be easy and we are looking for engineers that can make it happen. If this vision resonates with you, consider applying for Hyperswitch and we’d love to work with you! 🌟🔧🌈

What is Hyperswitch

Vedant Khairnar — Fri, 15 Mar 2024 13:23:07 +0000

As your business expands, it's essential to have a payment infrastructure that can handle larger transaction volumes and support local and alternate payment methods required by newer geographies.

A single payment processor might not fulfil your requirements, so you must integrate additional payment processors. But here's the catch: integrating additional payment processors involves a lot of dev effort, which makes it costly and time-consuming.

This is where a payment orchestrator like Hyperswitch comes in. A payment orchestrator pre-integrates multiple payment processors so that businesses don't have to go through the tedious integration process.

A payment orchestrator allows businesses to:

Reduce dev efforts
Increase conversion rates
Optimize processing fees
Reduce dependency on a single processor
Customize checkout experience

Embark on an enlightening journey through the intricate world of payments. These blogs are your compass to navigate the complexities of the payment galaxy.

Learn more about how you can set up your own payments stack in minutes with Hyperswitch

Want to contribute? Check out some of our good first issues here.
Try Hyperswitch. Get your API keys here. Happy reading!

What happens when you click pay now?

Vedant Khairnar — Thu, 14 Mar 2024 11:57:11 +0000

This chapter will cover the payment flows available with Hyperswitch. Please reach out to us to learn more about the payment flows supported!

Payments flow

There are multiple stages in a Payment flow depending on the payment methods that are involved. Considering an one-time payment method where there was no redirection involved, the following stages form the Payment flow:

a. Creating a Payment: When your customer wants to checkout, create a payment by hitting the payments/create endpoint. Fetch and store the payment_id and client_secret

b. Loading the SDK: After your customer checks out, load the Hyperswitch SDK by initiating it with the client_secret and publishable_key

c. SDK being rendered: After you initiate the SDK, the SDK makes several API calls involving the /sessions and /payment_methods endpoints to load relevant payment methods and any saved cards associated with the customer

d. Customer enters the payment method data: After the SDK is fully rendered, your customer would choose a payment method and enter the relevant information and click pay

e. Confirming the payment: After the customer clicks pay, the SDK calls the payments/confirm endpoint with the customer's payment method details and post response, it displays the payment status

Here's a more detailed version of the payment flow:

How does Payment flow vary across Payment methods?

Customer Action	Direct/Redirect flows	Payment - finalized immediately	Payment - finalized later
Customer action required before payments/ confirm	Within Hyperswitch SDK	Non 3DS Cards	Bank Debits like ACH Debit, BACS Debit, SEPA Debit
Customer action required before payments/ confirm	3rd party Redirect/SDK	- Wallets like Apple Pay, Google pay, Paypal, AliPay - BNPL like Klarna, Afterpay, Affirm
Customer action required after payments/ confirm	3rd party Redirect	- 3DS cards - Bank Redirects like iDeal, Giropay, eps	- Bank Transfers like ACH Transfer, SEPA Transfer, BACS Transfer, Multibanco - Crypto wallets like Cryptopay

Use-cases supported by Hyperswitch

Accept online payments Get started with accepting one time payments globally on your online store
Store mandates & recurring payments Setup payments for a future date or charge your customers on a recurring basis
Manage payouts Facilitate payouts for global network of partners and service providers
Save a card during payment Learn how you can save your customers' cards in a secure PCI compliant manner
Manage payments on your platform/marketplace Accept payments from your customers and process payouts to the sellers on your marketplace
Accept payments on your e-commerce platform Give your Wordpress store a lightweight an embedded payment experience with the Hyperswitch WooCommerce plugin
Create payment links Accept payments for your products through reusable links without writing any code

What are `PaymentIntent` and `PaymentAttempt` objects and how do they work in Hyperswitch?

Hyperswitch uses the PaymentIntent object to track the status of a payment initiated by you. Since, Hyperswitch enables retrying a single payment multiple times across different processors until a successful transaction, we track each of these payment attempts through separate PaymentAttempt objects.

While PaymentIntent and PaymentAttempt have their own state machines, the various states in PaymentAttempt are also constrained by their respective mapping to the PaymentIntent statuses.

PaymentIntent state machine

The following is an abridged version of the PaymentIntent state machine flow that covers majority of the above payment use-cases.

PaymentAttempt state machine

The following is an abridged version of the PaymentAttempt state machine flow that covers majority of the above payment use-cases.

Embark on an enlightening journey through the intricate world of payments. These blogs are your compass to navigate the complexities of the payment galaxy.

Learn more about how you can set up your own payments stack in minutes with Hyperswitch

Want to contribute? Check out some of our good first issues here.
Try Hyperswitch. Get your API keys here. Happy reading!

Hyperswitch by Juspay

Vedant Khairnar — Wed, 13 Mar 2024 11:39:38 +0000

"With Hyperswitch, our vision is to enable every digital business to get access to the best payments infrastructure, which they need to run their business efficiently - focusing on their core, not on the complexity of payments," says Sheetal Lalwani, Chief Operating Officer, Juspay.

We, at Juspay have transformed the payment landscape by providing comprehensive solutions to leading global enterprises and major banks in India.

During this time, we have cleared several engineering challenges, and we are applying our expertise and learnings to make Hyperswitch a fast, reliable, and affordable payment switch.

We are also utilizing 🦀 Rust to ensure type safety and leverage its robust features in our development process.

Join our co-founder as he talks about how our team leveraged insights gained from building Juspay to develop HyperSwitch, an end-to-end global payment solution that addresses the complex challenges in the payment ecosystem, allowing businesses to prioritize their core capabilities.

Learn more about how you can set up your own payments stack in minutes with Hyperswitch

Want to contribute? Check out some of our good first issues here.
Try Hyperswitch. Get your API keys here. Happy reading!

DEV Community: Hyperswitch

Prism: A stateless payment integration library extracted from 4 years of production

The Problem

Why unbundle at all?

Why protobuf for the specification?

The implementation: Rust at the core

The two-phase transformer pattern

Two ways to use it

Mode 1: The embedded SDK

Mode 2: The gRPC server

Code generation: the glue that holds it together

Walking through a real authorize call

Where we go from here — together

Open-Source Payments: Modular, Flexible, and Built for You

Why Hyperswitch?

Backed by a Global Engineering Force

Freedom from Closed-Loop Systems

Take Control of your Payments

Transitioning from Kubernetes to EC2 for Enhanced Kafka Performance

Why Kubernetes wasn’t working for us?

1. Resource Allocation Inefficiencies

2. Auto-Scaling Challenges for Stateless Applications

3. Kafka Node Management with Strimzi

Decided to move to EC2

1. Replacing Strimzi with a Custom Kafka Controller

2. Precise Resource Allocation

3. Streamlined Kafka Node Support

The Impact: Cost Savings & efficiency gains

Key lessons & Takeaways

Conclusion

🚀 Hyperswitch Plugin Development Hackathon: Build, Compete, and Win Big! 🚀

What’s the Hackathon About?

Key Dates:

How to Participate:

Prizes:

Hacktoberfest 2024 with Hyperswitch

Join the Celebration of Open Source!

How to Get Involved

Why Contribute?

Join the Hyperswitch Community

Securing Digital Transactions: How Hyperswitch makes Payment Protection a Priority

Our Top Priority: Customer Security

Keeping Your Business Secure

Hyperswitch's Approach to Security

Serious Security with a Smile

Scaling to 125 Million Transactions per Day: Juspay's Engineering Principles

Core Engineering Pillars

Adopting Haskell Programming Language

Cache-based Shock Absorber

Rapid Deployment and Release Frameworks

Hyperswitch: An Open-Source Payments Switch

Conclusion

RFC 003: Quantum Entangled Payment Methods

I. Objective

II. Proposal

Data Transmission

Payment Processing

Security and Reliability

III. Open Questions

Frame Format

Security Considerations

IV. Conclusion

Possible Implementation

On a serious note, Hyperswitch is Hiring:

Why we're changing our hiring process 🚀🎸

Identifying high potential talent

What we learnt from Hacktoberfest

What we look for in a developer

What is Hyperswitch

What happens when you click pay now?

Payments flow

How does Payment flow vary across Payment methods?

Use-cases supported by Hyperswitch

What are PaymentIntent and PaymentAttempt objects and how do they work in Hyperswitch?

PaymentIntent state machine

PaymentAttempt state machine

Hyperswitch by Juspay

What are `PaymentIntent` and `PaymentAttempt` objects and how do they work in Hyperswitch?