Title: How to Pick the Right Payment Gateway for Your Product? Author: Entexis Team Category: Software Development Read time: 11 min URL: https://entexis.in/how-to-pick-the-right-payment-gateway-for-your-product Published: 2026-08-31 --- Almost every custom software team hears the same request at some point. "We just need Stripe wired up. It should be quick." It rarely is. Not because Stripe is hard to wire up (it is not), but because the buyer has usually made the pick before they understood what they were picking. They chose the provider they had heard about, not the provider that fits how their product actually takes money. Half the time, the fit is fine and the work is straightforward. The other half, the buyer is a rebuild away from finding out the provider does not do the thing their product needs it to do. So how do you avoid becoming the buyer in the second half? That is the point of this piece. You will see what a payment gateway actually is in plain English, the 3 buckets almost every payment request falls into, the 3 decisions that decide whether Stripe is right for your product or something else fits better, the 4 things that break payment integrations after launch, a simple shape for a payment layer that does not lock you into one provider forever, and the 3 signs it is time to move from a hosted provider to a custom payment engine. All of it is written for the buyer making the call, not the engineer wiring it up, because the buyer is the person who decides whether the wiring even happens. Why does this decision matter more now than it did a few years back? Because product models have gotten more varied. A payment layer that fit a straight subscription product does not fit a marketplace that splits money across sellers. A layer that fit a US-only buyer does not fit a product taking payments across India, the Gulf, and Southeast Asia. And a layer that fit a small-invoice product does not fit one that runs on wallets, credits, and hybrid pricing. The gateway you would pick today is not always the gateway you would have picked when the product started, and the switch is expensive. Buckets almost every "we need a payment gateway" request actually falls into. Only one of them is a straight provider wire-up. 3Decisions that decide whether Stripe is right for your product, or a different provider fits your model better. 4Things that break payment integrations after launch: refunds, subscription edge cases, tax and compliance drift, and provider policy changes. 1Abstraction layer that keeps your product loose from any one provider. Skipping it is the reason gateway switches turn into rebuilds. The rest of the piece walks the answer in the order the questions show up during a real payment conversation. What is a gateway? Which bucket does your product fit? Which provider is right? What breaks after launch? How do you build a version that survives a provider change? When do you outgrow hosted providers entirely? None of it is exotic; most of it is boring on purpose, because boring is the version that keeps your customers paying without a support ticket. ## A Payment Gateway, Broken Down A payment gateway is the piece of software that sits between your product and the bank networks. When a customer types a card number into your product, the gateway takes that card number, talks to the card networks to see if the payment is good, and reports back to your product whether the money can be collected. Everything else (subscription management, refunds, tax handling, invoicing) is layered around that core job. Stripe, Razorpay, PayPal, Adyen, Paddle: they are all gateways at heart, with different amounts of extra tooling wrapped around them. Why do people build their own instead of using one? Because at a certain scale or with a certain product shape, the standard providers stop fitting. Marketplaces need to split money between multiple sellers on the same transaction. Credit-based products need to add funds to a wallet, not just charge a card. Products in certain regions need providers the global brands do not support well. Products with unusual billing (usage-based, hybrid pricing, promotional credits, partial-refund policies) run into limits inside the standard providers. The custom path is the answer when the standard path does not fit, not when the buyer feels like they should build one. What is the difference between a payment gateway and a billing engine? The gateway takes the payment. The billing engine decides what to charge, when to charge it, how to handle upgrades and downgrades, how to prorate, how to retry failed cards, how to send invoices. Stripe has a billing engine built in (Stripe Billing) that many buyers use without realising it is a separate product. Razorpay has one too. When a buyer says "we need Stripe", they often mean "we need Stripe plus Stripe Billing" without knowing the second piece exists. That difference (gateway vs billing engine) is where a lot of scoping conversations start to unravel. > **Before You Pick a Provider:** If you cannot describe your product's payment flow in one sentence to somebody who has never seen your product, the request is not ready to be built yet. "Customers subscribe monthly and can pause any time" is a scope. "We just need Stripe" is not. Sort out the flow first, then pick the gateway that fits that flow. ## Which Payment Setup Does Your Product Actually Need? Which of the 3 buckets does your product fit? Almost every "we need a payment gateway" conversation resolves into one of these once you push on it. Knowing which one you are in changes everything: the provider, the cost model, the compliance surface, and whether the work is a wire-up or a build. *[Diagram: What "We Need a Payment Gateway" Almost Always Turns Out to Mean]* Bucket 2 You Need a Marketplace or Split-Payment Setup Money comes in from a buyer and has to be split across multiple sellers or partners on the same transaction. Stripe Connect, Razorpay Route, Adyen for Platforms, and similar products exist precisely for this. The provider matters more here because the split model has to match your business model. Roughly a third of payment requests belong here, and they are the ones most often mis-scoped as "we just need Stripe". Bucket 3 You Need a Custom Payment Engine Wallets, credits, usage-based billing, hybrid pricing, regional acquirer routing, or a product that runs across regions where no single provider is strong everywhere. This is real payment engineering. It is a smaller share of requests than most buyers assume, but when the product genuinely needs it, no hosted provider is going to close the gap. This is where the design choices in the rest of this piece really start to matter. How to Sort Yourself Ask: is there more than one seller in a transaction, do your customers hold funds inside your product before spending them, and does any part of your billing sit outside what your first-choice provider natively supports. Two or three yeses push you out of bucket 1. Why does the bucket matter so much before you pick a provider? Because a bucket-1 request wired to a bucket-2 provider is over-engineered. A bucket-2 request wired to a bucket-1 provider is a rebuild waiting to happen. And a bucket-3 request wired to any hosted provider will hit a wall the moment the product tries to do the thing it needed a custom engine for. Getting the bucket right is the single decision that decides whether the rest of the payment work is small or large. ## 3 Decisions That Decide Whether Stripe Is Right for You (or You Need Something Else) Assuming you have sorted yourself into a bucket, which provider fits your product? The 3 decisions below are the ones that show up in almost every payment conversation. Everything else (fees, dashboard quality, developer experience) is second-order once these 3 are answered. 02 What Is Your Revenue Model? Straight monthly subscriptions fit almost every provider's default billing product cleanly. Marketplace transactions need a provider with a first-class split-payment product (Stripe Connect, Razorpay Route, Adyen for Platforms). Usage-based, credit-based, and hybrid pricing push you toward providers with strong metered billing (Stripe Billing, Chargebee on top of a gateway, Recurly, or a custom engine sitting on a gateway). One-time transactions inside a mostly free product usually fit the lightest possible setup. The model has to match the provider's strengths, not the other way around. 03 How Complex Is Your Billing Beyond Just Charging Cards? If your product needs custom invoicing, unusual proration rules, promotional credits, partial refunds tied to complex business logic, or approval workflows before charges hit, you are in "billing engine" territory, not just "gateway" territory. Some providers give you a strong billing engine built in; others expect you to bring your own. Deciding this up front prevents the moment where your team is halfway through the build and realises the provider's billing product does not do what your product needs it to do. > **The Order Matters:** Answer the region question first, the revenue-model question second, the billing complexity question third. Teams that answer them in reverse order often pick a provider based on billing features and then discover it does not clear cards well in the region where their customers actually live. ## 4 Things That Break Payment Integrations After Launch What actually goes wrong with payment integrations once they are live? The 4 below show up in almost every integration that felt clean at launch and started causing tickets a few weeks in. All of them are survivable if the integration is designed with them in mind from day one. Skipping them at launch is why so many payment integrations end up in a rebuild conversation later. 02 Subscription Edge Cases Are the Real Product Upgrades mid-cycle, downgrades mid-cycle, pause and resume, trial-to-paid conversions, cancellations with grace periods, dunning when a card fails, plan changes with prorated credits, seat additions and removals mid-month. Every one of these is a small feature. Together they are the product. Most subscription integrations wire up the happy path (customer picks plan, card charges, product unlocks) and then discover that the actual product is the 12 edge cases nobody drew on the whiteboard. Plan for the edge cases in the design phase, not as they arrive as tickets. 03 Tax and Compliance Drift Quietly The tax rules in the regions where you take payments change without asking you. New sales tax, VAT threshold changes, GST rule updates, changes to how digital goods are treated in a market you already sell in. Most providers offer tax handling as a separate paid product; some integrations skip it and calculate tax in the product itself, which is fine until a rule changes and the internal calculation is now wrong. Decide up front whether tax is the provider's job or your product's job, and if it is your product's job, plan for the rule drift. 04 Provider Policy Changes Land Without Warning The provider updates their acceptable-use policy, tightens their risk model, changes payout timing, drops support for a card brand, or restricts a category your product happens to fall into. You find out from a support email or a payout that does not arrive. Most of the time it is small; sometimes it is a "we can no longer process your business" letter. This is why the abstraction layer covered later in this piece exists. Keeping your product loose from any one provider is what turns "provider dropped us" from a rebuild into a switch. > **Why These Feel Sudden:** None of these 4 arrive with a heads-up. All of them arrive as a customer support ticket, a payout that did not land, a compliance letter, or a policy email. The teams that survive them cleanly designed for them at the start. The teams that did not are the ones doing the payment rebuild conversation a year later. ## A Simple Shape for a Payment Layer That Does Not Trap You With One Provider So what does a payment layer that survives a provider change actually look like? Not fancy. The shape below is the arrangement that keeps your product code from ever calling the provider directly, so that when the provider changes (or you change providers), the swap happens in one place instead of every place your product touches money. Every layer has one job. The layers do not overlap. When something breaks, you know exactly which layer to look at. *[Diagram: A Payment Layer That Keeps Your Product Loose From Any One Provider]* Layer 2 Payment Abstraction One clean interface for every payment operation your product does. Provider names live only inside this layer. Adding a second provider means adding an adapter, not touching your product. Layer 3 Provider Adapters One adapter per provider (Stripe, Razorpay, whatever comes next). Each adapter translates your abstraction into the provider's API and translates provider events back into your abstraction. Layer 4 Reconciliation Store Records every intent, every provider response, every webhook. Your source of truth for what happened. Never derived from the provider dashboard alone. ↓ Cross-Cutting The 3 Guarantees the Payment Layer Provides IdempotencyThe same charge intent, retried, never charges twice. Audit TrailEvery state change is timestamped and traceable back to the intent that caused it. Provider LooseSwitching a provider is an adapter swap, not a product rewrite. Why This Shape Survives Provider changes stay contained. Regional expansions plug in a new adapter without your product noticing. Reconciliation questions have a clean answer that does not depend on a provider dashboard. And when a provider quietly changes policy, the impact is scoped to one adapter, not the whole product. Why go to this trouble when Stripe is right there and it works? Because "right there and works" is true right up until it stops being true. The provider changes a policy, your product expands to a region where the provider is weak, a new regulation lands, or your billing outgrows the provider's built-in billing engine. Teams with the abstraction layer switch providers in a bounded piece of work. Teams without it discover that "payment" is written into every corner of the product and the rewrite is bigger than the original build. ## 3 Signs You Should Move to a Custom Payment Engine When is it time to walk away from a hosted provider and build your own payment engine? The 3 signals below are the ones that keep showing up. If you see more than one at a time, the buy-versus-build math has probably already tipped, even if it does not feel like it yet. 02 You Are Paying More in Provider Fees Than the Custom Build Would Cost At the early volume every provider looks cheap. As transaction volume compounds, provider fees start looking like a real recurring line. At some point, running your own routing across multiple acquirers (or moving to a lower-fee provider you would not have picked at day one) is cheaper than staying with the day-one pick. Watch the fee line as it grows; the crossover is real, and it usually arrives quietly. 03 You Operate Across Regions Where No Single Provider Is Strong Everywhere The card that clears cleanly on your US Stripe account fails on the same brand issued in India, or the Southeast Asian buyer's card gets flagged for fraud that a local acquirer would have accepted. Once you are running in more regions than any single provider serves well, the right shape is your own routing layer over multiple acquirers, not one provider trying to be everything everywhere. This is the moment the custom engine stops being a stretch and starts being the honest answer. > **The Honest Test:** If more than one of the 3 signals above is true and your product genuinely competes on payment reliability or payment cost, the custom engine is no longer optional. If none of them are true, stay with the hosted provider. The custom path is expensive, and it pays back only when the product needs the flexibility it provides. ## Frequently Asked Questions Is Stripe always the right first choice?For products with US, European, or global-first customers and a straightforward subscription or one-time model, Stripe is usually the fastest path to a working payment integration. For products serving India, Razorpay is usually a better first pick. For products in Africa, Paystack or Flutterwave. For products with heavy compliance or enterprise-scale volume, Adyen or Worldpay. The default answer depends on where your customers pay from; the wrong provider does not become right just because it has the best developer docs. Should you use the provider's built-in billing or bring your own?If your billing fits inside the provider's built-in product (Stripe Billing, Razorpay's subscription product, Paddle's merchant-of-record billing), use the built-in one. Building your own billing engine on top of a raw gateway is real work; nobody should do it just to feel in control. If your billing needs (usage-based, credit-based, hybrid, unusual proration, promotional credits, approval workflows) genuinely exceed what the provider offers, then a dedicated billing product like Chargebee, Recurly, or Metronome on top of the gateway is usually the right middle path before you consider a custom build. How do you handle payments across multiple currencies?Most modern gateways handle multi-currency acceptance cleanly. The harder questions are which currency you settle in, whether you present prices in the customer's local currency (localized pricing) or a single reference currency, how currency conversion fees affect your margins, and whether you need to hold balances in more than one currency to reduce conversion. These are business decisions, not technical ones. Pick a settlement approach that matches how you actually run the business, then wire the gateway to match, not the other way around. What is the difference between Stripe Connect, Razorpay Route, and Adyen for Platforms?All three are the same category of product: a way to accept one payment from a buyer and split it across multiple sellers or partners. They differ in the regions they cover well, the ease of onboarding your sellers, the compliance surface they take on for you, and the fee model. Stripe Connect is the global default. Razorpay Route fits marketplaces where the sellers are primarily in India. Adyen for Platforms is stronger for larger enterprise marketplaces with complex compliance needs. Pick the one whose region coverage and seller-onboarding experience matches your marketplace, not the one your team already has an account with. How do you handle webhooks reliably?Every payment provider sends webhooks (a callback fired when something happens, like a card charge succeeding or a subscription pausing). Treat every webhook as unreliable: it can arrive twice, arrive out of order, or not arrive at all. Design the receiver to be idempotent (the same event processed twice does not double-book a payment), store the event, and reconcile against the provider periodically for anything the webhook stream missed. Teams that trust webhooks as the sole source of truth are the ones who discover, months in, that a small percentage of payments were never recorded. Do you need to be PCI compliant?If your product never touches raw card numbers (because the customer types the card into the provider's hosted form or a provider-supplied embeddable widget), your compliance surface is small and mostly handled by the provider. The moment your product touches raw card numbers, PCI compliance becomes your problem, and it is real work. The right default for almost every buyer is: keep raw card numbers out of your product, let the provider hold them, and stay in the smallest possible compliance tier. The savings on compliance work usually outweigh any friction the provider's checkout adds. Can Entexis design and build the right payment setup for your product?Yes. Entexis designs and builds payment layers for custom software products where the payment side has to fit the product model rather than the other way around. That work starts with the sorting conversation (which bucket is your product in, which provider fits, is a hosted billing product enough or do you need something on top), then moves into the design choices covered above (payment abstraction, provider adapters, reconciliation store, refund and subscription edge cases from day one), and delivers a payment layer your team can run without a rebuild the next time the provider or the product changes. Reach out with your product model, the regions your customers pay from, and any billing complexity that does not fit a standard subscription, and we can walk through what the right setup looks like for your specific product. For the API design side of the same conversation (payment providers are APIs, and the design choices that make APIs pleasant apply here too), see: [How to Build an API That Other Teams Actually Want to Use](/insights/how-to-build-an-api-that-other-teams-actually-want-to-use). For a similar bucket-based decision framework applied to the data-collection side, see: [Web Scraping vs API vs Paid Data Feed](/insights/web-scraping-vs-api-vs-paid-data-feed-how-to-pick-the-right-one-for-your-product). For the consumer-mix shift that is making the payment layer more visible to AI agents and partner systems too, see: [Why APIs Are Becoming More Valuable Than User Interfaces](/insights/why-apis-are-becoming-more-valuable-than-uis). So where does that leave you? Almost every "we need a payment gateway" conversation is really 3 conversations wearing one label: what is your product's payment shape, which provider fits that shape, and how do you build the layer around the provider so a future change is a swap and not a rebuild. Get the shape right first, pick the provider that fits, and put the abstraction layer in from day one. Teams that do this find that when the payment world moves under them (and it will move), they move with it without the rewrite. Teams that do not find out later, usually from a customer whose card just failed for the fourth time, that "payment" was written into every corner of the product and the fix is bigger than they thought. > **Want a Payment Setup That Fits Your Product Instead of the Other Way Around?:** At Entexis, we design and build payment layers for products where the payment side is central to how the business runs. We start with the sorting conversation to make sure you are in the right bucket, review your regions and revenue model against the provider landscape, design the abstraction plus adapter plus reconciliation layers, wire the refund and subscription edge cases from day one, and hand you a payment layer that behaves the way the rest of your product does. Your customers pay cleanly, your team stops firefighting refund tickets, and your payment layer becomes a piece you rely on instead of a piece you fear touching. Start the conversation with Entexis.