- Home
- Industries
- Credits & Refunds
Credits & Refunds
When a Payment Changes, Keep the Value Story Connected.
Manage relevant refunds and customer credits in Salesforce while keeping post-payment activity connected to the original payment, customer context and future payment lifecycle with Bonza Payments.
Part of the Salesforce-native Bonza Payments suiteIllustrative post-payment lifecycle for one sample customer, Demo Customer, whose Salesforce context is connected. The original payment column shows a payment of $1,000.00 with a status of collected through a relevant configured gateway. The change-required column shows an amount of $250.00 and two possible paths, a refund or customer credit, with the choice described as a business decision. The updated-position column shows the refund path recording a refund of $250.00 with updated payment history, or the credit path recording customer credit of $250.00 available for relevant future payment use where supported. The wider payment context strip lists receivables, next payment, payment history and configured gateway. Every figure on this page is illustrative sample data and is not real customer data. Customer credit is recorded and managed within Bonza Payments and is not a wallet, stored cash, a bank balance or escrow, and Bonza does not hold customer funds.
Which path applies is a business decision.
or
Definition
What Are Credits and Refunds in Bonza Payments?
A direct answer for anyone comparing refund, credit and payment-management capabilities.
Bonza Payments supports post-payment management where relevant payment value needs to change after collection, including supported refund and customer-credit scenarios.
A refund returns relevant value through the applicable refund process, while customer credit records value within Bonza Payments for relevant future payment use where supported. Both remain part of the wider Salesforce customer payment lifecycle rather than becoming separate records somewhere else, which is what payment management is for.
Language, precisely
Two Terms That Get Used Interchangeably and Should Not Be.
A refund and customer credit are different. A refund returns relevant value through the applicable refund process, while customer credit records value within Bonza Payments for relevant future payment use where supported.
The wording here is not fussiness. Describing customer credit as a wallet implies a regulated product Bonza is not, and that is a claim worth never making by accident.
Refund
A relevant post-payment process where previously collected value is returned through the applicable configured payment or refund process.
- Refund
- Refund activity
- Relevant refund process
- Updated payment history
- Instant refunds
- Guaranteed refund timing
- Universal refund support
- Automatic refund approval
- Self-service refund initiation
Customer credit
Credit recorded and managed within Bonza Payments that may be relevant to a future supported payment.
- Customer credit
- Available credit
- Credit recorded and managed within Bonza Payments
- Credit available for relevant future payment use
- Wallet
- Digital wallet
- Stored cash
- Stored funds
- Stored-value account
- Bank balance
- Escrow
- Trust account
- Deposit account
- Money held by Bonza
- Cash withdrawal
- Interest
- Transfer between customers
Refund changes where the value goes. Customer credit changes how the value may be used later. Both should remain connected to the original payment story.
The part that gets lost
The Original Payment Is Easy to Find. What Happened After It Often Isn't.
A payment record can say collected, $1,000.00. Once $250.00 of that is refunded or becomes customer credit, these are the questions somebody has to answer.
Why did the payment value change?
What happened to the original payment?
What is the current payment position?
Was value returned?
Was value recorded as customer credit instead?
How much credit remains relevant?
Does the credit relate to a future payment?
Did the receivable position change?
Can Customer Service explain what happened?
Can Finance see the post-payment event at all?
The post-payment problem is not only executing the change. It is preserving the meaning of the payment after the change.
Transaction state ≠ final value state
“Payment Successful” Is a Transaction State—not Always the Final Value State.
A successful payment can still have a post-payment lifecycle. A system that stops at “success” does not explain everything that may happen after collection.
Where most payment records stop.
Through a refund or as customer credit.
The transaction may be complete. The value story may not be.
Signature · follow the value after the payment
Refund or Customer Credit? They Solve Different Post-Payment Needs.
Four reasons a collected payment changes. For each one, both value paths are shown at the same time, from the same original payment to the same customer payment history.
Original payment · unchanged in all four scenarios
This band is written once in the page markup and neither path below can change it. That is the point being made: a post-payment event adds to the record rather than rewriting the payment that created it.
Part of what was paid for was not delivered
The payment collected cleanly. A later business event means some of that value no longer corresponds to something the customer received.
“Should value go back through the relevant payment or refund route?”
The same provider that processed the original payment.
Attached to the payment it came from, not raised as a standalone transaction.
Both figures remain readable on the same record.
Returning the value suits a customer who is not expecting to transact again soon. The refund is the end of this value, and the history says so.
“Should relevant value remain available in the payment relationship for future use?”
A payment-management record against the customer.
Not applied to anything by itself.
Visible to whoever next looks at this relationship.
Retaining the value suits a continuing relationship. Nothing is applied automatically; a person decides whether and when the credit is relevant to a later payment.
The value took a different route. The customer, the original payment and the record a colleague reads six months later did not change. All figures are illustrative sample data.
Scenario 1, part of what was paid for was not delivered, with a change amount of $250.00. Both paths end at one connected customer payment history.
The two paths share no middle step at all — not one label and not one value — which is what makes them genuinely different value paths rather than two names for the same process. Both still terminate in the same record.
The value may take a different path. The context should remain connected.
Original → change → new position
Every Post-Payment Change Should Answer Three Questions.
If a team can answer all three from one record, the post-payment event has been managed rather than merely executed.
Original
What was originally collected?- Customer
- Payment
- Amount
- Gateway context
- Relevant obligation
Change
What happened afterward?- A refund, through the applicable process
- Or customer credit, recorded in Bonza Payments
- Decided by the business, not by the system
New position
What does the relationship look like now?- Updated payment history
- Current customer credit
- Receivables context
- Future relevant payment
Where it goes wrong
Refunds and Credits Become Hard to Manage When They Live Outside the Payment Story.
Nothing in the fragmented version is unreasonable on its own. Together they mean nobody can answer a customer question without assembling it first.
Five places, no single connected story, and the explaining falls to whoever the customer reaches.
One route, and the answer is already on the record.
The cost of fragmentation is the work required to reconstruct what happened to the value.
Refunds
Keep Refund Activity Connected to the Payment That Created It.
Refund management should preserve the relationship between the original payment and the subsequent return of relevant value, so Finance and customer-facing teams can see that the payment changed after collection.
Decided by the business.
Through the applicable configured provider.
Customer credit
Keep Relevant Value Available for a Future Payment Without Turning It Into a Wallet.
Customer credit allows relevant value to remain part of the payment relationship for future supported payment use. The credit is recorded and managed within Bonza Payments.
Illustrative.
Applied by decision, not by a rule this page invents.
The decision
The Post-Payment Question Is Often: Return the Value or Keep It in the Payment Relationship?
Bonza Payments does not automatically decide whether a refund or customer credit should be used. That remains a business decision within the relevant process.
- A relevant value change is required
Should value be returned through the relevant refund process?
Original payment → refund activity → updated history.
Original payment → customer credit → future relevant payment context.
- The same customer payment history underneath both answers
Bonza should support the decision. It should not invent the decision.
Receivables
A Refund Can Change the Customer Payment Position.
Where receivables are relevant, post-payment activity can change how Finance understands the customer payment position. A refund affects Accounts Receivable by changing what the collected figure means, not by posting an entry anywhere.
Explore Receivables Accounts Receivable Due & Overdue Payments
Customer Credit Becomes Most Useful When the Next Payment Knows It Exists.
Where supported, customer credit can remain connected to relevant future payment activity rather than becoming an isolated finance record. Customer credit can be used for a future payment where the implemented flow supports it.
- $200.00 recorded against Demo Customer
- Illustrative
- $1,000.00 expected
- Illustrative
- The $200.00 is visible at the moment it matters
- Applied only where supported
Across payment patterns
A Refund Should Not Break the Recurring Payment History.
Where recurring payments are relevant, refund activity should remain connected to the wider recurring payment relationship instead of interrupting it.
Attached to payment 02, not to the arrangement.
A One-Time Payment Can Still Have a Long Post-Payment Story.
One-time describes the payment frequency. It does not mean the payment has no post-payment lifecycle.
Explore One-Time & Ad Hoc Payments One-Time Payments
Post-Payment Changes Should Still Make Sense Against the Original Obligation.
The original payment obligation, the collected payment and the post-payment value change should remain understandable as one payment story.
The customer's side
The Customer Needs to Understand What Happened After Payment Too.
The customer does not need internal finance complexity. They do need a clear payment story.
- The original payment: $1,000.00, illustrative
- The post-payment change: a $250.00 refund, or $250.00 of customer credit
- The updated relevant payment context
- Request their own refund
- Convert value into credit themselves
- Withdraw credit as cash
None of these is claimed as customer-facing behaviour unless separately established.
Explore Customer Payment Experience Customer Self-Service Payments
Keep Relevant Refund and Credit Context Connected to Salesforce Experience Cloud Journeys.
Where Experience Cloud is already used for relevant customer-facing experiences, Bonza can keep supported payment context connected to that Salesforce environment.
The organisation's own portal. Bonza does not provide it.
Gateways
Keep Refund Context Connected Even When Payments Use Different Configured Gateways.
Configured payment gateways handle relevant underlying payment processing, while Bonza manages the broader Salesforce-native payment context around the original payment and supported post-payment activity.
Configured by the business.
The refund stays associated with the provider that handled the original payment.
Explore Multiple Payment Gateways Manage Multiple Payment Gateways
AI, scoped
Use AI to Surface Relevant Post-Payment Changes for Human Review.
AI Payment Insights read the payment, refund, credit and receivables context that already exists and point a person at what changed. The insight ends at the person.
- Relevant refund activity changed the customer payment position.
- Customer credit is relevant to an upcoming supported payment.
- Post-payment activity changed the wider payment context.
- Approve refunds
- Approve credits
- Decide whether a refund or credit is better
- Change customer credit
- Move value
- Issue refunds autonomously
- Contact customers automatically
- Determine financial entitlement
The signal goes to a person with its context. Any decision after that is theirs.
One operating view
See Post-Payment Activity in the Same Operating View as Payments and Receivables.
Refund and credit figures sit here as contextual panels rather than headline metrics, because the operating question is what changed on which customer, not a post-payment scoreboard.
Illustrative Payment Command Center view of post-payment activity. The KPI strip shows $412,800.00 collected, $250,000.00 outstanding and $118,400.00 upcoming, all illustrative. The recent payment activity table lists three sample customer payments with amount and status. The post-payment activity panel lists three sample entries showing the customer, the original payment, whether a refund or customer credit applied, the relevant amount and the updated context. The needs-attention panel lists a relevant overdue item, a relevant payment method expiry and a relevant AI payment insight, each for human review. The customer payment position strip lists payment history, refund context, credit context and next payment. Refund and customer credit appear as contextual panels rather than formal metrics. Every figure is illustrative sample data and is not real customer data.
| Customer | Payment | Amount | Status |
|---|---|---|---|
| Demo Customer | PAY-6210 | $1,000 | Collected |
| Sample Account | PAY-6218 | $3,400 | Collected |
| Example Client | PAY-6226 | $780 | Collected |
| Customer | Original | Path | Amount | Updated context |
|---|---|---|---|---|
| Demo Customer | PAY-6210 | Refund | $250 | Payment history |
| Sample Account | PAY-6218 | Credit | $400 | Future payment |
| Example Client | PAY-6226 | Refund | $780 | Payment history |
Sample Account · an amount is past its relevant expected date.
Human reviewExample Client · method expires before a relevant upcoming payment.
Internal signal · human reviewRefund activity changed Demo Customer's payment position.
Insight · human reviewAll values illustrative sample data, not real customer data. Refund and customer credit appear as contextual panels rather than formal Command Center metrics. Bonza performs no bank reconciliation, settlement reconciliation, automatic accounting reconciliation or general ledger posting, and holds no customer funds.
Transaction history ≠ value history
Transaction History Tells You What Happened. Value History Tells You What Changed.
Both are accurate. Only one of them answers what the payment is worth to the relationship now.
$1,000.00
“Did the payment go through?”
“What is the payment worth to the customer relationship now?”
The original transaction does not always explain the current payment position.
A Successful Payment Can Still Have a Different Current Position.
Payment status describes the transaction event. Payment position describes the wider customer payment reality.
“What did the transaction do?”
“Where does the relationship stand?”
Cross-industry post-payment patterns
Different Industries. The Same Need to Manage What Happens After Payment.
Each entry is the question that sector actually asks, and what Bonza does not provide there. Post-payment value is exactly where sector-specific assumptions creep in, so each one says no explicitly.
Financial & professional services Client value change
“What happens when previously collected client payment value needs to be returned or retained as relevant customer credit?”
Keep supported post-payment activity connected with the client payment history. See Financial & Professional Services.
- Trust accounting
- Escrow
- Client money accounts
- Regulated fund custody
Education Payer value change
“What happens when a relevant payer payment changes after collection?”
Keep refund or customer-credit context connected to Salesforce. See Education.
- Student accounting
- Tuition adjustment
- Financial aid
- Scholarship logic
Healthcare Customer value change
“How can relevant customer payment value changes remain connected to the wider payment history?”
Manage the supported post-payment activity on the customer payment side only.
- Insurance refunds
- Claims adjustments
- Medical billing
- Patient accounting
Technology & SaaS Customer value change
“How do relevant refunds or credits remain connected to the customer payment relationship?”
Keep the post-payment activity attached to the payment it came from. See Technology & SaaS.
- Subscription proration
- A usage-credit engine
- Revenue recognition
- Plan changes
Membership & associations Member value change
“How does relevant post-payment value stay connected to member or customer payment history?”
Keep the value change connected to the payment record. Membership status stays in the membership system or CRM and is never set by Bonza. See Membership & Associations.
- Membership-status changes
- Renewal rules
- Dues adjustments
Real estate & property Property-related value change
“How does relevant customer payment value remain connected when a post-payment change occurs?”
Keep the post-payment activity connected, in neutral payment language. See Real Estate & Property.
- Security deposit management
- Escrow
- Rent accounting
- Trust accounts
Nonprofits Where the payment model applies
“How does relevant post-payment activity remain connected where the Bonza payment model applies?”
Manage the relevant post-payment activity as a payment event. See Nonprofits.
- Donation refunds
- Gift adjustments
- Pledge credits
- Tax receipt changes
Other Salesforce-powered businesses The same three questions
Where collected customer payment value later changes, the same core questions remain, whatever the sector is called.
Was value returned? Was customer credit created? What does the payment position look like now? See Other Salesforce-Powered Businesses.
- Universal refund support
- Vertical-specific functionality
Two paths
Most Payments Follow the Normal Path. Some Need a Value Adjustment Later.
The second path is longer, and it is a legitimate part of the lifecycle rather than an exception to be handled elsewhere.
Nothing changes after collection
Four steps. Most payments never leave this path, which is why the other one is easy to under-build.
Value changes after collection
Seven steps, and step four is a person. Bonza supports the decision rather than making it.
Post-payment change should be an extension of the payment lifecycle, not a disconnected exception.
What goes wrong
Seven Credits and Refunds Mistakes That Break the Payment Story.
Each is a reasonable shortcut. Together they are why a customer question about a three-month-old payment takes an afternoon.
Treating the refund as a new, unrelated transaction
Keep the original payment and the refund connected on the same record.
Tracking customer credit in a spreadsheet
Keep relevant customer credit inside the payment lifecycle where the next payment can see it.
Calling customer credit a wallet
Describe exactly what it is: credit recorded and managed within Bonza Payments.
Losing the customer context after the refund
Keep post-payment activity tied to Salesforce and the same customer.
Letting Finance and Customer Service see different histories
Use one wider payment context, read differently by different teams.
Ignoring what the post-payment event does to receivables
Keep the current payment position visible where receivables are relevant.
Assuming “payment success” is the end of the lifecycle
Treat refund and credit as legitimate later stages of the payment relationship.
The cost nobody budgets for
The Hidden Cost Is Reconstructing Where the Value Went.
One customer asks one question. Six checks later, somebody can answer it.
Four steps, and the answer is the record rather than a reconstruction of it.
If teams have to rebuild the value story after every post-payment change, the payment operation is still fragmented.
Maturity
How Credits and Refunds Management Matures.
A description of how this tends to develop. No visitor is scored here, and no level is assigned to anyone.
Transaction-only
The payment is collected. Refunds or credits are handled separately, somewhere else.
History visible
Refunds become visible alongside the original payment activity rather than only in a provider portal.
Value connected
The original payment and everything that happened to it sit on the same customer.
- Original payment
- Refunds
- Customer credits
- Customer context
Lifecycle connected
The post-payment story joins the rest of the payment lifecycle.
- Receivables
- Future payments
- Recurring activity
- Customer experience
- Configured gateways
Operating view
Teams can see post-payment activity in context, with people still deciding.
- Payment Command Center
- AI Payment Insights
- Cross-team payment context
Across the business
One Post-Payment Event. Different Questions Across the Business.
Five teams, five sets of questions, one value history underneath them.
- What was collected?
- What was refunded?
- What relevant customer credit exists?
- How did the payment position change?
- Does this change the amount still open?
- What is the customer position now?
The same connected value history underneath every one of these questions, inside Salesforce.
- What happened to the customer's payment?
- Was value refunded?
- Does customer credit exist?
- What changed?
- What happens next?
- How do we keep post-payment events connected to the same customer and payment architecture?
The questions change by team. The value history should not.
Team views in more depth: Finance & Accounts Receivable and Customer Service.
Patterns
Common Credits & Refunds Patterns Across Salesforce-Powered Businesses.
Six situations that recur regardless of sector, and what connecting them changes.
Previously collected relevant value needs to be returned.
The refund becomes disconnected from the original payment.
Keep refund activity connected to the payment history.
Clearer post-payment context.
Relevant value should remain available for a future supported payment.
Credit is tracked outside the payment system.
Record and manage customer credit inside Bonza Payments.
Clearer future payment context.
A post-payment change affects the wider customer payment position.
Finance can no longer understand the original payment in isolation.
Keep payment, refund and relevant receivables context connected.
Clearer current position.
Customer credit exists and another relevant payment is expected.
The credit is disconnected from the future payment context.
Keep relevant credit visible within the wider payment lifecycle.
Better payment continuity.
One payment within a recurring relationship changes after collection.
The refund breaks the continuity of the payment history.
Keep post-payment activity connected to the recurring lifecycle.
Clearer payment history.
Original payments use different configured gateways.
Post-payment activity becomes provider-specific.
Keep the wider Salesforce payment context connected.
More consistent operational visibility.
Business outcomes
What Connected Post-Payment Context Actually Changes.
Defensible outcomes only. There is no claim here about lower refund rates, lower churn, higher retention, higher CSAT, faster refunds, lower support volume, lower costs, higher revenue, specific productivity gains or specific ROI.
Keep refunds and customer credits tied to the relevant payment history.
Understand how a payment changed after collection, and why.
Keep relevant customer credit within the wider payment lifecycle.
Connect customer credit with relevant future payment activity where supported.
Give Finance, AR, Customer Service and Operations relevant views of the same history.
Keep payment-management context connected across configured providers.
Help authorised teams understand and explain what happened to the payment.
Support refund and credit scenarios without conflating them or splitting the history.
Why Bonza
Why Manage Credits and Refunds Through Bonza?
Eight reasons, all of them about what happens to the record after the transaction succeeds.
Keep post-payment activity connected with relevant customer context.
Connect refund or credit activity to the payment that created it.
Support relevant refund and customer-credit scenarios without conflating them.
Understand the wider customer payment position where relevant.
Keep customer credit relevant to future supported payments.
Keep wider payment history connected across configured gateway activity.
Keep customer-facing payment context aligned with internal payment history.
Use AI Payment Insights and the Payment Command Center for additional operational context.
The wider lifecycle
Credits and Refunds Are Part of the Wider Payment Lifecycle.
Not every post-payment change touches every capability. These are the parts of the suite the value story can draw on.
Bonza Payments keeps relevant refund and customer-credit activity connected with the wider Salesforce customer payment lifecycle, including payment history, receivables and future payment context. That connection is the whole point of treating post-payment change as a stage of the lifecycle rather than an exception to it.
The payment may change after collection. The rest of the payment lifecycle should still make sense.
FAQ
Credits & Refunds Questions.
Twelve questions buyers actually ask, answered against established product scope.
What is the difference between a refund and customer credit?
A refund and customer credit are different. A refund returns relevant value through the applicable refund process, while customer credit records value within Bonza Payments for relevant future payment use where supported. A refund changes where the value goes; customer credit changes how the value may be used later. Both should stay connected to the original payment.
How does Bonza manage refunds in Salesforce?
A refund is raised through the applicable configured refund process, with the same provider that handled the original payment, and the resulting refund activity is recorded against that original payment rather than as a standalone transaction. The payment history is updated so both the collected amount and the returned amount remain readable on the same record.
How does Bonza manage customer credit?
Customer credit is recorded and managed within Bonza Payments against the customer, and is available for relevant future payment use where supported. It sits in the payment lifecycle rather than in a separate finance record, so whoever handles the next payment can see that it exists.
Is customer credit the same as a wallet, and does Bonza hold customer funds?
No to both. Customer credit in Bonza Payments should not be interpreted as a bank balance, stored cash or digital wallet. It is credit recorded and managed within Bonza Payments for relevant future payment use where supported. Bonza does not hold or store customer funds, and this is not a stored-value account, deposit account, trust account or escrow.
Can customer credit be withdrawn as cash, or transferred to another customer?
Neither is claimed. Customer credit is a payment-management record relevant to future supported payment activity, not money that can be paid out or moved between customers. It earns no interest, and no multi-currency conversion or expiry rule is claimed either.
Can customer credit be used for a future payment?
Where customer credit exists and is relevant to a supported payment flow, it can be part of the context for that future payment. It is applied only where supported and by decision; no automatic application rule, allocation logic or partial-payment mechanic is claimed.
How do refunds affect Accounts Receivable?
Where receivables are relevant, a post-payment change can alter how Finance understands the customer payment position, because the collected figure no longer means what it did before. That is a change in payment context rather than an accounting action: there is no general ledger posting, no journal entry, no automatic receivable reconciliation and no automatic write-off.
Can refunds work with recurring payments?
Where recurring payments are relevant, refund activity stays connected to the wider recurring payment relationship and attaches to the specific payment it relates to. It does not pause, skip, retry, cancel or reschedule the arrangement, and it involves no subscription billing, plan adjustment, recalculation or proration.
Can refunds work across multiple payment gateways?
Bonza supports multiple configured payment gateways, and where a refund is relevant the underlying process stays associated with the applicable configured provider and payment context. Cross-gateway refunds are not claimed, and there is no automatic gateway selection, smart routing, automatic failover, least-cost routing, automatic retry, unified settlement or gateway reconciliation.
Can customers request their own refunds, and does Bonza approve refunds automatically?
No to both. Self-service refund initiation is not claimed unless separately established, and no refund or credit is approved automatically. Bonza Payments does not automatically decide whether a refund or customer credit should be used; that remains a business decision within the relevant process, and AI Payment Insights surface context for human review rather than acting.
Does Bonza support partial refunds?
Partial refund capability is not claimed here unless separately established. What this page describes is that whatever relevant value change a business makes, the resulting refund or credit activity stays connected to the original payment and the wider customer payment history.
Does Bonza replace accounting software?
No. Bonza manages the customer payment lifecycle, not the books. It provides no general ledger, journal entries, revenue recognition, tax adjustments, accounting credit notes, bank reconciliation, settlement reconciliation or automatic accounting reconciliation, and it is not an ERP.
Credits & Refunds
When Payment Value Changes, Keep the Customer Payment Story Intact.
See how Bonza Payments keeps refunds, customer credits, payment history, receivables and future payment context connected inside Salesforce.