Building directly around the first gateway
Business logic becomes provider-specific, so the second provider is a fork rather than a setting.
BetterSeparate payment management from payment processing.
For Salesforce teams
Give Salesforce Teams a Payment Platform They Don't Have to Rebuild for Every Use Case.
Use Bonza Payments as a Salesforce-native payment-management layer for one-time payments, recurring payments, receivables, refunds, credits, customer payment experiences and multiple configured gateways — without making every new payment requirement a separate architecture.
Salesforce-native payment management suiteTwo Salesforce payment architectures compared. In the first, capability is built requirement by requirement: Salesforce sits above a custom payment component wired to gateway A, a second custom component wired to gateway B, custom recurring logic, custom refund logic, a custom credit object, a separate Experience Cloud payment flow, spreadsheet reporting and hand-written accounts receivable status logic. Each was a reasonable decision on its own, and the Salesforce team owns every one of them afterwards. In the second, Salesforce sits above a single Bonza Payments layer holding one-time payments, recurring payments, invoices, receivables, refunds, credits, customer experience, Experience Cloud, multiple gateways, forecasting, AI insights and the Payment Command Center, and that layer sits above the configured payment gateways. Configuration and business-specific extension are still work in both. The difference is how often the foundation is rebuilt.
The short answer
What Is Bonza Payments for Salesforce Teams?
A reusable payment-management layer, not another integration to maintain.
Bonza Payments is a Salesforce-native payment-management suite that helps Salesforce teams support customer payment workflows without treating every payment requirement as an isolated integration or custom application. It provides connected capabilities across one-time and recurring payments, invoices, receivables, refunds, customer credits, customer-facing payment experiences, multiple configured gateways, payment forecasting and operational payment visibility.
Configured payment gateways perform the relevant underlying payment-processing functions, while Bonza manages the wider Salesforce payment lifecycle and customer context. Bonza is not a payment gateway, a Salesforce replacement, a general integration platform, an ERP or an accounting system.
The real problem
The First Payment Requirement Looks Small. The Fifth One Becomes an Architecture.
Each request below is reasonable in isolation. None of them arrives labelled "this is a platform decision."
How it arrives
One request at a time
- "Add a payment button."
- "We need recurring payments."
- "We need another gateway."
- "Customers should pay through Experience Cloud."
- "Finance needs refunds."
- "We need customer credits."
- "Can AR see overdue payments?"
- "Can we forecast upcoming payments?"
What it becomes
A payment platform, maintained by the Salesforce team
By the eighth request the team is no longer solving a payment-button requirement. It is maintaining a payment platform — and payment complexity accumulates whether or not anyone decided it should.
- Consistency between payment types
- Maintainability across releases
- Customer context on every payment
- Gateway-specific behaviour
- Payment status and post-payment activity
- Reporting, user experience and support ownership
A payment button is a feature. Payment operations are an architecture.
Where the problem actually sits
Payment Processing Is Only One Layer of the Salesforce Payment Problem.
Integrating a gateway solves the fourth layer below. The other four still have to exist somewhere — and if they are not in a payment-management layer, they are in your org as custom code.
Layer 01
Customer & business context
Layer 02
Payment experience
Layer 03
Payment management
Layer 04
Payment processing
Configured gatewayAuthorisation and captureProvider behaviour
Layer 05
Operations
Integrating a gateway solves one layer. A payment operation needs more than one layer.
The accumulation
Know When a Payment Feature Has Become a Payment Platform Problem.
Step through eight ordinary business requests. On the left is what the Salesforce team ends up owning when each one is built in turn. On the right is the same request mapped onto a payment-management layer that already exists.
"Can Salesforce take this payment?"
1Owned by your teamOne payment button.
Built requirement by requirement
Mapped onto one payment layer
Configuration and business-specific extension are still work in both columns. The claim is not that development disappears — it is that the foundation does not need rebuilding each time a request arrives.
At some point you are no longer building features. You are building a payment platform.
Where effort goes
Custom Development Still Matters. Rebuilding Commodity Payment Foundations Usually Doesn't.
The question is not whether to write code. It is which code is worth owning for the next five years.
Custom-build every payment capability
The Salesforce team owns all of it
- Gateway integration
- Payment UI
- Payment lifecycle logic
- Recurring logic
- Refund and credit logic
- Status tracking
- Customer payment experience
- Reporting and exception handling
- Ongoing maintenance for every item above
Bonza payment-management layer
The Salesforce team focuses on what is theirs
- Business-specific requirements
- Customer and process context
- Salesforce configuration
- Relevant extension
- Integration boundaries
- User adoption
- Governance
- Ongoing platform architecture
This page does not claim "no custom development required." It claims something narrower and more defensible: reduce the need to repeatedly rebuild foundational payment capabilities. Business-specific workflows, integrations and extensions may still require Salesforce architecture and development work.
The architecture model
Put Payment Management Between Salesforce Business Logic and Payment Processing.
Three layers, three owners, one boundary you can defend at architecture review.
Owns customer + business context
Salesforce
CustomerAccountBusiness processInvoice / obligationExperience CloudInternal users
Owns payment management
Bonza Payments
Owns payment processing
Payment providers
Configured gatewaysStripeRazorpayPayUOther supported providers
Salesforce owns the business and customer context. Bonza manages the wider payment lifecycle. Configured gateways perform the relevant underlying payment processing. Provider names appear as examples of configured gateways and imply no partnership, endorsement or certification.
Capability by capability
Eight Requirements That Shouldn't Each Need Their Own Architecture.
Each one below is a request Salesforce teams receive. Each one is a capability rather than a project.
01
Explore one-time & ad hoc payments
Make One-Time Payments a Reusable Salesforce Capability.
The Salesforce team should not need to create an entirely new payment architecture whenever a business process needs a one-time payment.
Salesforce recordWhere the process already lives
Payment action
Bonza payment component or workflow
Configured gatewayRelevant underlying processing
Payment activityBack in Salesforce context
02
Add Recurring Payments Without Building a Subscription Platform From Scratch.
Bonza supports recurring payment management within the wider Salesforce payment lifecycle — the arrangement, the schedule, the payment activity and what is expected next.
Customer
Recurring payment arrangement
Schedule
Payment activity
Next paymentExpected, not guaranteed
Status / attentionA person decides
This is recurring payment management, not full subscription billing. Usage billing, proration, a plan catalogue, subscription upgrades and downgrades and revenue recognition are not claimed capabilities.
Explore recurring payments
03
Support More Than One Gateway Without Hard-Wiring the Process to One Provider.
The architectural value is that gateway choice lives below the payment-management layer. A configured default, with explicit selection of another configured gateway where appropriate.
Salesforce business process
Bonza Payments
Default or selected configured gateway
Gateway AGateway BGateway C
No smart routing, dynamic routing, least-cost routing, automatic failover, cascading or automatic gateway optimisation. Provider capabilities are not interchangeable, and token portability between gateways is not claimed.
Explore multiple payment gateways
04
Explore Experience Cloud payments
Bring Customer Payments Into Experience Cloud Without Creating a Separate Payment World.
For teams already using Experience Cloud, Bonza can connect relevant customer-facing payment activity with the wider Salesforce payment operation rather than standing up a second payment application beside it.
Customer
Salesforce Experience CloudThe customer-facing environment
Customer / payment context
Bonza PaymentsThe payment-management layer
Configured gatewayRelevant underlying processing
Payment activity in Salesforce
05
Keep Refunds and Credits in the Same Payment Architecture.
Without a connected payment-management model, refund and credit requirements usually become separate custom workflows — because they arrive after the original build was finished.
Original paymentCollected
Change required
Refund
Customer credit
Payment history
Future payment context
Salesforce customerOne updated position
Customer credit is customer value recorded and managed within Bonza Payments — not a wallet, a cash balance or stored funds.
Explore refunds & credits
06
Give Finance Payment Visibility Without Building Another Reporting Application.
Salesforce teams frequently become responsible for producing the operational payment view after building the transaction flow. That second request is usually larger than the first.
Payment data
Bonza payment context
Finance viewCollected · outstanding · due · overdue · upcoming · attention
The same view serves finance and accounts receivable and revenue operations without becoming a different application for each.
Explore receivables
07
Add Forward Payment Visibility Without Turning Salesforce Into a Treasury Platform.
Bonza provides forward visibility into relevant expected payment activity, built from recurring schedules and other supported upcoming payment inputs.
Today
Upcoming
Recurring
Expected payment activityExpected, not collected
This is payment-operations forecasting. It is not treasury, cash-flow, revenue or bank-balance forecasting, and expected activity is never presented as guaranteed cash.
Explore payment forecasting
08
Add Payment Intelligence Without Creating an Autonomous Finance System.
AI surfaces relevant information for a person to review. Signals may include overdue payment activity, changes in upcoming payment activity, and payment-method expiry context.
Payment data
Signal
AI payment insight
Customer + payment context
User reviewA person decides
AI interprets and prioritises. It does not contact customers, choose collection actions, issue refunds, create credits, change configuration or make financial decisions.
Explore AI payment insights
Before and after
From Payment Integrations to a Payment Architecture.
Before
Capability by capability
Salesforce
Custom gateway A integrationOwned
Custom gateway B integrationOwned
Custom recurring jobOwned
Custom refund flowOwned
Credit spreadsheetOwned
Experience Cloud payment componentOwned
AR reportOwned
Payment dashboardOwned
Eight things to test, document, support and release
After
A reusable payment foundation
SalesforceCustomer and business context
Bonza PaymentsPayment-management layer
Configured gatewaysRelevant underlying processing
One foundation, configured and extended where the business differs
The goal is not to remove Salesforce architecture work. It is to stop rebuilding the same payment foundations.
Where each kind of effort belongs
Use Configuration for the Payment Foundation. Reserve Customization for What Makes the Business Different.
Zone 01 — standard payment capability
Use the suite where established
- Payments
- Recurring
- Refunds and credits
- Receivables
- Gateways
- Customer experience
- Forecasting
Zone 02 — business configuration
Shape it to your org
- Relevant Salesforce process
- Customer context
- Payment selection
- Operational views
- Gateway setup
Zone 03 — business-specific extension
Only where it is genuinely different
- Unique workflow
- Special business logic
- Unique integrations
- Industry-specific processes
Not every business-specific extension is supported without development. Zone 03 is real work, scoped against the actual requirement.
Configure the common. Customize the differentiated.
Four roles, one payment layer
The Same Foundation Looks Different Depending on Which Seat You Sit In.
None of these roles disappears. What changes is how much of the payment foundation each one has to invent first.
Give admins a coherent payment configuration surface.
Illustrative settings view. Provider names appear as configured-gateway examples and imply no partnership or endorsement.
What a custom component really costs
Every Custom Payment Component Creates More Than Development Work.
The build is the part you can estimate. The rest arrives after go-live.
The part that gets estimated
Development
- Design and build
- Gateway integration
- Deployment
The part that does not
Everything after go-live
- Testing responsibility and regression risk
- Gateway-specific behaviour as providers change
- User training and documentation
- Security review
- Support ownership and release management
- Experience Cloud behaviour
- Refund and recurring-payment behaviour
- Finance reporting as requirements move
The real cost of custom payment logic is the lifecycle you have to own after go-live.
What most Salesforce teams get wrong
Five Architecture Mistakes That Make Salesforce Payments Harder to Maintain.
Treating every payment type as a different project
One-time, recurring and invoice payments evolve separately and stop agreeing with each other.
BetterUse one payment-management model across payment types.
Building customer and internal payment experiences separately
Experience Cloud and internal Salesforce users end up operating against different payment logic.
BetterKeep relevant payment journeys connected to the same lifecycle.
Leaving post-payment activity until later
Refunds, credits and receivables arrive after go-live and become bolt-ons by default.
BetterDesign for the full payment lifecycle from the start.
Optimising for the first payment requirement
The architecture works for requirement one and struggles at requirement seven.
BetterDesign for payment capability, not a payment button.
An honest comparison
Choose Where Your Salesforce Team Should Own Complexity.
All three of these are legitimate choices. The question is which complexity you want to own.
Custom build
Maximum control
Advantages
- Maximum control over behaviour
- Can fit highly specific requirements
Trade-offs
- Team owns development and maintenance
- Gateway-specific behaviour
- Testing and support
- Future capability expansion
Direct gateway integration
Closest to the provider
Advantages
- Direct provider relationship
- Good for straightforward processing requirements
Trade-offs
- Business process may become tied to the provider model
- Lifecycle capabilities still need to be built
Bonza payment management
A reusable layer
Advantages
- Reusable Salesforce-native payment-management layer
- Multiple payment lifecycle capabilities
- Configured gateway flexibility
- Connected customer context
Trade-offs
- Implementation must still align to actual business requirements, gateway capabilities and Salesforce architecture
Bonza is not universally the right answer. A single straightforward payment requirement with no lifecycle around it may not need a payment-management layer at all.
Governance
Payment Capability Needs Governance—Not Just Functionality.
A reusable payment suite helps teams make better architecture decisions before creating new custom code — because there is now something to evaluate the request against.
01
Business requirement
A payment need arrives from a business team.
02
Salesforce product owner
The request is received against the platform rather than as a standalone project.
03
Payment capability review
Does the payment-management layer already support this?
YesConfigure and implement within the existing capability.
PartiallyExtend appropriately, scoped to the gap rather than the whole requirement.
NoAssess a custom solution or integration on its merits.
04
Test
Against the actual business requirement and the relevant gateway behaviour.
05
Deploy
Through the org's existing release process.
06
Operate
Owned as platform capability, not as another one-off to remember.
Two architecture boundaries worth getting right
Keep Provider Diversity and Customer Journeys Below One Payment Model.
Multi-gateway architecture
Keep provider diversity below the payment-management layer
The Salesforce application should not need to become three separate payment applications just because the business uses three providers.
Business process
Bonza payment management
Gateway A · Gateway B · Gateway CConfigured, selected — not routed automatically
Provider capabilities are not interchangeable. Payment method support, recurring support and refund behaviour can vary by gateway and configuration.
Explore manage multiple payment gateways
Experience Cloud architecture
Explore Experience Cloud payments
Keep customer-facing payments on the same payment model
Internal and customer-facing payment scenarios should not have to become separate payment platforms maintained by the same team.
Internal Salesforce user
Experience Cloud customer
Bonza PaymentsOne payment model, two audiences
Configured gateway
Payment activity in Salesforce
Operating view
Give business teams an operating view without building every dashboard
The payment-management layer should create operational visibility for business users, not only transaction records for technical teams. Collected, outstanding, due, overdue and upcoming activity, recent payment activity, attention items and the forecast are read from the same model rather than assembled per request.
Explore the Payment Command Center
How the Salesforce team's role changes
From payment feature builder to payment platform owner
BeforeDesign integration → build UI → build status logic → build reporting → support production → repeat for the next requirement
With BonzaMap requirement to capability → configure or extend → connect business process → test → operate and govern
Less rebuilding. More platform ownership. The work does not vanish — it moves to the part that is actually specific to your business.
Use cases
Where Salesforce Teams Benefit From a Reusable Payment Layer.
A new payment requirement
Situation
A business team asks Salesforce to accept a payment.
Problem
The team risks building another isolated integration.
Bonza
Use the payment-management layer that already exists.
Outcome
A more consistent payment architecture.
A second payment gateway
Situation
The organization needs another provider.
Problem
Current payment logic is tightly coupled to the first gateway.
Bonza
Manage multiple configured gateways below the wider payment layer.
Outcome
Provider flexibility without rebuilding the payment model.
Experience Cloud payments
Situation
Customers need to pay through Salesforce Experience Cloud.
Problem
The team risks building a separate external payment application.
Bonza
Connect relevant customer payment journeys with the Salesforce payment lifecycle.
Outcome
A more coherent customer and internal architecture.
A recurring payment requirement
Situation
The business adds repeating customer payments.
Problem
The original one-time payment architecture was not designed for it.
Bonza
Add recurring payment management within the broader suite.
Outcome
Less architectural fragmentation.
Finance needs receivables visibility
Situation
Payments exist but finance needs due, overdue and outstanding visibility.
Problem
The Salesforce team is asked to build reporting around raw payment records.
Bonza
Use connected receivables and operational payment capabilities.
Outcome
A more complete finance and payment model.
Refunds and customer credit
Situation
Post-payment requirements emerge later.
Problem
The original implementation only handled collection.
Bonza
Keep refunds and credits inside the broader payment lifecycle.
Outcome
Fewer bolt-on payment processes.
Maturity
How Mature Is Your Salesforce Payment Architecture?
A description of how payment architecture tends to evolve, not a score. Plenty of organizations are right to stay where they are.
Level 01
Transaction
- One payment requirement
- Direct gateway integration
- Limited lifecycle scope
Level 02
Custom payment application
- Multiple custom payment components
- Recurring logic
- Refund logic
- Reporting
- Growing maintenance responsibility
Level 03
Payment platform
- Reusable payment-management layer
- Multiple payment types
- Customer context
- Configured gateways
- Connected lifecycle
Level 04
Operated payment capability
- Receivables
- Forecasting
- Payment method expiry visibility
- AI payment insights
- Payment Command Center
- Governed expansion
No organization has to follow this path, and none of these levels is a verdict on a team.
Outcomes
What a Reusable Payment Layer Actually Gives a Salesforce Team.
Less duplicated payment architecture
Reduce repeated creation of similar payment functionality across requirements.
A more consistent payment model
Keep different payment use cases connected to the same broader payment-management approach.
Clearer provider boundaries
Separate Salesforce business context, Bonza payment management and gateway processing.
More maintainable payment operations
Reduce the number of disconnected payment workflows the team needs to understand.
Better customer and business context
Keep payment activity connected with the Salesforce records it belongs to.
Easier capability expansion
Add relevant payment capabilities within the suite rather than creating a new foundation per use case.
Connected business visibility
Support finance, RevOps and customer-facing teams through the same payment lifecycle.
A platform to evaluate against
Assess each new payment request against an existing capability instead of commissioning a separate solution.
What is not claimed
No specific development savings, implementation-speed improvement, headcount reduction, zero maintenance, cost saving or ROI figure appears on this page.
Why Bonza Payments
A Salesforce-Native Payment Layer Built for More Than the First Payment Requirement.
Salesforce-native
Keep payment management close to the customer and business context already managed in Salesforce.
Complete payment lifecycle
Support one-time payments, recurring payments, receivables, refunds, credits and future payment visibility.
Multi-gateway flexibility
Work with multiple configured payment providers without making each one a separate Salesforce payment application.
Customer + internal experiences
Support relevant internal and customer-facing payment workflows, including Experience Cloud scenarios.
Finance + operations visibility
Connect payment activity with receivables, forecasting and the Payment Command Center.
Payment intelligence
Use payment method expiry and AI payment insights as operational context without turning Salesforce into an autonomous finance platform.
Connected suite
One Payment Layer. Many Salesforce Use Cases.
The same payment foundation can support multiple business teams without becoming a different payment application for each one.
Stop treating every payment requirement as a new Salesforce project.
Questions
Salesforce-Native Payments, Answered.
What is a Salesforce-native payment management platform?
It is a payment-management layer that runs inside Salesforce rather than beside it, so customer payment activity stays associated with the Salesforce records it belongs to. It manages the wider payment lifecycle — initiation, recurring arrangements, status, refunds, credits, receivables and forward visibility — while configured payment gateways perform the relevant underlying payment processing.
How can Salesforce teams add payments without building everything from scratch?
By separating the payment foundation from the business-specific work. Payment initiation, recurring payment management, refund and credit context, gateway configuration and operational payment visibility are common to most implementations. Bonza provides those as connected capability, so the team's effort goes to the Salesforce process, the customer context and the requirements that are genuinely particular to the business.
Does Bonza eliminate the need for Salesforce developers?
No. Bonza can reduce the need to repeatedly build foundational payment capabilities, but business-specific workflows, integrations, unique user experiences, data transformation and extensions may still require Salesforce architecture and development work. This page makes no claim of zero code, zero development or zero maintenance.
Does Bonza replace payment gateways?
No. Configured gateways perform the relevant payment-processing functions. Bonza manages the wider Salesforce payment lifecycle and customer context around those transactions. Bonza is not a payment gateway and does not process payments itself.
Does Bonza replace MuleSoft?
No. Bonza is a payment-management suite, not a general integration platform. It does not position itself as an integration layer for arbitrary systems, and integration requirements outside customer payment management remain outside its scope.
Does Bonza replace Salesforce Revenue Cloud?
No. Bonza is focused on payment management rather than the full revenue lifecycle functionality associated with Salesforce revenue products. It is also not a CPQ, subscription management or revenue recognition system.
Does Bonza replace an ERP or accounting system?
No. Bonza is positioned around Salesforce-native payment management and operational customer payment visibility rather than general ledger, accounting or ERP replacement. It does not perform journal entries, tax accounting, revenue recognition, financial statements, the accounting close, or bank and settlement reconciliation.
Can Bonza support multiple payment gateways, and can I set a default?
Yes. Bonza supports multiple configured gateways, including a configured default and explicit selection of another configured gateway where a scenario calls for it. There is no smart routing, dynamic routing, least-cost routing, automatic failover, cascading or automatic gateway optimisation, and token portability between gateways is not a claimed capability. Provider capabilities are not interchangeable.
Can Bonza work with Salesforce Experience Cloud?
Yes. Where Experience Cloud provides the customer-facing Salesforce environment, Bonza can provide the payment-management layer behind relevant customer payment journeys, with a configured gateway handling the underlying processing. The point architecturally is that internal and customer-facing payments do not become two payment platforms.
Can Bonza manage recurring payments?
Yes, as recurring payment management within the wider payment lifecycle: the arrangement, the schedule, payment activity and what is expected next. This is not full subscription billing — usage billing, proration, a plan catalogue, subscription upgrades and downgrades and revenue recognition are not claimed capabilities.
Can Bonza support refunds and customer credits?
Yes. Refunds and customer credits stay connected to the original payment and the Salesforce customer rather than becoming separate workflows. Customer credit is customer value recorded and managed within Bonza Payments — not a wallet, a cash balance, stored funds or a bank account.
How extensible is Bonza Payments?
Extensibility should be assessed against your actual requirement rather than assumed. The honest framing is that standard payment capability is configured, business configuration shapes it to your org, and genuinely business-specific behaviour may still need development. This page does not claim unlimited custom extensibility, universal API compatibility, automatic migration from an existing custom payment solution, or that there are no Salesforce platform limits to design around.
Salesforce teams
Stop Rebuilding Payments One Requirement at a Time.
See how Bonza Payments gives Salesforce teams a native payment-management layer for one-time and recurring payments, receivables, refunds, credits, customer experiences and multiple configured gateways.