restu ananda saputra

Posted on Jul 26

The Biggest Payment Mistake Isn't Choosing the Wrong Gateway. It's Designing Your System Around One.

When a team starts building a product that needs online payments, one discussion almost always comes up before any architecture diagrams are drawn or code is written.

Which payment gateway should we use?

Depending on where you're building, the shortlist usually looks familiar. Stripe, Xendit, Midtrans, DOKU, Adyen, PayPal, Braintree, or perhaps a regional provider that dominates the local market. The comparison spreadsheet quickly fills with transaction fees, supported payment methods, settlement times, dashboard features, API documentation, and reliability metrics.

At first glance, it feels like one of the most important architectural decisions you'll make.

But after working on systems that process payments, I've come to think the question itself is slightly wrong.

The real challenge isn't choosing the best payment gateway.

It's making sure your application doesn't become dependent on whichever provider you happen to choose first.

There Is No Perfect Payment Gateway

Every payment provider has strengths, and every provider has limitations.

Some offer excellent support for international credit cards but have limited local payment methods. Others dominate domestic bank transfers yet provide weaker cross-border capabilities. One platform might have outstanding API documentation, while another offers lower transaction fees or faster settlement periods.

Even the largest providers in the industry experience occasional outages, scheduled maintenance, degraded performance, or temporary service interruptions.

That's simply the reality of distributed systems.

No matter how much research you do before launch, there will eventually be a situation where another gateway becomes a better fit for part of your business.

The problem begins when your software isn't prepared for that change.

The Hidden Cost of Tight Coupling

Imagine your application is integrated directly with a single payment gateway.

Your checkout flow calls the provider's SDK.

Your order service stores the provider's transaction IDs.

Your webhook handler understands only one event format.

Your refund logic depends entirely on one API.

At first, everything feels simple.

Until one day it isn't.

Perhaps your biggest marketing campaign begins, and the provider experiences an unexpected outage. Customers can't complete purchases, shopping carts are abandoned, and revenue stops flowing.

Or maybe your company expands into another country where your existing gateway doesn't support the payment methods customers actually use.

Now what seemed like a straightforward integration suddenly becomes a major engineering project.

Instead of adding another payment provider, you're forced to untangle payment logic that's spread across controllers, services, databases, webhook handlers, notification systems, and reporting pipelines.

Changing providers becomes less like swapping a component and more like performing open-heart surgery on a production system.

Thinking in Terms of Architecture, Not Vendors

One lesson I've learned is that mature systems rarely allow business logic to communicate directly with external providers.

Instead, they introduce an abstraction layer.

Rather than asking Stripe to create a payment, or calling Midtrans directly from the checkout service, the application communicates with its own internal payment interface.

Conceptually, the interaction becomes much simpler.

Application
      │
      ▼
Payment Service
      │
      ▼
Payment Abstraction Layer
      │
 ┌────┴─────────────┐
 ▼                  ▼
Stripe         Xendit
 ▼                  ▼
Midtrans        Adyen

From the application's perspective, the request never changes.

Create Payment

Amount: $250
Currency: USD
Payment Method: Credit Card
Customer: #12458

How that payment is ultimately processed becomes an implementation detail hidden behind the abstraction.

Routing Payments Intelligently

Once an abstraction layer exists, routing logic becomes incredibly flexible.

Instead of hardcoding one provider, the system can decide dynamically.

For example:

IF payment_method == Credit Card
    → Stripe

ELSE IF payment_method == Virtual Account
    → Xendit

ELSE IF country == Indonesia
    → Midtrans

ELSE
    → Adyen

That routing logic can become even more sophisticated.

You might choose providers based on:

Customer location
Currency
Transaction value
Provider availability
Processing fees
Historical success rates
Preferred payment method
Regulatory requirements

The business logic never needs to know which provider ultimately handles the payment.

It simply asks for a successful transaction.

High Availability Through Failover

One of the biggest advantages of this architecture is resilience.

Suppose your primary provider becomes unavailable.

Without an abstraction layer:

Checkout
      │
      ▼
Stripe ❌
      │
      ▼
Payment Failed

With intelligent routing:

Checkout
      │
      ▼
Stripe ❌
      │
Retry
      ▼
Adyen ✅
      │
Payment Success

To the customer, the transaction succeeds.

Many users never realize a failover occurred.

That's exactly how resilient systems should behave.

Designing a Payment Interface

A clean abstraction often begins with a simple contract.

Instead of exposing provider-specific APIs throughout the application, define a common interface.

