Simplify refunds & credits
Manage refunds and customer credits as part of the same Salesforce-native payment lifecycle, keeping the original payment, customer value and future payment activity connected.
Powered by the Salesforce-native Bonza Payments suiteIllustrative workflow. An original payment of $2,500 from Acme Customer, reference PAY-10482, has a status of Paid. A change is then required covering $500 of that value. From there the value can follow one of two paths: a refund, where $500 is returned through the configured refund process and the refund activity appears in the payment history; or customer credit, where $500 of credit is created within the Bonza payment relationship, becomes available customer credit and can be used toward a relevant future payment where supported. Both paths continue into the same connected customer payment history.
Definition
Simplifying refunds and customer credits means managing post-payment value changes without separating them from the original customer and payment relationship.
Bonza Payments keeps relevant refund and customer-credit activity connected within Salesforce so finance and customer-facing teams can understand what was originally paid, what changed, where the value went and what may happen next.
A refund returns relevant value through the configured refund process. Customer credit keeps relevant value associated with the customer for future payment use where supported.
The real problem
The original payment is usually simple. What follows it rarely is — because the questions multiply the moment value moves.
Then something changes. Perhaps value needs to be returned. Perhaps the relevant business outcome is customer credit.
Illustrative values.
When that information is spread across gateway dashboards, spreadsheets, Salesforce notes and finance records, the payment story becomes harder to understand — and every answer has to be reconstructed by hand.
Refund or credit
Both are legitimate outcomes. They differ in what happens to the value — and the right one depends on the business process and the customer situation, not on a preference built into software.
Decision path. A payment is collected. Something changes. The question is what should happen to the relevant value. One path is a refund, where the value is returned through the configured refund process, producing refund activity that appears in the customer payment history. The other path is customer credit, where the value remains associated with the customer for future payment use, producing available credit that can participate in a future payment where supported.
The relevant value is returned through the applicable configured refund process. What that process involves — and what it supports — depends on the payment gateway behind the original payment.
The relevant value remains associated with the customer within Bonza and can be available toward a future payment where supported — as a credit record inside the payment relationship, not as held funds.
Neither path is presented here as better, cheaper, preferred or recommended. Bonza does not steer the outcome, apply a rule that favours credit, or decide on your behalf. The appropriate path depends on your business process and the customer situation.
What breaks
Four patterns show up repeatedly — and none of them are about whether the refund itself worked.
The refund may well occur. But the wider Salesforce customer and payment context becomes fragmented, so the record of what happened lives somewhere the rest of the business doesn't look.
Teams may know that credit exists without a clear view of why it exists, how much remains, or whether any of it has been used. The knowledge sits with whoever happened to create it.
They represent different value outcomes. Collapsing them into one idea — "we sorted it out" — makes the customer's actual position impossible to state precisely later.
Post-payment changes disappear from the wider customer story, so the history describes a transaction that is no longer an accurate picture of the relationship.
The post-payment value model
Most payment views follow the status. This one follows the value — from the original payment, through the change, down whichever path the business chooses, and back into the same customer history.
The same original payment sits at the top of both paths, and the same customer payment history sits at the bottom of both. What changes in between is where the value went — which is exactly the question finance and customer-facing teams are usually trying to answer after the fact.
How Bonza simplifies it
Post-payment activity is easier to understand when it begins with the transaction that created the customer value — not with a refund record that arrived from somewhere else.
Relevant context may include the customer, the payment reference, the original amount, the payment date, the payment status and the gateway behind it. Finance should be able to answer what are we adjusting? before anyone answers what happens next?
Explore refund managementIllustrative record.
A refund is not a single moment. It is an initiation, a value, a configured process, a status and a permanent change to what the customer's history shows. Bonza helps keep that activity connected to the customer and payment relationship rather than stranded in a gateway dashboard.
What the configured process supports — timing, method behaviour, the shape of the refund itself — depends on the underlying payment provider. Bonza does not override that, and does not promise a refund timeline of its own.
Illustrative. Refund behaviour and timing depend on the configured gateway and financial institution.
The useful question is rarely does this customer have credit? It is where it came from, how much is available, whether any has been used, and what payment activity it connects to.
Credit tracked in a spreadsheet can answer the first question. Credit recorded and managed within the payment relationship can answer the rest.
Explore credit managementIllustrative. Customer credit is a credit record managed within the payment relationship, not held customer funds.
Credit only matters if it participates in what happens next. When a customer returns to pay again, the relevant available credit should be part of the payment context rather than something a team has to remember.
How credit is applied remains a decision within your supported workflow. Bonza does not apply credit automatically, and does not decide how much of it should be used.
Illustrative example. Credit usage follows your supported payment workflow — it is not applied automatically.
Refund and credit questions move between finance and the people talking to the customer. When both sides read from the same connected Salesforce payment context, the answer doesn't change depending on who was asked.
What each team sees still depends on the access and permissions configured in your Salesforce org.
Side by side
Stated neutrally, so the difference is about the value — not about which one a vendor would like you to pick.
Neither path is labelled better, cheaper, recommended or preferred. That belongs to your business rules, not to the software.
The customer value timeline
The same original payment, followed along each of the two value paths. What finance and customer-facing teams usually need is not the refund record on its own — it is the sequence it sits inside.
Illustrative customer value timeline, credit path. On 5 January a payment of $1,000 is collected. On 18 January a change is required affecting $250 of that value. On 20 January the value path is decided and $250 is recorded as customer credit. On 10 March a future payment of $600 arises, $250 of available customer credit is used toward it where supported, and the customer position is updated with $350 remaining to pay and no credit left available. The alternative refund path: on 5 January the same $1,000 payment is collected; on 18 January a refund of $250 is initiated; the relevant refund status is recorded against the configured gateway process; and the customer payment history is updated. All dates and amounts are illustrative sample data, and the dates are positions in a sequence rather than an indication of how long refund processing takes.
Customer payment experience
Bonza's broader customer payment experience can connect available customer credit with relevant future payment journeys where supported.
Illustrative interface. Credit is not withdrawn, transferred, gifted, shared between customers or converted to cash.
Explore customer payment experienceRefunds and gateways
Refund processing capabilities can differ across multiple payment gateways. The connection back to the original payment shouldn't.
Refund capability, refund timing, payment-method behaviour and settlement handling depend on the configured payment provider and the relevant financial institution. Bonza does not make every gateway behave identically, and does not claim that every gateway supports the same refund options.
Explore multiple payment gatewaysReceivables context
Post-payment events are not only administration. They are context — the kind that changes what a customer payment position actually means.
All values illustrative.
A collected figure that does not reconcile with the original invoice at a glance is often explained by a refund earlier in the relationship. An outstanding amount read without the available customer credit beside it tells a different story than the same amount read with it. That is why refund and credit activity belongs alongside receivables rather than in a separate process.
This is operational payment visibility, not accounting treatment. Bonza does not post journal entries, perform bank reconciliation, run revenue recognition or determine how a refund or credit should be treated in your general ledger.
Explore receivables visibilityPayment Command Center
Refunds and customer credits should not disappear into side processes. They remain part of the wider payment operation.
| Customer | Original payment | Refund | Customer credit | Status |
|---|---|---|---|---|
| Acme Customer | PAY-10482 · $2,500 | — | $500 | Credit available |
| Northstar Logistics | PAY-10488 · $8,400 | $1,200 | — | Refunded |
| Harbourview Trust | PAY-10495 · $6,750 | — | $250 used | Applied |
| Global Corp | PAY-10611 · $4,250 | — | — | Paid |
AI Payment Insights
AI Payment Insights can point at post-payment activity worth a look. It does not decide what should happen to the value.
AI does not decide whether to refund, how much to refund, whether to issue customer credit, how much credit to create, or how credit should be applied. Those are business decisions, and they stay with people.
Operating model
Bonza does not make the financial decision. It removes the reconstruction work that surrounds it.
Step four is deliberately marked differently. Bonza does not make that choice automatically, does not apply a rule that prefers credit, and does not approve refunds on your behalf.
Where the line sits
Bonza should reduce fragmented payment administration without removing the controls that matter.
Use cases
Maturity
A way to describe where you are today. There is no score, and not every organisation needs the same path.
Business outcomes
Understand what happened after the original payment changed.
Keep relevant refund activity associated with the original customer and payment context.
Understand relevant available customer credit without relying on disconnected records.
Keep customer value connected from the original payment through the relevant refund or credit path.
Reduce the need to piece together refund and credit history across separate tools.
Keep relevant customer credit visible for future payment use where supported.
Give finance and authorised customer-facing teams a clearer view of the payment story.
Keep refunds and credits connected with payments, receivables and future customer activity.
These are operational outcomes. Bonza does not claim faster refunds, lower refund costs, higher retention, reduced churn, improved cash flow, fewer chargebacks, specific time savings or a specific ROI.
Why Bonza
Keep refund and customer-credit context connected with the Salesforce customer relationship, inside the same org your teams already work in.
Start post-payment activity from the transaction that created the value, rather than from a record that arrived separately.
Support the established value-return and customer-credit workflows within the broader Bonza payment lifecycle, with neither path treated as the default.
Keep relevant customer credit available in the future payment relationship where supported.
Maintain refund and payment visibility across the configured payment environment while respecting gateway-specific capabilities.
Connect refunds and credits with receivables, payment history and the Payment Command Center.
FAQ
They are two different value paths after a payment changes. A refund returns relevant value through the configured refund process, and that value is not retained as Bonza customer credit. Customer credit keeps relevant value associated with the customer within Bonza, where it can be available toward a relevant future payment if your workflow supports that. Neither is inherently better — the appropriate path depends on your business process and the customer situation.
Yes. Bonza Payments is a Salesforce-native payment management suite, so relevant refund activity is managed within Salesforce alongside the original payment and the customer record, rather than only in a gateway dashboard. The underlying refund processing still happens through your configured payment gateway.
Yes — that is the core of this approach. Refund activity is associated with the transaction that created the customer value, so the customer payment history shows the original payment and what happened to it afterwards rather than stopping at "paid".
Where your configured process supports it, the relevant value can follow the customer-credit path instead of the refund path — the value remains associated with the customer in Bonza for future payment use. This is a business decision made by your team, not an automatic conversion applied by Bonza.
Customer credit is recorded and managed within the customer payment relationship in Bonza. It carries the context of where it came from, how much is available and what payment activity it connects to. It is not a wallet, a cash balance, a stored-value account or a gift card, and it is not transferable or shareable between customers.
Available customer credit can be used toward a relevant future payment where your supported payment workflow allows it. Bonza does not apply credit automatically and does not decide how much credit should be used — that stays within your process.
Yes. Relevant available customer credit is visible within the customer payment context rather than living in a spreadsheet or a note, so the question "does this customer have credit, and how much" can be answered from the payment record itself.
Yes. Refund and customer-credit activity appear alongside collected, outstanding, due, overdue and upcoming payment activity, so post-payment events stay part of the wider payment operation instead of becoming a separate process.
Bonza keeps refund and payment context connected across your configured payment environment, with the relevant refund routed to the gateway behind the original payment. What each gateway supports still varies, so Bonza does not make every gateway behave identically.
No. Refund capability, refund options, payment-method behaviour, timing and settlement handling can differ by provider. Any assumption that every configured gateway supports identical refund behaviour should be checked against the specific gateways in your setup.
Refund timing depends on the relevant payment method, the configured payment gateway and the financial institution involved. Bonza does not set or guarantee a refund timeline of its own, and the dates shown anywhere on this page are illustrative rather than an indication of processing duration.
Partial refund capability depends on what is established in your implementation and on what the configured payment gateway supports. [Confirm partial refund support per gateway before launch.]
No. Bonza manages the customer credit record and the wider payment context, while relevant payment processing is handled through the configured payment setup. Customer credit should be understood as a credit record within the payment relationship, not as money held by Bonza.
Customer-initiated refund requests are not claimed here as a standard capability. Whether any customer-facing refund request path exists depends on what is established in your implementation. [Confirm customer self-service refund behaviour before launch.]
No. Bonza does not decide whether to refund, how much to refund, whether customer credit is appropriate, how much credit to create, or how credit should be applied. AI Payment Insights can surface that relevant post-payment activity changed and attach the context behind it, but the decision stays with people.
See how Bonza Payments keeps refunds, customer credits, original payments and future payment activity connected inside Salesforce.