Where did this value come from?
The payment event that created the credit stays attached to it, so the balance has an origin rather than an assumption.
Customer credit management
Store and manage customer credits within Bonza Payments so available value stays connected to the Salesforce customer and can be used in a future payment journey.
Part of the Salesforce-native Bonza Payments suiteInterface shown is an illustrative representation of Bonza Payments inside Salesforce. Amounts, references and dates are sample values. Credit is a balance recorded and managed within Bonza — Bonza is not a wallet and does not hold customer funds.
Plain definition
Customer credit management is the process of recording, tracking and using monetary value retained for a customer for future payment activity.
With Bonza Payments, customer credit can stay connected to the Salesforce customer and the wider payment lifecycle instead of being tracked as an isolated value outside the payment operation. Where the configured Bonza process allows value from a refund to be retained as customer credit, that available credit can subsequently be used toward a future payment.
Bonza Payments provides customer credit management for businesses using Salesforce: credit is recorded against the customer, maintained as part of the payment relationship, and used toward future payment activity where the configured payment process supports it.
Credit management means different things in financial software. Here it means one thing only: customer payment credit — value held for a customer that can go toward a future payment.
The real problem
A customer has credit. Weeks later, finance and customer-facing teams still need to answer all of this:
WITHOUT CONNECTED CREDIT MANAGEMENT, TEAMS FALL BACK ON
The deeper problem isn't “can we create a credit?” It's “can we understand the entire lifecycle of that customer value?”
How to think about it
A mature credit-management process can answer three questions at any point in that life:
The payment event that created the credit stays attached to it, so the balance has an origin rather than an assumption.
The customer's available credit is readable now, without adding up notes or asking whoever handled the refund.
Credit use is recorded against the payment it went toward, so the position after the payment is as clear as the position before it.
The credit lifecycle
Where only part of the available credit is used, the remaining value stays available for a later payment and the lifecycle begins again at step 02. [Confirm partial credit application and running-balance behaviour before launch.]
Core capability
Where the established Bonza workflow generates customer credit — for example, relevant refund value retained as credit instead of being returned — that value is recorded against the customer it belongs to.
The customer's available credit is visible in the payment operation alongside the rest of their activity.
Relevant credit events are readable over time — created, available, used — so the balance is explained rather than asserted.
Available credit connects to the customer's next relevant payment journey rather than sitting outside it, according to the supported workflow.
After credit is used, the customer's credit and payment position reflects it — so the next person to look knows where things stand.
Customer credit profile
| Date | Event | Reference | Amount | Balance |
|---|---|---|---|---|
| 12 Jan | Credit created | REF-104 | +$500 | $500 |
| 18 Feb | Credit created | REF-131 | +$250 | $750 |
| 05 Mar | Credit applied | PAY-222 | −$300 | $450 |
Who owns the value, how much is available, where it came from and what happened to it — in one record. [Confirm which credit statuses and whether running-balance history are supported before launch; simplify this panel if not.]
Credit in a payment
Credit earns its keep at the moment of the next payment. Here the paying party selects it — nothing is applied on its own.
The arithmetic is illustrative. Whether credit is offered to the customer or applied by your team, and how it behaves when only part of the value is needed, follows your configured workflow — Bonza does not apply credit automatically, make it mandatory, or impose priority or split-tender rules of its own. [Confirm the supported credit-application workflow before launch.]
Where credit comes from
The established route into customer credit runs through a refund: when value needs to come back, retaining it as credit is one of the two configured outcomes.
Bonza's refund and credit capabilities are two outcomes of the same moment. A refund returns relevant value through the configured refund process; customer credit keeps relevant value associated with the customer for future payment use. Neither is presented as the better option.
Side by side
The difference between a refund and customer credit is where the value goes next.
Customer context
Customer credit should not exist as an anonymous balance. Read inside the customer's wider payment relationship, $250 of credit is an outcome with a cause and a consequence — not a number someone has to take on trust.
The next payment
Customer credit remains part of the customer's wider Bonza payment context alongside one-time and recurring payment activity. Which payment journeys can draw on available credit depends on your configured setup. [Confirm which payment types support credit application — including recurring — before launch.]
The wider picture
If a customer has available credit, finance teams may want to read that value alongside the rest of the payment relationship.
Illustrative values, shown for payment context and visibility — not formal accounting, and not a claim that available credit automatically reduces accounts receivable. How credit interacts with an outstanding balance follows your configured process.
Explore Receivables →Customer payment experience
Bonza supports customer payment experiences, including Salesforce Experience Cloud payment scenarios. Where available credit is exposed in the configured customer payment experience, the customer sees the value they already hold at the moment they're paying.
Customers cannot transfer, withdraw, gift or cash out credit, manage anyone else's credit, or change how it behaves. Credit is a balance recorded and managed within Bonza against their account. [Confirm which customer-facing credit capabilities are in scope before launch.]
Architecture
Customer credit belongs to the payment-management relationship, not to any one gateway. Gateways process the payments; Bonza keeps the credit position.
Gateways shown are examples. Customer credit is a balance recorded and managed within Bonza Payments against the Salesforce customer — Bonza is not a wallet, a bank, a stored-value issuer or a financial institution, and does not hold customer funds. Relevant payment processing is performed by the configured gateway according to its own capabilities. [Confirm the supported gateway list before launch.]
Payment Command Center
Credit is not a side ledger hidden from the payment operation. It sits with everything else that happened to your customers' payments.
Activity shown is illustrative.
Use cases
Connected suite
What changes
These describe operational visibility. We don't claim increased retention or revenue, lower refund costs, reduced churn, improved cash flow, higher lifetime value, or specific time or ROI savings.
Why Bonza
Customer credit connects with the relevant Salesforce customer and payment relationship, where your teams already work.
Manage the established transition from relevant refund value into customer credit as one continuous process.
Available credit stays ready for the customer's relevant future payment journey rather than expiring into a note somewhere.
Understand available credit and the relevant credit activity that produced it.
Credits connect with payments, refunds, receivables and customer payment activity instead of standing apart from them.
The credit and payment-management layer stays with Bonza while configured gateways handle relevant payment processing.
FAQ
Customer credit management is the process of recording, tracking and using monetary value retained for a customer for future payment activity. It covers where the value came from, how much is available, and what happened when it was used.
Yes. Bonza Payments is Salesforce-native, so customer credit is recorded against the Salesforce customer and managed as part of the payment relationship rather than tracked in a spreadsheet or an external system.
Where the configured Bonza process creates customer credit — for example, when refund value is retained rather than returned — that value is recorded against the customer and stored within the application. It then remains visible as available credit and can be used toward a future payment where the configured payment process supports it.
Yes — that is the established route into customer credit. When a refund is initiated, the relevant value can either be returned through the applicable refund path or retained as customer credit for future use, depending on the configured Bonza process and the customer's situation.
Yes. Available credit can be used in the customer's future payment journey, with the remaining amount handled through the configured payment gateway. Credit is not applied automatically — it is selected as part of the supported workflow.
The customer's available credit is visible against their record in Salesforce, alongside the credit activity behind it, so teams don't have to reconstruct the position from disconnected notes or gateway information.
The difference is where the value goes next. A refund returns relevant value through the configured refund process, so it leaves the payment relationship. Customer credit keeps relevant value associated with the customer in Bonza, available for future payment use. Neither is universally better.
Available credit is surfaced in the relevant payment process so it can be applied to a customer's next payment, with the remaining amount taken through the configured gateway. Which payment journeys support credit application depends on your configured setup — worth confirming against your implementation.
Customer credit remains part of the customer's wider Bonza payment context alongside one-time and recurring payment activity. We don't claim automatic application to recurring schedules — whether credit can be applied to a recurring collection depends on the configured behaviour, so please confirm it for your setup rather than assuming it.
Where available credit is exposed in the configured customer payment experience — including Salesforce Experience Cloud payment scenarios — the customer can see the credit they hold at the point of payment and select it. Customers cannot transfer, withdraw, gift or convert credit, or manage anyone else's.
Customer credit sits in the Bonza payment-management layer rather than inside any one gateway, so the credit position is held against the Salesforce customer regardless of which configured gateway processes a given payment. The gateway handles the relevant payment processing according to its own capabilities.
No. Customer credit is a balance recorded and managed within Bonza Payments against the customer — Bonza is not a wallet, a bank or a stored-value issuer, and does not hold customer money. Relevant payment processing is handled through your configured payment setup.
We don't impose an expiry policy, and this page doesn't claim one. Whether any time limit applies to available credit depends on your configured Bonza setup and your own business terms — confirm it for your implementation.
See how Bonza Payments helps you manage customer credit within Salesforce and keep available value connected from the original payment event through future payment activity.