Refund management
Manage refunds and customer credits as part of the same Salesforce-native payment lifecycle — so what happens after a payment stays connected to the customer, the transaction and future payment activity.
Part of the Salesforce-native Bonza Payments suiteCollected from Acme Customer
Every refund starts from the payment that created it — so whatever happens next stays attached to this record and this customer.
Refund selected. The relevant value is returned through the configured payment process, and the event stays attached to PAY-10482 in the customer's payment history.
Interface shown is an illustrative representation of Bonza Payments inside Salesforce. Amounts, references and dates are sample values. Statuses shown depend on your configured payment process. [Confirm the supported refund status set before launch.]
The real problem
Payments do not always stay final. The lifecycle doesn't always end at “paid.”
A CUSTOMER MAY
The operational challenge is not merely “can we send money back?” It is everything the answer has to stay attached to:
When refunds are handled only as isolated gateway events, finance and customer-facing teams can lose the context around what actually happened.
How to think about it
A mature refund process therefore preserves the relationship between the two events. Whether that relationship survives is what separates the two approaches below.
The important question isn't simply whether the refund was initiated. It's whether the entire payment story remains understandable afterward.
The post-payment fork
When a payment needs to change, the value has somewhere to go. Bonza supports both established paths, and the right one depends on your configured business process and the customer's situation.
Use when the appropriate business or customer outcome is to return the relevant value through the configured refund process.
Use when the relevant value should stay associated with the customer for future payment use within Bonza Payments.
Neither path is better than the other. Bonza does not steer a customer toward a credit, and the choice should reflect the configured business process and the customer situation rather than a default. Credit behaviour follows what is configured in your Bonza setup.
Core capability
Refund activity starts from the payment that created it — the customer, the reference, the original amount and the payment context around it, rather than a standalone transaction typed in somewhere else.
Capture the relevant refund or value-adjustment information supported by your configured process, attached to the original payment record. [Confirm partial-refund support before launch.]
Where supported by the configured process, the value can be returned as a refund or retained as customer credit — two established outcomes for the same adjustment.
The refund or credit event stays visible as part of the customer's payment history, so the transaction story can be read months later without reconstruction.
Where customer credit is created, it can remain available for relevant future payment use — so the post-payment event connects forward into the wider Bonza lifecycle instead of ending the thread.
Refund workflow
Processing behaviour follows your configured payment process and the capabilities of the gateway involved. Bonza manages the refund within Salesforce; it is not the payment processor.
Transaction relationship
The same customer, read as one relationship rather than four disconnected records.
Available credit shows $0 here because this illustrative adjustment took the refund path. Had it taken the credit path, the same value would appear as available credit instead.
Dates and values are illustrative. They show the order of events in the record, not how long a refund takes — processing time depends on the payment method, the gateway and the financial institution involved.
Customer credit
Where the appropriate outcome is customer credit, Bonza can keep that value associated with the customer so it is available for a future payment within the same relationship.
Numbers are illustrative only. This describes operational payment visibility, not accounting treatment. Whether credits expire, and how they may be applied, follows your configured Bonza setup — and credits stay with the customer they belong to. [Confirm credit configuration details before launch.]
Customer payment experience
The customer experience shouldn't fragment simply because a transaction has moved into a refund or credit stage. The relationship continues; the record should reflect that.
Refund and credit activity is managed by your team within Bonza. This page does not describe customer self-service refund initiation, a customer refund portal, refund cancellation or customer-controlled refund routing. [Confirm which customer-facing post-payment capabilities are in scope before launch.]
Customer-facing teams
Refund questions frequently become customer-service questions. A useful payment record lets an authorised team see what actually happened without reconstructing it across disconnected payment information.
This is customer context within Salesforce — the payment record sitting where your teams already work. It is not a claim of specific Service Cloud workflows or service automation. [Confirm which Salesforce clouds are in scope before launch.]
One customer, one payment story — collected, returned, retained and expected.
Multi-gateway
The refund is processed by the gateway that handled the payment. The record of it belongs with your customer in Salesforce.
Gateways shown are examples. Refund functionality varies by gateway — supported refund methods, timing, behaviour and API capabilities differ, and not every gateway supports the same options. Bonza is the Salesforce-native payment-management layer; the underlying gateway handles processing according to its own capabilities and your configuration. [Confirm the supported gateway list and per-gateway refund behaviour before launch.]
The wider picture
When money previously collected is returned, the wider payment picture needs to stay understandable — what was collected, what went back, what is held as credit and what is still expected.
Operational visibility, not formal accounting. Bonza is not an ERP, a general ledger or an accounting system.
Payment Command Center
A refund shouldn't disappear into a gateway portal. It belongs in the same operational view as everything else that happened to your payments.
Activity shown is illustrative. Bonza does not report refund-rate analytics.
Side by side
Both remain part of the broader customer payment lifecycle — visible against the original payment, in the customer's history and in the wider payment operation. Neither is universally better; the right path is the one your configured process and the customer's situation call for.
Use cases
Connected suite
The relevant value goes back through the configured refund process, and the event stays attached to the original payment.
The value stays with the customer, available for a future payment.
What changes
These describe operational visibility. We don't claim faster refunds, lower refund rates, higher retention, reduced churn, cost savings, guaranteed satisfaction or fewer chargebacks — refund timing and outcomes depend on your process, your gateway and the institutions involved.
Why Bonza
Refund activity stays connected to the Salesforce customer and payment information your teams already work in.
The relationship between the payment and what happened afterward is maintained, not reconstructed later from two systems.
Support for different established post-payment value paths, so the outcome can match the situation.
Refunds connect with payments, receivables, credits and future activity rather than sitting outside them.
Manage payment operations across configured gateway options while respecting each gateway's own capabilities.
Relevant refund and credit activity stays visible within the broader payment operation, not buried in a portal.
FAQ
Refund management is the process of returning or otherwise managing value after a customer payment has already been collected. It covers identifying the original payment, deciding what happens to the value, processing the outcome through the configured payment process, and keeping the result visible in the customer's payment history.
Yes. Bonza Payments is Salesforce-native, so refund activity is managed alongside the customer and payment records rather than only in a separate gateway portal. The gateway still performs the underlying processing according to its own capabilities.
A refund is treated as a new payment event that points back at the payment that created it. The original payment, the returned value, the refund status and the customer context stay associated, so the transaction story can be read as one sequence rather than two unrelated records.
Where your configured process supports it, yes. When a refund is initiated, the value can either be returned through the configured refund path or retained as customer credit within Bonza Payments. Which option applies depends on your configured business process and the customer's situation.
Customer credit keeps the relevant value associated with the customer inside the application instead of returning it. It is stored and managed within Bonza and remains connected to that customer's payment relationship.
Yes — available credit can be used in the customer's future payment journey, so value retained today can be applied to a payment later. How it is applied follows your configured setup.
Yes. The refund or credit event stays part of the customer's payment history alongside the original payment, so finance, operations and customer-facing teams can understand what happened without reconstructing it.
Bonza supports working with multiple configured gateways, with a default or preferred gateway where you need one. Refund functionality varies by gateway, though — supported refund methods, behaviour, timing and API capabilities differ, so what is possible for a specific payment depends on the gateway that processed it and how it is configured.
Processing time depends on the payment method, the gateway and the customer's financial institution — not on Bonza. We don't promise instant, same-day or guaranteed refund timing. Bonza's role is to manage the refund within your Salesforce payment process and keep its status visible.
Refund amounts are captured through the configured refund process, and support for returning part of a payment depends on that configuration and on the gateway involved. We'd rather confirm this against your setup than promise it here. [Confirm partial-refund support before launch.]
Yes. Refunds and credits sit alongside collected payments, outstanding amounts and recent payment activity in the Command Center, so a refund stays part of the broader payment operation rather than disappearing into a gateway portal.
A refund returns the relevant value through the configured refund process, so it leaves the payment relationship. A customer credit keeps the value associated with the customer inside Bonza, available for future payment use. Both stay visible against the original payment and in the customer's payment history, and neither is universally better than the other.
See how Bonza Payments helps you manage refunds and customer credits without losing the Salesforce customer and payment context behind the original transaction.