Bonza Payments Product Tour
Take a guided tour of Bonza Payments and see how customer payment activity moves through Salesforce — from collection and payment status to receivables, refunds, credits, recurring payments, forecasting and operational visibility.
Salesforce-native payment management suite. The Bonza Payments Product Tour shows how customer payment activity moves through the wider Salesforce payment lifecycle, including collection, receivables, recurring payments, refunds, customer credits and forward payment visibility.
What am I paying, how much, did it work, what comes next.
Expected, collected, outstanding, due, overdue, refunded, credited, upcoming.
The payment-management lifecycle around the transaction.
Relevant transaction processing, by whichever provider is configured.
Three ways in
All three run on the same page. The thirteen-step tour below is the default route; the three-lens toggle further down covers the other two.
Move through one customer's payment story step by step, with the running position carried beside every step.
Best for business buyers, Finance, Operations and Customer Service.
Start at step oneJump to the capability you are evaluating and read what it does in the lifecycle, then open its page.
Best for product evaluators and Salesforce teams.
Go to the capability navigatorRead the same payment as a stack: who holds the customer, who manages the lifecycle, who processes the transaction.
Best for Salesforce architects and technical buyers.
Open the architecture lensThe tour
Thirteen steps, one customer. The position on the right is carried from step to step and recalculated as things change — including when you choose refund or customer credit at step eight. Every figure is illustrative.
The payment story begins in Salesforce, with a customer and the business context around them. Before any form exists there is a requirement: an amount, a reason and a shape.
Payment management starts before the payment form. Who is paying, what for, how much is relevant, whether this is one-time, recurring or invoice-driven, and what context should follow the transaction afterwards.
Running position, carried from step to step
Reconciliation
$0 + $10,000 = $10,000 — matches the requirement
Customer credit is shown separately and is never added into collected or outstanding. It is recorded value available against future supported payments, not cash held by Bonza.
Every amount, date, customer and status in this tour is illustrative sample data used to explain how the lifecycle behaves. Nothing here is real customer data, a measured Bonza result or a performance claim, and the tour is not connected to a live Salesforce org.
Zoom out
Those thirteen steps were not a feature list. They were one payment story moving across four bands of the suite.
Bonza Payments provides the Salesforce-native payment-management layer while configured payment gateways perform relevant underlying payment processing.
Three lenses
The payment does not change. Who is looking at it does. Bonza sits between the customer view and the business view, and the architecture lens shows why.
Looking at the same $10,000 illustrative payment
Customer view
What they do not need
The customer sees a payment journey. The business sees the payment context behind it.
The operating view
Step thirteen, drawn out. Northstar Services is one row inside this illustrative operation — and the customer record is still underneath every number on it.
Receivables
| Customer | Amount | Status |
|---|---|---|
| Northstar Services | $4,000 | Overdue |
| Customer B | $3,300 | Not yet due |
| Customer C | $1,200 | Due |
| Customer D | $1,000 | Not yet due |
Payment forecast
Expected activity, not collected cash.
Needs attention
And back to where the tour started
The Command Center shows the operation. The customer story still sits underneath it.
What the tour is arguing
It processes the relevant transaction. Everything the business asks afterwards belongs to a layer above it.
Receivables, refunds and customer credits may all remain relevant after the transaction has cleared.
One-time, recurring and invoice-related activity can stay connected rather than becoming separate architectures.
They need different information, and they should still be reading the same payment lifecycle.
What happened, what is open, what may happen next, and what currently deserves attention.
The Product Tour demonstrates the relationship between customer payment activity and internal payment operations rather than showing isolated product features.
Jump to a capability
Each one is a step in the tour above. Here is where it sits and where to read more.
Collect & bill
Steps 1 to 5 of the tour: the requirement, the model, the customer experience, the gateway and the result.
Manage & recover
Steps 6 to 8: what is still open, when it becomes time-sensitive, and what happens when value moves back.
Connect & experience
Steps 3 and 4: how the customer pays, and which configured provider processes it.
Understand & optimise
Steps 10 to 13: the forward signals, what gets surfaced for review, and the operating view.
Or start from the question
Start with the question. The tour shows where it fits in the lifecycle.
How do I collect a customer payment?
How do I know what is still open?
How do I know what is due or overdue?
What happens after a refund?
How does customer credit affect the next payment?
How do multiple gateways fit together?
How can customers pay through Salesforce?
What payment activity is expected next?
What needs attention?
Other journeys
The tour above follows one shape. Four other shapes run through the same lifecycle, and none of them is industry-specific.
Why a tour rather than a feature list
No single decision below is unreasonable. The shape they produce together is the problem.
Added one at a time
Or treated as one model
Bonza can support relevant one-time and recurring payment management, invoices, receivables, due and overdue visibility, refunds, customer credits, multiple configured gateways and Salesforce-connected customer payment experiences.
The point is not that the ten requirements disappear. It is that they can belong to one payment operating model rather than a series of separate payment projects.
What this is for
Stated as capabilities of the model rather than as numbers, because no measured figures exist to quote.
See relevant payment activity in the wider Salesforce context rather than beside it.
Understand collected, outstanding, due and overdue activity as distinct states.
Keep one-time, recurring and post-payment activity connected to one another.
Keep customer-facing activity connected with internal payment operations.
See relevant upcoming payment activity before it arrives.
Support multiple configured gateways through a wider payment-management model.
Surface relevant payment situations for human review.
Reduce the need to manually rebuild context across disconnected payment processes.
Why a journey
Each capability in the suite is individually useful, and each has its own page explaining what it does. But a list of fifteen capabilities does not explain why they belong together, and a buyer reading them one at a time has to assemble the argument themselves.
The tour exists because the value is in the connections. One customer needing to pay $10,000 touched collection, the gateway, payment status, receivables, timing, a post-payment change, recurring continuity, an expiry signal, a forecast, an attention signal and an operating view — without ever becoming a different customer.
Bonza AI Payment Insights support human review by surfacing relevant payment context and attention signals rather than autonomously making financial decisions. Bonza Payment Forecasting provides visibility into relevant expected customer payment activity. Expected payment activity is not guaranteed collection.
The Product Tour shows the connections, not merely the features.
The capabilities this journey passed through
And the roles that read it differently
Keep reading
Product Tour FAQ
One illustrative customer payment followed through thirteen steps: the requirement, the payment model, the customer experience, the configured gateway, the payment result, receivables, due and overdue timing, a refund or customer credit branch, recurring continuity, payment-method expiry, forward visibility, an attention signal, and the operating view it all lands in.
Yes. You step through it with Back, Next or by jumping to any step, you can choose refund or customer credit at step eight and watch the position recalculate, and you can switch between customer, business and architecture lenses. It is a deterministic walkthrough with illustrative data, not a video and not a connection to a live Salesforce org.
No. Northstar Services is a fictional customer and every amount, date and status is an illustrative sample value used to explain how the lifecycle behaves. Nothing on this page is real customer data, a measured result or a performance claim.
No. Bonza Payments provides the Salesforce-native payment-management layer while configured payment gateways perform relevant underlying payment processing. Stripe, Razorpay and PayU are named on this page only as examples of providers a business might configure.
Yes, at step two, where all three payment models are shown feeding into the same payment-management layer. How each is configured differs; where the resulting activity lives afterwards does not.
Yes, at steps six and seven. A collected payment can leave part of the requirement still expected, and the tour shows the same outstanding figure changing operational meaning as the relevant due date passes. Nothing is chased or escalated automatically.
Yes, as a branch you choose at step eight. A refund reduces what has been collected; a customer credit records value available against future supported payments and leaves the collected figure unchanged. Customer credit is not a wallet, stored cash, a bank balance or funds held by Bonza.
Yes, in the multi-gateway scenario and the architecture lens, where configured gateways sit beneath the payment-management layer. Supporting more than one does not imply smart routing, automatic failover, least-cost routing or automatic cross-gateway retry.
Yes, at steps eleven and twelve. Bonza Payment Forecasting provides visibility into relevant expected customer payment activity. Expected payment activity is not guaranteed collection. Bonza AI Payment Insights support human review by surfacing relevant payment context and attention signals rather than autonomously making financial decisions.
Yes, as step thirteen and again as a fuller illustrative mockup. It is the operating view of the payment operation rather than the whole of Bonza Payments, and the customer record from step one is still visible inside it.
No video has been published, so there is none linked here. This page is the walkthrough itself, and it is the same material a video would cover, in a form you can step through at your own pace.
Not from this page, which runs on illustrative data only. Walking through your own payment model — your collection, receivables, recurring activity, refunds, credits, configured gateways and forward visibility — is what a demo conversation is for.
Walk through how your current payment model could map across collection, receivables, recurring activity, refunds, customer credits, configured gateways and forward payment visibility with Bonza Payments.