How to Build a Payment Gateway: Lessons from Building a Gateway that Saved Up to $100M

The decision to build a custom gateway typically arises when off-the-shelf tools can no longer keep pace with growing business needs. But such a decision is rarely made lightly, as there’s always that question in the background: will the investment pay off with a reliable system, or turn into yet another resource-draining headache?

To help you steer clear of the second scenario, in this article we’ll walk through the way of how to create a payment gateway the Expert Soft team followed to build a custom payment gateway for an enterprise client.

This is a behind-the-scenes look at what an actual solution can be. Just as important, we’ll share the hands-on insights we gained along the way — the kind that help you avoid common pitfalls and boost the odds that your custom solution becomes a success story, not a cautionary tale.

Quick Tips for Busy People

No time to read it all? Here are the core steps of building a custom payment gateway, based on our experience.

• Start with business alignment. Involve finance, legal, and ops early. A cross-market compatibility matrix prevents scope creep and late-stage surprises.
• Don’t delay abstraction. Build a unified routing layer from day one to avoid duplicated logic and simplify future integrations.
• Validate providers early. Check SDK quality, sandbox availability, and API stability before committing to any provider.
• Map compliance into architecture. Define data flow, storage, and encryption rules upfront to stay within PCI DSS and local regulatory scope.
• Design for failure scenarios. Normalize errors, implement retries, and keep users in context to reduce friction during failed payments.
• Log with purpose. Use structured logs linked to users, orders, and providers. Make data accessible to both tech and business teams.
• Keep modules independent. Build each provider as a standalone module to simplify testing, updates, and multi-region scaling.

Now, let’s break down the full process of how to set up a payment gateway that works in the real world.

Role of a Payment Gateway

A payment gateway routes requests between your store and external providers, acting as the control layer, as well as managing how payments are initiated, validated, and tracked across systems.

If you’re building a custom payment gateway, your system should be designed to handle the following core tasks:

A well-architected custom payment gateway also needs to offer more than basic functionality. It should include an abstraction layer to hide provider-specific logic, be scalable enough for high transaction volumes, be compliance-ready from day one, and be extensible to support new payment methods or regulatory changes without rewriting core logic.

In short, if you’re developing a payment gateway, it’s necessary to make it flexible, secure, and scalable.

Ready-Made vs. Custom Gateway: Expert Soft’s Client Choice

Ready-made solutions, such as Stripe or Adyen, cover a lot of ground, but they’re not always flexible enough for businesses with multi-platform needs. In such cases, you may prefer to create your own payment gateway.

Let’s see a practical example of one of Expert Soft’s clients in ecommerce healthcare — a global manufacturer and seller of medical equipment. They operated three separate online stores: one for equipment, one for spare parts, and one for training. Each had its architecture, but all relied on the same set of payment providers. Managing payments consistently across these disconnected systems became a major challenge.

So, the company decided to opt for a centralized payment engine that unifies transaction routing across all three platforms. The goal was to simplify integrations, reduce duplication, and make it easier to onboard new providers in the future.

Below are the reasons why, in this case, a custom gateway was a more efficient choice than a ready-made one.

Unified multi-market architecture

Managing payments across three distinct storefronts meant dealing with very different business flows under the hood. Depending on the type of inventory and markets available, each store had its checkout logic, legal requirements, and preferred payment methods.

Serving as a centralized payment layer across all platforms, the payment gateway made it easier to manage and scale transactions. It unified the payment layer, supported country-specific variations, and routed transactions to the appropriate provider. This allowed us to decouple payments from the storefronts while maintaining flexibility and simplifying regional expansion.

Support for local payment providers

In our case, supporting the client’s multi-country expansion meant dealing with providers that mainstream platforms couldn’t easily accommodate:

• Inicis (Korea): provided essential market coverage but offered limited support for testing environments.
• Soundbank (Japan): had a non-standard API design that deviated from common transaction lifecycles.
• Ingenico (India) and Checkout.com (US): each came with their SDKs or constraints.

With each provider’s specifics, it was difficult to ensure smooth operation within ready-made solutions. Our custom gateway, in turn, lets us handle them cleanly, using custom extensions or APIs.

Regulatory and compliance constraints

Compliance standards for B2B payment gateways are typically more stringent than those for B2C. For our client, that meant aligning with PCI DSS and regional data protection laws from day one.

At this point, the custom solution offered us more flexibility than ready-made ones. So we were able to embed security requirements directly into the architecture. This gave the team full control over how data was handled, stored, and audited.

Operational control and extensibility

As the client’s needs grew, so did the pressure on their payment system.

Over time, the gateway needed to support:

• Seamless provider switching (e.g., from Cybersource to Checkout.com);
• Reuse of customer payment tokens across providers;
• Custom reports, fraud tracking, and transaction history auditing;
• Business-driven rollout schedules and monthly release cycles.

