Business Operations
Know What Happened. What's Open. What's Next. And What Needs Attention.
Give Business Operations a connected Salesforce-native view of customer payment activity — from collections and receivables to recurring payments, refunds, credits, upcoming activity and payment signals that may need attention.
Salesforce-Native Payment Management
One customer
Every band below belongs to the same relationship
Salesforce customer context
Past — what happened
- Payment collected
- Recurring payment completed
- Refund issued
Present — what's open
- Receivable open
- Payment due
- Credit available
Future — what's next
- Next recurring payment
- Upcoming expected payment
- Payment method approaching expiry
Attention — what needs review
- Overdue activity
- Relevant payment signal
- AI insight, then human review
Bonza Payments — the connected payment-management layer beneath the lifecycle
One customer. Multiple payment events. One operational payment story.
What operations is actually dealing with
Payment Operations Do Not End When the Transaction Succeeds.
Twelve connected areas, not twelve separate products.
Business Operations rarely owns one payment type. The work spans collection and what happens afterwards, which is why a view built around a single transaction keeps coming up short.
The operational problem
The Payment Was Successful. Operations Still Has Questions.
Twelve of them, none answered by the transaction result.
What the gateway confirmed
Payment successful
True, useful, and the end of what a transaction result was designed to tell you. It answered one question: did the payment process?
- What was this payment for?
- Is anything still outstanding?
- Is another payment expected?
- Is anything now due?
- Has anything become overdue?
- Was value later refunded?
- Does the customer have credit?
- Which gateway was relevant?
- What does the customer see?
- Is another recurring payment approaching?
- Is the relevant payment method approaching expiry?
- Is there something the team should review?
The transaction answered one question. Business Operations still needs to answer the rest.
How it happens
Payment Operations Rarely Become Fragmented All at Once.
Nine reasonable requests, each one sensible on the day it arrived.
01
“We need to take a payment.”
→
Payment integration
02
“We need recurring payments.”
→
Another payment process
03
“Finance needs to know what is outstanding.”
→
Receivables process
04
“We need to see what is overdue.”
→
Another operational view
05
“We need refunds.”
→
Another workflow
06
“We need customer credits.”
→
Another record and process
07
“We need another gateway.”
→
Another integration
08
“Customers should pay through Salesforce.”
→
Another customer journey
09
“We need to know what's expected next.”
→
Another reporting requirement
“We need one operational view.”
No one intentionally designs a fragmented payment operation. It usually grows one reasonable requirement at a time.
Explore Payment ManagementThe hidden cost
The Hidden Work Is Reconstructing What the Payment Data Means.
Not too many systems. Too much assembly.
A business can hold every relevant payment record and still need a person to put them together before anyone can answer a question. The records exist. The understanding has to be rebuilt each time someone asks.
Without a connected model
- Payment data
- Customer record
- Receivable
- Refund
- Credit
- Recurring schedule
- Gateway context
- Future payment
↓
Manual reconstruction
↓
Operational understanding
versus
With the Bonza model
Connected payment context
↓
Operational understanding
The operational problem is often not missing data. It is the work required to reconstruct the payment story.
Status is not position
A Payment Status Tells You What Happened. Payment Position Tells You Where Things Stand.
Expand one status and see the 7 things it does not say.
Transaction status
Payment collected
Transaction status asks: what happened to this transaction?
Payment position asks: where does this customer currently stand across the relevant payment lifecycle?
A successful payment does not necessarily mean the customer's payment story is complete.
Four operational lenses
Good Payment Operations Explain More Than History.
Select a lens. The question changes; the customer does not.
Past tells operations what happened. Present tells operations where things stand. Future tells operations what may be coming next. Attention helps the team decide where to look.
These four lenses are a fixed structure on this page. The tabs move between written content; nothing here is generated, predicted or labelled as AI.
The operating model
Manage the Payment Lifecycle Instead of Managing Isolated Payment Events.
The same eight things, arranged two different ways.
Before — event by event
- Payment transaction→separate record
- Recurring payment→separate process
- Receivable→separate report
- Refund→separate workflow
- Credit→separate record
- Gateway→separate integration
- Forecast→separate spreadsheet or view
- Operations team→reconstructs the story
After — one lifecycle
- Customer
- Salesforce context
- Bonza payment management
- Connected payment position
- Operational visibility
One customer should not require operations to understand ten unrelated payment stories.
The Bonza model
One Payment-Management Layer Across the Operational Lifecycle.
Four layers, each answering a different operational question.
Collect & Bill
Layer 1 of 4
What payment activity is happening?
Manage & Recover
Layer 2 of 4
Where does the payment position stand now?
Connect & Experience
Layer 3 of 4
How does the payment connect to the customer and the relevant payment route?
Understand & Optimize
Layer 4 of 4
What is expected next and what may need attention?
Every capability answers a different operational question. The value comes from connecting those questions into one payment lifecycle.
Follow one customer
One Customer Can Create an Entire Payment Operations Story.
Ten payment states. Each one says whether every customer reaches it.
The same customer, throughout
1 of 10
This is a conceptual illustration of how different payment events can belong to one wider customer payment lifecycle. It is not a claim that every customer passes through every state — most of the states above are marked as reached by some customers only, and a customer who simply pays once and is settled never enters them at all.
One customer. Multiple payment events. One connected operational story.
Payment Command Center
See the Payment Operation Without Reconstructing It First.
One capability inside the operations story, not the whole of it.
Collected
Sample
Outstanding
Sample
Due
Sample
Overdue
Sample
Upcoming
Sample
Forecast view
- Relevant expected customer payment activity by date
- Recurring activity due to arrive
- Not cash-flow, treasury, revenue or bank-balance forecasting
Payments requiring attention
- Items that moved into overdue
- Positions that changed after a refund or credit
- Surfaced for review, never actioned automatically
Recent payment activity
- Payments, refunds and recorded credits in sequence
- Each attached to the customer it belongs to
- Recurring payment events alongside one-time activity
AI Payment Insights
- Observes, surfaces, explains and prioritises
- Ends at human review
- No autonomous collection, approval or write-off
Payment method expiry visibility
- Expiry read against the next expected payment
- Timing context for a person to act on
- Not failure prediction and not an automatic card updater
Refund and credit context
- Post-payment changes kept with the original payment
- Recorded credit for supported future payment use
- Not stored cash, not a bank balance, not a wallet
The tiles above are labelled interface placeholders, not figures — no amount, count or result is shown, because none has been measured
The Payment Command Center is designed to give teams an operational view across relevant Bonza payment activity. It is one capability within the Business Operations story rather than the whole of it, and it is only useful because the lifecycle underneath it is connected in the first place.
The payment lifecycle creates the context. The Command Center makes the operation easier to see.
Explore the Payment Command CenterAttention
Not Every Payment Needs Attention. Operations Needs to Know Which Ones Might.
Two lanes. Most payment activity stays in the first one.
Normal flow — no one needs to look
- Expected
- Collected
- Recorded
- Next payment, lifecycle continues
Attention flow — worth a person's time
- Expected
- Still open
- Due
- Overdue, or a relevant timing signal
- Attention
- Human review
Not every overdue payment follows the same resolution path, and nothing here implies one. Bonza does not collect debt, does not contact customers on a business's behalf, does not apply late fees and does not record promises to pay. The attention lane ends where a person picks it up.
Good payment operations do not treat every payment the same. They make the exceptions easier to see.
AI in payment operations
Use AI to Surface Payment Signals—not Replace Operational Judgment.
The chain ends with a person, deliberately.
What goes in
- Payment data
- Customer context
- Receivables
- Due and overdue
- Recurring activity
- Payment methods
- Forecasting
- Bonza AI Payment Insights
- Signal
- Context
- Recommendation or priority
- Human review
- Action
Insights are designed to help operations see what matters sooner, by reading payment activity against the customer context it belongs to. The last two steps belong to a person, and the product is built so they cannot be skipped.
Not offered, and not implied
- Autonomous collections
- Automatic customer contact
- Autonomous refunds
- Autonomous credits
- Automatic write-offs
- Automatic gateway selection
- Default prediction
- Payment-failure prediction
- Financial decisions without human review
AI should help operations see what matters. People remain in control of the decision.
Explore AI Payment InsightsForward visibility
Operations Should Understand What's Expected Next—not Only What Already Happened.
A narrow, well-defined kind of forecasting.
Past
Collected activity, refunds and recorded credits — what already happened.
Present
The open, due and overdue position as it stands right now.
Future
Upcoming and recurring expected customer payment activity, visible before the date arrives.
Bonza Payment Forecasting is not
- Treasury forecasting
- Cash-flow forecasting
- Bank-balance forecasting
- Liquidity forecasting
- Revenue forecasting
- FP&A forecasting
It is forward visibility into relevant expected customer payment activity, and nothing wider than that.
Expected payment activity is not the same as guaranteed collection.
See how Payment Forecasting worksPayment method timing
A Payment Method Can Become an Operational Signal Before the Next Payment.
The same two facts in two orders. Only one of them is a signal.
Order A — information only
- Today
- Payment method active
- Next payment expected
- Payment method expiry
The next payment falls before the expiry date. The expiry is still true, and it is still worth recording, but nothing about it needs anyone's attention this week.
Order B — an operational signal
- Today
- Payment method active
- Payment method expiry
- Next payment expected
The expiry falls before the next expected payment. Same two dates, reversed, and now a person may want to do something before that date arrives.
Expiry alone is information. Expiry plus future payment context is an operational signal.
Comparing two dates is not a prediction. Bonza does not claim payment-failure prediction, does not replace cards automatically, operates no card updater and guarantees no prevention of failed payments.
Multiple configured gateways
More Gateway Options Shouldn't Mean More Payment Operations.
The gateway layer sits beneath the payment-management model.
Salesforce
Bonza Payments
Gateway A — for example, Stripe
Gateway B — for example, Razorpay
Gateway C — for example, PayU
Bonza can support multiple configured payment gateways, including a default or another configured gateway where relevant. The business decides which applies; the operating model above it stays the same either way.
That matters to operations more than it looks: without it, every additional provider tends to arrive with its own reporting, its own reconciliation habit and its own way of describing the same payment.
Bonza does not perform smart routing, least-cost routing, AI gateway selection, automatic failover, cross-gateway retries or success-rate optimization, and claims no universal gateway support. Providers are named as examples of configured options only, and no partnership is implied.
One payment management model. Multiple configured gateway options.
Two sides of one payment
The Customer Sees a Payment Journey. Operations Needs to See What Happened Around It.
One payment, two vocabularies.
Customer side
- Payment context
- Payment choice
- Relevant gateway option
- Payment action
Bonza payment lifecycle
Operations side
- Customer context
- Payment activity
- Current position
- Post-payment changes
- Upcoming activity
- Attention
One payment. Two views. One connected story.
See Experience Cloud paymentsCross-functional visibility
Different Teams Ask Different Questions About the Same Payment.
Select a team. Only the questions change.
One payment — unchanged by whoever is asking
The questions change by team. The underlying customer payment story should not.
Operational scenarios
Where Connected Payment Operations Matter
Five situations, each with the problem stated honestly.
01
Understanding the current payment position
Situation
A customer has multiple payment events.
Problem
A successful transaction alone does not explain whether anything remains outstanding.
Bonza model
Connect relevant payment activity, receivables, due and overdue context and customer history.
Outcome
Clearer understanding of where the customer payment relationship currently stands.
02
Recurring payment operations
Situation
Payments repeat over time.
Problem
Operations needs to understand history and what is expected next, not merely whether recurring logic exists.
Bonza model
Recurring payment activity, forecasting, payment-method expiry context and relevant attention signals.
Outcome
Better forward visibility across recurring payment activity.
03
Post-payment changes
Situation
A collected payment later changes.
Problem
Refunds or customer credits can become detached from the original payment context.
Bonza model
Payment, change, refund or credit, updated payment position, future payment context.
Outcome
A clearer post-payment story.
04
Multi-gateway operations
Situation
The organization uses more than one configured gateway.
Problem
Each gateway can otherwise become another independent operational process.
Bonza model
Salesforce, then Bonza, then the relevant configured gateways.
Outcome
Greater gateway flexibility without positioning every gateway as a separate payment-management model.
05
Customer payment experience
Situation
Customers interact through relevant Salesforce customer experiences.
Problem
The customer journey and internal payment context can become disconnected.
Bonza model
Customer experience, the Bonza payment lifecycle and configured gateway processing.
Outcome
A more connected customer-side and operations-side payment story.
Maturity
How Payment Operations Mature
Six stages, each defined by the question it can answer.
Stage 1
Transaction-centric
Did the payment succeed?
Stage 2
History-aware
What payment activity happened?
Stage 3
Position-aware
What remains open, due or overdue?
Stage 4
Lifecycle-aware
How do recurring activity, refunds, credits and customer context connect?
Stage 5
Forward-looking
What payment activity is expected next?
Stage 6
Attention-driven
What deserves review now?
This model is not a score and nothing on this page assesses which stage a visitor is at. Nor does installing software move an organization between stages: the stages describe questions a payment operating model can answer, and the work of getting there belongs to the business.
Payment operations mature when the business can answer more than “did the transaction succeed?”
Common mistakes
What Payment Operations Teams Commonly Get Wrong
Seven patterns, and what to do instead.
01
Designing around the first transaction
Design around the wider customer payment lifecycle.
02
Treating every new payment requirement as a new integration
Consider the payment operating model before adding another silo.
03
Confusing payment status with payment position
Understand what remains open and what happens next.
04
Looking only backward
Connect history with upcoming payment activity.
05
Treating refunds and credits as side processes
Keep post-payment changes connected to the payment story.
06
Designing the operation around one gateway
Keep payment management conceptually above relevant configured gateways.
07
Using AI as a substitute for financial judgment
Use AI to surface context and signals while people make decisions.
A question for your own operation
Can Your Payment Operation Answer These Questions Without Reconstruction?
Nothing here is scored, submitted or counted.
- Who is the customer?
- What payment was expected?
- What actually happened?
- What has been collected?
- What remains outstanding?
- What is due?
- What is overdue?
- Was anything refunded?
- Does relevant customer credit exist?
- Is another payment expected?
- Is relevant payment-method expiry approaching?
- Which configured gateway is relevant?
- What does the customer see?
- What needs attention?
If these questions require multiple people, reports and systems to reconstruct the answer, the problem may be the payment operating model — not the transaction itself.
Why Bonza
Bonza Is Built Around the Payment Lifecycle—not Just the Payment Moment.
Six reasons that matter specifically to operations.
Salesforce-native payment management
Keep relevant payment context connected with Salesforce customer and business context, rather than rebuilding it from an unrelated system each time.
Broader payment lifecycle
Support established areas including one-time payments, recurring payments, receivables, due and overdue activity, refunds, customer credits and future payment visibility.
Multi-gateway flexibility
Work with relevant configured gateway options without making the gateway the entire payment-management model.
Customer and operations connection
Connect relevant customer payment experiences with internal payment context, so both sides describe the same payment.
Forward visibility
Understand relevant upcoming payment activity and payment-method timing before the date arrives rather than after it.
Operational intelligence
Use the Command Center and AI Payment Insights to make relevant payment information easier to interpret and prioritize, with decisions staying with people.
The goal is not more payment data. The goal is a payment story operations can understand.
Where Bonza fits
Three Layers, and What Each One Owns for Operations.
None of the three replaces another.
Context layer
Salesforce
Customer and business context — who this is and what the relationship is.
Payment management layer
Bonza Payments
The payment lifecycle around the transaction — expected, collected, open, due, overdue, changed, upcoming, worth attention.
Processing layer
Configured payment gateway
Relevant transaction processing, performed by the provider the business configured.
And then back up
- Payment activity returns to Bonza plus Salesforce context, which is the part a gateway response on its own cannot give an operations team.
- Salesforce provides the customer and business context.
- Bonza manages the payment lifecycle.
- Configured gateways process relevant payments.
Boundaries
Clear Boundaries Make Better Payment Operations.
An unclear boundary costs more later than a narrow one does now.
Bonza should not be positioned as
A bank
A payment gateway
A merchant acquirer
A general ledger
An ERP
A treasury platform
A debt-collection agency
A digital wallet
A full subscription-billing platform
An accounting system
Bonza does not hold customer money. Recorded customer credit is relevant value tracked within the payment lifecycle for supported future payment use; it is not stored cash and not a wallet. Recurring payment management is not full subscription billing and does not include usage billing, metered billing or proration. Receivable visibility is not general accounting, and no bank or universal settlement reconciliation is claimed.
Bonza does not need to replace every financial system to connect the customer payment lifecycle.
Operational change
What Better Payment Operations Can Make Easier
Qualitative only. No figures, because none have been measured.
- Clearer payment visibility
- Less payment-story reconstruction
- Better understanding of outstanding, due and overdue activity
- More connected recurring payment context
- Clearer refund and credit history
- Better awareness of upcoming payment activity
- Better visibility into relevant payment-method expiry timing
- More connected customer and internal payment context
- More flexible multi-gateway payment operations
- Clearer identification of payment activity that may need attention
None of the above is quantified, and that is deliberate. No productivity gain, DSO reduction, collection-rate improvement, revenue increase, cost reduction, ROI figure, payment-success improvement, churn reduction, retention improvement or forecast-accuracy claim has been measured for Bonza, so none is made here.
Industry relevance
Payment Operations Look Different by Industry. The Core Questions Stay Familiar.
Where the same operating problem shows up.
Financial & Professional Services
Relevant where client relationships may include multiple payment events, receivables, recurring activity or post-payment changes.
Relevant where payer payment activity may occur across multiple stages or payment moments.
Healthcare
Relevant where payment context should remain connected to the relevant customer relationship, without positioning Bonza as medical billing. The Healthcare page has not been published on this site yet, so this entry is marked as not yet published rather than linked.
Relevant where one-time and recurring customer payment activity needs connected operational visibility.
Relevant where repeating payment relationships may need ongoing visibility.
Relevant where customer payment obligations may occur across multiple payment moments.
Relevant where supporter payment activity should remain connected to the relevant relationship, without positioning Bonza as a fundraising platform.
Other Salesforce-Powered Businesses
Relevant where Salesforce already provides the customer and business context and the organization needs a connected payment-management model.
No industry-specific workflow is claimed beyond what is established above.
The better question
The Better Question Is No Longer “Did the Payment Succeed?”
Eight rungs. The first one is where most payment tooling stops.
01
Did it succeed?
02
What was collected?
03
What is still open?
04
What is due?
05
What is overdue?
06
What changed?
07
What happens next?
08
What needs attention?
The transaction is the beginning of operational understanding — not the end of it.
FAQ
Payment Operations, Answered.
Including the questions where the honest answer is a boundary.
What is payment operations management?
Payment operations management is the work of understanding and coordinating customer payment activity across the wider lifecycle, not only processing individual transactions. The relevant questions include what was expected, what was collected, what remains open, what is due or overdue, what changed after payment and what activity is expected next. It is an operating problem rather than a reporting problem: the records usually exist, and the work is assembling them into something a team can act on.
How does Bonza help Business Operations teams?
Bonza Payments connects relevant payment activity with Salesforce customer and business context. Its established capabilities span one-time and recurring payments, receivables, due and overdue activity, refunds, customer credits, configured gateways, forecasting, payment-method expiry visibility, AI Payment Insights and the Payment Command Center. For operations specifically, the point is that those are one connected lifecycle rather than a set of separate processes that have to be cross-referenced.
Is payment operations the same as payment processing?
No. Payment processing focuses on whether a relevant transaction can be processed, and a configured gateway answers that well. Payment operations deals with the wider operational context around customer payments before, during and after that transaction. A gateway response is not designed to tell an operations team what remains open, what changed afterwards or what is expected next.
What is the difference between payment status and payment position?
Payment status describes what happened to a particular payment. Payment position provides wider context about where the customer currently stands — whether relevant amounts remain open, are due or overdue, whether value was later refunded or recorded as credit, and whether future payment activity is expected. A payment can be collected and the customer still be unsettled; the status alone does not say so.
Can Bonza help teams see outstanding, due and overdue payments?
Yes. Receivables and Due & Overdue Payments are established Bonza capabilities designed to provide relevant payment visibility in Salesforce. Keeping the three states distinct is deliberate: outstanding is what is still open, due is what has reached its date, and overdue is what has passed it. Collapsing them into one open figure removes the information that decides whether anyone needs to act today.
Can Business Operations see upcoming payment activity?
Bonza includes Payment Forecasting, which provides forward visibility into relevant upcoming, scheduled or recurring customer payment activity. This is payment-operations forecasting. It is not treasury, cash-flow, bank-balance, liquidity, revenue or FP&A forecasting, and expected payment activity is not the same as guaranteed collection.
How does Bonza handle refunds and customer credits?
Refunds and customer credits are treated as part of the wider payment lifecycle rather than as separate side processes. A refund returns relevant value through the applicable refund process, while recorded customer credit keeps relevant value available for supported future payment use. Customer credit should not be understood as stored cash, a bank balance or a digital wallet, and Bonza does not hold customer money.
Can Bonza support multiple payment gateways?
Yes. Multiple Payment Gateways is an established Bonza capability. Relevant configured gateways can be managed within the Bonza payment model, including a default or another configured gateway where appropriate, with the business deciding what applies. Bonza does not perform smart routing, least-cost routing, AI gateway selection, automatic failover, cross-gateway retries or success-rate optimization, and claims no universal gateway support.
What is the Bonza Payment Command Center?
The Payment Command Center is the operational visibility layer across relevant Bonza payment activity. It is intended to help teams see areas such as collections, receivables, due and overdue activity, recurring payments, refunds, credits, upcoming activity and payment insights in a connected Salesforce-native view. It is one capability within the payment operations story rather than the whole of it, and it is only useful because the lifecycle underneath it is connected first.
How does Bonza use AI in payment operations?
Bonza AI Payment Insights are positioned to help surface and interpret relevant payment signals and indicate where attention may be useful. The model keeps financial decisions under human review rather than positioning AI as an autonomous financial decision-maker. Bonza AI does not collect payments, contact customers, approve refunds, create customer credit, select gateways, write off receivables, predict default or predict payment failure.
Does Bonza chase overdue payments automatically?
No. Bonza surfaces payment activity that may deserve review and stops there. It is not a debt-collection agency, performs no autonomous collections or customer outreach, applies no automatic late fees, runs no automatic dunning and records no promises to pay. Not every overdue payment follows the same resolution path, and deciding what to do about one is a person's job.
Is Bonza an accounting or ERP platform?
No. Bonza is a Salesforce-native payment-management suite. It should not be positioned as a general ledger, an ERP, a treasury platform or a full accounting system, and it does not perform bank reconciliation or universal settlement reconciliation. Receivable visibility inside the payment lifecycle is a different thing from general accounting.
Is Bonza a payment gateway?
No. Bonza provides the payment-management layer around the customer payment lifecycle. Relevant configured gateways perform the underlying transaction processing. Bonza is not a gateway, not a processor, not a bank and not a merchant acquirer, and gateway providers named on this page are examples of configured options only, implying no partnership.
One connected story
See What Your Payment Operation Looks Like When the Whole Story Is Connected.
Explore how Bonza Payments can connect relevant customer payment activity across collection, receivables, recurring payments, refunds, credits, configured gateways and forward payment visibility in Salesforce.
The transaction was one moment. Operations needs the whole story.