Manage multiple payment gateways
Manage multiple configured payment gateways through Bonza Payments while keeping customer context, payment activity and the wider Salesforce payment lifecycle connected.
Powered by the Salesforce-native Bonza Payments suiteIllustrative two-layer architecture. Above the gateway layer sits the payment operation: customer, invoice, one-time payment, recurring payment, refund and customer payment experience. Beneath it, Bonza Payments acts as the Salesforce-native payment management layer. Below that are the configured payment gateways: Stripe set as the default, with Razorpay and PayU active and a further gateway configured. Alongside, a new payment for Acme Customer of $2,500 as a one-time payment shows Stripe selected as the default gateway, with Razorpay and PayU available as alternative options a person can choose. A payment activity table then shows payments from different customers processed through different gateways, all read together.
Definition
Managing multiple payment gateways means operating more than one payment provider without treating each gateway as a completely separate payment process.
Bonza Payments provides a Salesforce-native payment-management layer where supported gateways can be configured, a default gateway can be established and another configured gateway can be selected where appropriate.
The selected gateway handles the relevant underlying payment processing, while Bonza keeps the wider customer and payment context connected to Salesforce.
The real problem
Connecting a provider is rarely the hard part. What follows it is.
Three steps, one path, one place to look. Then the business adds another provider — and the path stops being a path.
None of those are integration questions. Every one of them is an operating question — which is why a second gateway so often arrives as a technical success and a process problem.
Two views of the same setup
Two connections, both working. On an architecture diagram this is a finished piece of work.
Nothing here is wrong. It just doesn't describe how anyone works.
A multi-gateway architecture is not mature because several APIs are connected. It is mature when the payment operation stays understandable as providers change.
The operating model
Three layers, three different jobs. This is the central architectural idea of the page.
The gateway handles the relevant payment processing. Bonza manages the broader Salesforce-connected payment operation. Salesforce remains the business and customer context. Adding a fourth provider changes layer three — it should not require rebuilding layers one and two.
Before vs managed
The providers stay different either way. What changes is how many payment operations the business has to run alongside them.
Each gateway is treated as its own payment product, so the same four steps get rebuilt once per provider — and finance learns three of everything.
Nothing here is broken. It simply multiplies: the fourth provider adds a fourth stack of the same steps, not a fourth step.
Gateway-centric model. Gateway A has its own portal, payment process, refund process and reporting. Gateway B has its own portal, payment process, refund process and reporting. Gateway C adds another portal and another set of processes and reports. Each provider added repeats the whole workflow rather than extending an existing one.
Salesforce stays the business context, Bonza stays the payment operation, and the configured gateway is the processing layer inside it.
A fourth provider becomes a fourth option in one layer — the workflow above it is the one that already exists.
Bonza model. Salesforce holds the business context. Bonza Payments is the payment operation. Within it, a default or explicitly selected configured gateway does the processing, chosen from Gateway A, Gateway B or Gateway C. The resulting payment activity lands in the customer and finance context. The selection is configured and chosen, not routed automatically.
The gateway swap
One payment, three configured providers. Choose which one processes it and watch what changes — and, more importantly, what doesn't.
A person makes this selection inside the supported Bonza payment workflow. Bonza does not choose the provider, and nothing here is routed automatically.
Capabilities shown as "varies" are deliberately not filled in. Recurring support, refund behaviour, payment methods, markets and technical requirements depend on the specific provider and your configuration — and no page should tell you otherwise.
Different processors. Consistent payment context. That is the whole argument for putting a payment-management layer above the gateway layer rather than letting whichever portal processed the transaction become the place your team works.
Another configured gateway can be selected where appropriate in the supported workflow — by a person, for a reason they hold. If a vendor tells you their default gateway is also an optimiser, that is a different product making a much bigger claim.
How it works in practice
A default gives the payment workflow a normal starting point, so multi-gateway flexibility doesn't create an unnecessary decision on every transaction.
Where supported, a user can select a different configured gateway rather than redesigning the payment process around that provider. The selection is explicit, never inferred.
The value isn't that another gateway exists. It's that users stay inside the wider Bonza payment workflow — which stops the gateway portal becoming the primary operating interface.
Where the supported payment experience exposes more than one configured option, customers select from the choices made available to them — inside the same payment journey.
Individual payment scenarios may need a different provider without creating a different payment-management process around it.
Recurring capabilities can vary by gateway and implementation. Multi-gateway does not mean interchangeable gateways, and this page will not pretend otherwise.
Refund behaviour can vary by gateway. The operational requirement is to preserve the link between the original payment, the gateway that processed it, the refund activity and the customer history.
Finance should not need to open three gateway portals to understand the payment operation. This is operational visibility — it is not settlement reconciliation.
An honest matrix
Every cell below says "varies" deliberately. Publishing a provider-by-provider comparison would mean asserting things that depend on your contract, your region and your configuration.
A mature multi-gateway strategy does not pretend gateways are identical. The payment-management layer should respect provider-specific capabilities while giving the business a more consistent operational model above them.
Why more than one
Different parts of the organisation may already use different payment providers.
Provider capabilities may vary by market and configuration.
Payment requirements can change as the business enters new markets or supports new scenarios.
Existing operating units may already have provider relationships.
Different payment scenarios may require different configured payment options.
The goal is not to use multiple gateways because you can. The value is having an architecture that doesn't break when more than one provider becomes necessary.
Above the gateway layer
Payments from every configured gateway feed the same customer payment activity, and the receivables position is read above all of them.
Forecasting here is about expected customer payment activity, connected to the wider configured payment setup rather than driven by it.
Relevant patterns and signals surface with the customer and payment context attached, for a person to review.
It does not choose the best gateway, route transactions, optimise fees, predict gateway success or switch providers.
Explore AI Payment InsightsGateway management
Status and default. Nothing more is shown, because nothing more is claimed.
Illustrative gateway management workspace. Stripe is active and set as the default gateway. Razorpay is active and not the default. PayU is active and not the default. Each has a manage action, and a further payment gateway can be added.
No uptime score, authorisation score, routing weight, fee score, priority percentage, settlement health, SLA monitoring or success-rate analytics — none of those are claimed capabilities.
Customer experience
Behind the scenes there may be three providers. In front of the customer there should be one clear payment journey.
Where the implementation shows payment options rather than provider brand names, that is what the customer sees. Not every configured gateway is exposed to every customer.
How it goes wrong
Users learn several processes instead of one, and the process they use depends on which provider happened to handle the payment.
Recurring, refund and payment-method behaviour can differ. Plans built on the assumption they don't tend to fail at exactly the wrong moment.
The portal knows the transaction but not the customer. Work drifts into it, and the Salesforce context fragments behind.
With no default, every payment becomes another decision — and decisions made differently by different people stop being a process.
The operating model, complete
Three of them are usually in place by the time a second provider is live. The fourth is the one that decides whether the setup is genuinely managed.
Who owes what, and why. This belongs to Salesforce and does not change when a provider does.
Where the payment is initiated, tracked through its lifecycle and kept attached to the record it belongs to.
A configured default, with explicit selection of another configured gateway where the scenario calls for it. This is the only layer another provider actually changes.
Payment activity read together rather than provider by provider — which is the layer a gateway portal cannot supply, because each portal only ever sees its own traffic.
Most often the missing layer
The four layers of a managed multi-gateway setup, in order. Layer one, business context: the customer, the invoice and the payment obligation, held in Salesforce. Layer two, payment management: Bonza Payments, where the payment is initiated and tracked through its lifecycle with its context attached. Layer three, gateway choice: the configured gateways, the default gateway and any explicitly selected gateway — the only layer that changes when a provider is added. Layer four, operational visibility: payment history, receivables, customer context and the Command Center, read together rather than provider by provider. Layer four is the one most often missing, because a gateway portal can only report on its own traffic.
Maturity
No score, and no suggestion that every business needs multiple gateways.
Everything at level 4 operates above the gateway layer. That is what makes it a maturity model rather than a list of integrations.
An honest caveat
Adding a second provider to a setup that doesn't need one adds operational cost for no operational return.
The point of a payment-management layer is that this transition doesn't require rebuilding how you work.
Use cases
Business outcomes
Work with multiple configured payment providers.
Keep gateway choice inside the wider Bonza payment workflow.
Reduce the need for each gateway to create a separate operational model.
Keep relevant gateway and payment activity tied to the Salesforce customer relationship.
See relevant payment activity across the wider payment operation.
Where supported, keep relevant payment choices inside the same customer payment experience.
Keep refunds connected with the gateway and the original payment.
Accommodate additional configured providers as requirements evolve.
These are operational outcomes. No claim is made about lower fees, higher authorization rates, higher payment success, better uptime, reduced failures, DSO, revenue, productivity or ROI.
Why Bonza
Keep customer and payment context inside the Salesforce environment your teams already work in.
Support more than one payment provider within the same Bonza payment environment.
Create a normal starting provider, so flexibility doesn't become a decision on every transaction.
Use another configured gateway where the supported payment workflow requires it — chosen by a person.
Keep relevant customer-facing payment options part of the wider payment journey.
Connect gateway activity with payments, recurring activity, receivables, refunds, credits, forecasting and operational visibility.
FAQ
It allows a business to use more than one configured payment gateway without treating each provider as a separate payment operation. The providers still process transactions; a payment-management layer above them keeps the customer context, payment activity and lifecycle connected.
Common reasons include different business units with existing provider relationships, payment methods that vary by market, expansion into new regions, acquisitions, and customer payment scenarios that need different configured options. It is usually a business requirement rather than a technical preference.
Yes. Supported gateways can be configured, a default gateway can be established, and another configured gateway can be selected where the supported workflow allows it. Payment activity from all of them stays connected to the Salesforce customer context.
Yes. A default gives the payment workflow a normal starting point so multi-gateway flexibility doesn't create an unnecessary decision on every transaction. A default is a configured starting selection — not a routing engine, an optimiser or a recommendation.
Where supported, yes — a person can select a different configured gateway within the Bonza payment workflow rather than redesigning the process around that provider. The selection is always explicit.
No. There is no smart routing, dynamic routing, least-cost routing, authorization-rate routing, geographic routing, currency routing, load balancing or automatic gateway optimisation. The model is configure, default, select, process, track.
No. Automatic failover, automatic cascading, gateway health routing and automatic retry through another gateway are not claimed capabilities. If a payment needs to be attempted through a different provider, that is a decision a person makes.
Recurring capabilities can vary by gateway and implementation. Multi-gateway does not mean interchangeable gateways: a recurring arrangement established with one provider should not be assumed to move freely to another. [Confirm recurring support per configured gateway before launch.]
No. Token portability, credential portability and automatic movement of stored cards between providers are not claimed. Stored payment credentials belong to the provider that holds them.
A refund follows the relevant refund process for the gateway behind the original payment, and refund behaviour can differ between providers. What Bonza keeps consistent is the connection between the original payment, the gateway that processed it, the refund activity and the customer payment history.
Yes. Payment activity processed through different configured gateways can be read together in the Payment Command Center alongside collected, outstanding, due, overdue and upcoming activity. This is operational visibility, not settlement or bank reconciliation.
No. Cross-gateway settlement reconciliation, bank reconciliation and gateway fee optimisation are not claimed capabilities. Those remain with your providers and your finance platform.
No. Bonza provides the Salesforce-native payment-management layer, while configured gateways perform the relevant payment-processing functions. Bonza is not a gateway, an acquirer or a payment processor.
No, and no page should imply otherwise. Payment method support, recurring support, refund behaviour, markets and currencies, technical requirements and merchant configuration can all vary by provider and by how you have configured them.
No. Those providers are named as examples of gateways commonly discussed in this context. Naming them does not imply partnership, endorsement or certification in either direction.
See how Bonza Payments helps you manage multiple configured payment gateways while keeping customer context, payment activity and the wider Salesforce payment lifecycle connected.