A custom solution gave the company full control over provider logic, data, and timelines, built to grow with the business.

This level of control is often achievable only when you make a payment gateway tailored to your specific needs.

Performance and reliability

Although the system handled B2B transactions, meaning lower volume than consumer commerce, reliability was paramount. So, building a payment gateway with such robustness ensures uninterrupted service in critical scenarios.

We implemented retry logic, clean error feedback, and a modular setup that scaled payment components independently. Even under load or provider issues, the system stayed stable thanks to an architecture built for flexibility and resilience.

Custom Payment Gateway: Architecture Overview

For the client, we built the gateway as a modular and extensible layer within the SAP Commerce ecosystem. This setup isolated complexity from the storefronts, supported multi-market operations, and gave the client full control over how payments were handled across regions and platforms.

This is how the gateway looks from the inside.

Core architectural components

Setting up a payment gateway typically includes several key components, each responsible for a specific part of the transaction flow. In our system, we brought these elements together in a modular architecture built for scale and adaptability.

If you’re planning to build your own gateway, this structure can serve as a blueprint to ensure flexibility, security, and long-term maintainability.

Provider integration layer

Each payment provider was implemented as a dedicated SAP Commerce extension, following a shared interface defined by the Core Router. This structure allowed us to keep provider-specific logic separate while maintaining a consistent command flow for operations like auth, capture, void, and refund.

To name some of the available providers, we built modules for Checkout.com (US), Inicis (Korea), Soundbank (Japan), and Ingenico (India). Each module handled its endpoints, credentials, and transaction lifecycles, with built-in error parsers to align provider responses with system-wide handling.

Overall, creating your own payment gateway with such modularity facilitates easier maintenance and scalability.

Data flow and transaction lifecycle

Each transaction followed a structured flow designed to keep payment logic centralized and storefronts clean.

At checkout, the storefront sent cart and customer data to the gateway. The gateway created a mirror cart and displayed a secure, standalone payment form. Once the user submitted their info, the Core Router selected the appropriate provider based on region and context.

The provider module processed the transaction: authorization, capture, or sale, and returned the result. The gateway stored the outcome, notified the storefront, and, if successful, triggered order creation.

Post-payment, the system handled invoicing and logged all transaction data for reporting and compliance, ensuring visibility and traceability across every step.

Security and compliance handling

If you’re researching how to create an online payment system, start by mapping out your compliance boundaries: what needs to be encrypted, isolated, or tokenized, and build from there.

The system in our project was designed with strict security controls to meet PCI DSS and regional compliance standards at a technical level.

Sensitive card data was never stored. CVV codes were excluded entirely, and PANs were masked, with only the last four digits retained. For recurring payments, we used tokenization to avoid handling raw card data altogether.

All data in transit was encrypted using HTTPS and TLS. The payment form was fully decoupled from the storefront, minimizing data exposure. 3D Secure authentication flows were handled externally by the provider via redirects, ensuring sensitive verification data stayed outside our infrastructure and reducing PCI audit scope.

The next steps for anyone wondering how to make my own payment gateway include defining what needs to be abstracted, what regions to support, and how much control is required at the routing layer. We also follow these steps while building the gateway for the client.

Steps for Building a Gateway with Key Recommendations

Below are the steps we followed when building the gateway for the client with insights gained.

Step 1: Define the scope and requirements

This step is crucial when you’re considering how to create a payment gateway for a website that aligns with diverse business needs.

Before writing a single line of code, we started where it really counts — understanding the business. That meant involving teams across ecommerce, finance, legal, IT, and regional operations. Each brought a different view of what the gateway needed to support: countries, currencies, payment methods, customer expectations, and compliance rules.

We ran discovery workshops with stakeholders from every key market. In several cases, provider choices were dictated by regulation or local availability. For instance, Inicis was a must in Korea because of local requirements without any alternative options.

Here, we had to rely deeply on business analysts to translate these requirements into something the architecture could support.

Recommendation: Hold regional workshops early to surface legal constraints, preferred providers, and customer expectations. Build a country-by-country compatibility matrix to keep scope clear and avoid costly surprises later.

Step 2: Create an architectural blueprint

When developing a custom payment gateway, it can be tempting to integrate the initial provider with tightly coupled logic for the sake of speed. However, without a unified routing layer, each additional provider introduces redundant code, fragmented logic, and increased maintenance complexity.

In the early stages of our project, we focused on getting providers connected fast and skipped a central router, causing redundant logic across provider integrations. We corrected the course by introducing a central router that handled provider selection and transaction delegation through a shared command structure. That one architectural shift cut integration time in half and made the entire system easier to scale and debug.