interface PaymentGateway {
    createPayment(request)
    capturePayment(id)
    refundPayment(id)
    cancelPayment(id)
    getPaymentStatus(id)
}

Each provider then implements the same behavior.

StripeGateway

implements PaymentGateway

MidtransGateway

implements PaymentGateway

XenditGateway

implements PaymentGateway

The rest of the application interacts only with the interface.

Changing providers no longer requires changing business logic.

Supporting Future Growth

Another benefit often overlooked is expansion.

Imagine your company launches in Indonesia.

Midtrans works perfectly.

A year later, you expand into Singapore.

Then Australia.

Then Europe.

Each region has different customer expectations.

Some prefer credit cards.

Others use bank transfers.

Some rely on digital wallets.

Others expect Buy Now, Pay Later (BNPL) services.

If your architecture assumes a single payment provider forever, international expansion becomes increasingly difficult.

If your payment layer was designed for multiple providers from the beginning, adding support for another market becomes significantly easier.

You're extending the platform rather than rebuilding it.

Vendor Lock-In Is an Architectural Problem

Vendor lock-in isn't unique to payment gateways.

It happens with cloud providers.

Databases.

Authentication systems.

Message queues.

Search engines.

Storage platforms.

The more tightly your business logic depends on a specific implementation, the harder migration becomes later.

Good architecture isn't about predicting which technology you'll use forever.

It's about assuming change is inevitable.

Abstraction is one of the most effective ways to prepare for that reality.

But Should Every Startup Build This?

Not necessarily.

One mistake engineers sometimes make is overengineering too early.

If you're building an MVP with limited traffic, integrating directly with a single payment gateway is often the right decision.

Shipping a product usually creates more value than designing a perfect architecture that never reaches production.

The key is recognizing when the investment becomes worthwhile.

As transaction volume grows...

As multiple payment methods become necessary...

As expansion into new markets becomes realistic...

As uptime becomes business-critical...

That's when introducing a payment abstraction layer starts paying for itself.

Architecture should evolve alongside the business.

Final Thoughts

When people discuss payment systems, the conversation usually centers on providers.

Which gateway has the lowest fees?

Which dashboard looks better?

Which API is easier to integrate?

Those questions matter.

But they're rarely the most important ones.

The more valuable question is this:

If we needed to replace this provider next year, how much of our application would need to change?

If the answer is "almost everything," then the architecture—not the payment gateway—is probably the real problem.

Sometimes the smartest engineering decision isn't choosing the perfect technology.

It's designing your system so that replacing technology is never a crisis.

That's the kind of flexibility good architecture gives you.

And in software engineering, flexibility often turns out to be one of the most valuable features you can build.

Thanks for Reading

If you enjoy articles about software architecture, backend engineering, scalable systems, AI engineering, cloud computing, and modern application design, feel free to follow my work. I enjoy sharing practical lessons from real-world software development, architectural decisions, and the engineering trade-offs that rarely make it into official documentation.

Outside of writing, I work with founders, startups, and businesses to design and build scalable software solutions—from payment systems and backend platforms to AI-powered applications, automation tools, and cloud-native architectures. If you're building something interesting and need a software engineer to help bring it to life, I'd be happy to connect.

I’ve always enjoyed sharing what I learn, whether it’s from building software, exploring new technologies, participating in research projects, or simply solving problems that took longer than expected. Writing became a natural extension of that process.

Most of my work revolves around software engineering, cloud technologies, system design, artificial intelligence, and digital product development. Over the years, I’ve worked on a variety of projects, from business applications and websites to more technical topics involving architecture, scalability, and emerging technologies. Many of my articles are inspired by real experiences, lessons learned, mistakes made, and observations from working in technology.

What I enjoy most about writing is the opportunity to make complex ideas easier to understand. Some people discover new concepts through books, others through videos. For me, writing is how I explore topics more deeply while hopefully helping others learn something useful along the way.

Joining the Medium Partner Program feels like a natural next step. I plan to continue publishing articles about technology, software engineering, artificial intelligence, personal growth, and the challenges of building products in an increasingly digital world. My goal is not only to share information but also to contribute thoughtful perspectives that readers can apply to their own work, careers, and projects.

🚀 Need help building AI-powered applications, scalable software, mobile apps, web scraping, or business automation?

Contra:

Restu ananda saputra - AI Agent Engineer | Contra

Web Developer creating complex task. View Restu ananda saputra's Profile on Contra. The Independent-first, commission-free freelance marketplace shaping the future of work.

contra.com