Recommendation: Start with a clear abstraction layer, even if you’re integrating just one provider. Define a unified contract for key operations: authorize, capture, refund, void, and build around that from day one. It’ll save you time, reduce errors, and make future integrations easier.

Step 3: Evaluate payment providers

Payment providers may check all the boxes on paper, but the real test comes during integration. SDKs vary widely in quality: some are outdated, others poorly documented, and a few don’t offer sandbox environments at all.

For example, Checkout.com’s SDK required patching to even get started, and Inicis didn’t offer a test environment, so we had to set up internal QA support in Korea using real cards to validate transactions.

Recommendation: Don’t assume every provider is ready for production use. Validate SDKs early, confirm whether API fallback is an option, and secure local testing resources in regions with sandbox limitations. It’s the only way to avoid roadblocks mid-build.

Step 4: Ensure compliance and security from day one

When it comes to payments, security and compliance are foundations. From the beginning, we set strict rules for how sensitive data would be handled:

• CVV data was never stored;
• Masked card data and non-sensitive metadata were selectively persisted;
• 3D Secure authentication was always offloaded to providers’ hosted pages, simplifying our compliance burden.

One of the valuable moves we made early on was building a detailed data flow diagram. It gave our security team a clear view of where data entered and exited the system.

Recommendation: Map your payment data flow upfront and involve your DevOps and InfoSec teams early. Define what can be stored, how it’s protected, and where your system falls within PCI DSS scope. It saves time, reduces audit friction, and strengthens your security posture from day one.

Step 5: Handle failure and retry mechanisms gracefully

Payment failures are inevitable, so you need a plan on how to handle them with minimal impact. For example, we had to deal with vague or inconsistent error codes from Soundbank. Such responses made it harder to identify and handle failures reliably. To avoid confusion, we built logic into the core router to normalize these messages and return clear, actionable feedback to the UI.

When a transaction failed, users didn’t get kicked out or lose their progress. Instead, they stayed on the gateway screen and could retry without re-entering payment details or rebuilding their cart, keeping the experience smooth.

Recommendation: Design with failure in mind. Normalize provider errors, build retry logic into your flows, and test how the UI responds to edge cases.

Step 6: Set up transaction logging and reporting

If your finance or operations teams rely on detailed analytics, make transaction visibility a core feature. Structured logging and seamless export into BI tools can save hours in reconciliation, reporting, and troubleshooting.

Our client needed monthly revenue validation, anomaly detection, and detailed chargeback investigations. To support this, we built logging into the system from the start, capturing everything from timestamps and currency to provider responses and user identifiers. This data fed into custom reports, used monthly by finance to validate revenue, spot anomalies, and investigate chargebacks. Logs also supported dispute resolution and performance tuning.

Recommendation: Use structured, searchable log formats and include identifiers that tie events to user sessions, orders, and providers. This makes your system not just traceable, but truly audit- and insight-ready.

Step 7: Ensure maintainability and deployment simplicity

For our client, staying agile across markets meant regularly updating providers, adding new ones, and aligning releases with internal QA and business cycles. To support that pace, the system needed to be easy to maintain and fast to deploy without introducing risk.

To keep things scalable, we packaged each provider as a separate module, allowing teams to test, deploy, and update integrations independently. Automated tests were run per region, and every rollout followed a clear, documented playbook.

This modular setup made a real impact: provider integration time dropped from two months to just three to four weeks. And monthly deployments stayed in sync with both QA and business timelines.

Each step in building the gateway contributed to a system that was secure, scalable, and easy to evolve. After all, with a thoughtful approach and high attention to details and business requirements, the gateway delivered helped not only to streamline payment management but also saved the company about $100M on operational expenses.

Lessons Learned

Every complex implementation comes with its pitfalls and leaves behind insights that can be a real treasure for future projects. Here are the ones that made the difference throughout the gateway development process.

For any team considering a custom gateway, these lessons offer a clear direction: plan for scale early, prioritize maintainability, and treat compliance as architecture, not overhead.

To Sum Up

For this medical equipment manufacturer, a custom gateway was the only viable solution for a fragmented, multi-country ecommerce operation. Off-the-shelf tools couldn’t support critical providers, nor could they align with the client’s strict compliance model or internal release cadence.

So, if limitations and customizations a ready-made payment provider requires outweigh the capabilities it brings, maybe it’s a sign to consider a custom solution. In this case, prioritize modular design, centralized routing, and clear abstraction from the start. Treat compliance as a core part of the system, not an add-on, and structure your logging for full visibility. These principles make it easier to scale, maintain, and trust. These are the foundations that will carry your gateway forward.

If you’re exploring how to create your own payment gateway, reach out — we’d be happy to share our insights or provide professional tech assistance.

FAQ