Making finance the only team that understands payment history
Every payment question becomes an internal handoff, and the customer experiences it as a callback.
BetterGive authorized service users relevant payment context.
For customer service teams
Give Customer Service the Payment Context Behind Every Conversation.
Connect customer service teams with relevant payment history, receivables, refunds, customer credits and upcoming payment context inside Salesforce so they can understand the payment situation before deciding what happens next.
Powered by the Salesforce-native Bonza Payments suiteIllustrative customer service view for one sample customer, Acme Corporation. Its current payment position shows $400 outstanding, $400 due on 15 October, nothing overdue, and $600 upcoming on 15 October. Its payment history shows a payment of $600 collected on 15 September, a refund of $100 raised on 1 October, a customer credit of $100 created on 1 October and available, and a next payment of $600 expected on 15 October. The service context panel shows the customer asking whether their refund was completed, the relevant payment PAY-10482, the refund REF-2041, the associated customer credit and the next expected payment. Every figure on this page is illustrative sample data. Expected payment activity is not collected payment, and the response to the customer is always a person's.
The short answer
What Does Bonza Payments Do for Customer Service Teams?
Payment context for the conversation — not another system to work in.
Bonza Payments gives customer service teams access to relevant Salesforce-connected payment context so they can better understand customer questions involving payment history, outstanding amounts, refunds, customer credits, recurring payments and upcoming payment activity.
Bonza does not replace a customer service platform. It is not a case-management system, a contact centre, a ticketing system or a knowledge base, and it does not route cases, hold conversations or answer customers. It provides the payment-management context that can support a more informed customer conversation, which a person then has.
The real problem
The Customer Asks One Question. Your Team May Need Four Systems to Answer It.
None of these questions is hard. What makes them hard is that the answer lives in pieces.
"Where is my refund?"
Four places before an answer
- Salesforce customer record
- Payment gateway portal
- Finance notes
- Refund history
- Then ask Finance — and call the customer back
"Why do I still owe money?"
Five facts that have to agree
- The original payment obligation
- The previous payment
- The outstanding amount
- Any customer credit
- Any refund activity
A third customer asks what happens with their next recurring payment, and now the team needs the recurring arrangement, the payment-method context and the expected date. The problem is not the customer's question. The problem is that the payment story is fragmented, and the customer experiences that fragmentation as a transfer, a callback or a contradiction.
Service teams do not need every finance function. They need the right payment context at the moment of the conversation.
Two different things
A Transaction Record Is Not the Same as the Customer Payment Story.
Transaction view
One row, one moment
Payment$500.00 · collected
True, and not enough. It cannot tell a service user whether anything happened afterwards, what remains open, or what the customer is actually asking about.
Customer payment story
What the customer actually remembers
Customer
Original payment$500.00
Refund$100.00
Customer credit$100.00 where relevant
OutstandingRelevant amount
Next paymentExpected
Current customer payment position
The customer remembers the relationship. A service team needs more than one transaction to explain it.
Question, context, response
Start With the Customer Question. Surface the Payment Context Behind It.
Six questions a service team hears constantly. Each one needs a different slice of the same payment story — and one of them should not be answered at all.
The customer asks
"Did my payment go through?"
Payment context surfaced
What the service user can now do
Bonza surfaces context. It does not write the reply, contact the customer, approve a refund, issue a credit or decide what the customer is told. Illustrative sample data throughout.
The model
Give Service Teams the Context They Need—Not Another Payment System.
Four layers. The last one belongs to a person, and that is the point.
Layers 01 & 02
Customer context, then payment context
Customer contextCustomer · account · relevant Salesforce relationship
Payment contextPayments · receivables · refunds · credits · recurring activity
Layers 03 & 04
Current position, then a human decision
Current positionPaid · outstanding · due · overdue · upcoming
Service decisionExplain · clarify · escalate · route to finance where necessary
Bonza does not decide the response. Layer four is always a person acting within their authorized process.
Capability by capability
Seven Kinds of Payment Context a Service Conversation Needs.
Each one is a question a customer already asks. None of them requires the service team to become finance.
01
Explore payment management
See the Payment Behind the Customer Question.
When the customer asks about a transaction, the service team should be able to see relevant payment context without treating the gateway portal as the primary customer record.
Customer
Payment historyDate · amount · type · gateway · status
Relevant payment context in Salesforce
02
See What the Customer Still Owes.
A customer may believe payment is complete while part of the obligation remains unresolved. Receivables context helps the service team understand the situation before responding.
Original obligation
Payment activity
Outstanding
Due
Overdue
Seeing the position is not the same as being authorized to change it. Service users work within their configured permissions and business process; this page describes no specific permission model.
Where the wider position is the question, due & overdue payments and finance & accounts receivable cover it in full.
Explore receivables
03
Keep Refund Questions Connected to the Original Payment.
The customer should not have to repeat the entire transaction story because the refund exists in a separate system.
Original payment
Refund required
Refund activity
Current status
Customer payment historyOne connected sequence
Refund timing is never promised on this page. Chargeback and dispute management, automatic refund approval and customer-initiated refunds are not claimed capabilities.
Explore refunds & credit management
04
See Customer Credit in the Context of What Happened Before.
Credit is only useful to a service user who can answer four things: where did it come from, how much is available, has any of it been used, and can it apply to a future payment where supported.
Previous payment
Value change
Customer credit
Available credit$100.00 illustrative
Future payment context
Customer credit is customer value recorded and managed within Bonza Payments — never a wallet, a cash balance, stored funds or a bank balance.
Explore credit management
05
Understand the Next Payment Before the Customer Asks.
For ongoing customer relationships, service teams may need more than historical payment information. Upcoming payment context helps them understand what is expected next.
Customer
Recurring payment arrangement
Last payment15 Sep · $600.00 · collected
Current status
Next payment15 Oct · $600.00 · expected
Expected and scheduled activity is not guaranteed collection. A schedule says when a payment event is expected, not what will happen at it.
Explore manage recurring payments
06
See When a Payment Method May Matter to the Next Conversation.
An approaching expiry can provide useful service context when a future payment is expected — as timing information, nothing more.
Payment methodExpires 31 Oct
Next payment15 Nov
AttentionExpiry lands first
This does not say the next payment will fail. Automatic card updating, automatic customer notification and automatic remediation are not claimed capabilities.
Explore payment method expiry
07
Keep Gateway Details Behind the Payment Story.
A service team generally needs to understand what happened to the payment. They should not have to become experts in each provider’s portal to explain it to a customer. Configured payment gateways handle the relevant underlying payment processing, while Bonza Payments keeps the wider payment context connected with the Salesforce customer relationship — so the provider is a detail on the payment rather than a separate place to go looking.
Gateway AGateway BGateway C
Bonza payment activityOne record set
Customer contextSalesforce
Service viewRead together
Settlement reconciliation, smart routing and automatic failover are not claimed capabilities. Provider capabilities are not interchangeable, and the gateway is recorded against the payment as context rather than being the customer record.
Where the gateway environment itself is the question, multiple payment gateways covers the configured model in full.
Explore manage multiple payment gatewaysOne customer, one timeline
See the Customer Payment Story in Order.
Customer service should not have to reconstruct this chronology from separate systems while the customer waits.
Acme Corporation
ILLUSTRATIVE SEQUENCE
Illustrative payment chronology for one sample customer. 10 August: an invoice and payment obligation of $1,000 is raised. 15 August: a payment of $600 is collected, leaving $400 outstanding. 1 September: a refund of $100 is raised against that payment and carries its relevant refund status. 1 September: a customer credit of $100 is created from that refund and is available for relevant future payment use. 15 September: a recurring payment of $600 is collected under a monthly arrangement. 15 October: the next payment of $600 is expected, which is expected activity and not collected payment. The payment method on the arrangement expires 31 October, which lands before the following expected payment. Every figure is illustrative sample data.
Seven events, one customer, one order. Asked "why do I still owe money?", a service user reading this sequence can see that a payment was made, that it was partial, and that a refund and a credit sit in between — which is a different conversation from "our records show an outstanding balance".
Two sides of one payment
See What the Customer Is Asking About—and What the Business Knows.
What the customer says
"I paid last week. Why do I still have an amount due?"
From where the customer sits this is a contradiction, and being told the balance again does not resolve it.
What Bonza shows the service user
Both facts, in one place
Original amount$1,000.00
Payment received$600.00
Outstanding$400.00
Due15 Oct
Customer creditRelevant
The customer is right and the business is right. The service user can now explain which part of the obligation the payment covered — and the reply is theirs to write.
What the customer experiences and what the service team explains should come from the same payment story.
What to surface, and when
The Right Payment Context Depends on the Question.
More context is not automatically better. Too little creates handoffs; too much creates confusion and governance concerns.
"Did you receive my payment?"
Payment amountDateStatus
"What do I still owe?"
OutstandingDue or overdue status
"What happened to my refund?"
Original paymentRefund contextNever a promised date
"Do I have credit?"
Relevant customer creditAvailable value
"What is my next payment?"
Recurring contextUpcoming payment contextExpected, not guaranteed
"Why can't I use this payment method?"
Only supported payment-method contextDo not infer a reason that is not known
Escalation
Give Service Enough Context to Help—and a Clearer Point to Escalate.
The goal is not to make customer service perform finance's job. It is to reduce the back-and-forth caused by missing payment context.
01
Customer question
A payment question arrives through whatever service channel the business already uses.
02
Service team reviews payment context
Relevant payment history, current position, refund and credit context, read against the Salesforce customer.
03
Can service resolve the question?
A judgement a person makes within their authorized process.
YesRespond within the authorized process, with the payment context visible rather than remembered.
NoEscalate to the relevant finance or operations user — and the payment context travels with the question instead of being gathered twice.
04
Connected payment context follows the customer story
Whoever picks it up starts from the same sequence, not from a summary of a summary.
Three connections worth making
Keep the Payment Conversation Connected to Everything Around It.
Experience Cloud
Payments customers make themselves should not vanish from the service view
Customer
Salesforce Experience Cloud
Bonza payment experience
Payment · configured gateway
Salesforce customer context → customer service
Bonza does not manage cases, identity, authentication, knowledge or service workflows.
Explore Experience Cloud payments
AI payment insights
Surface payment context — not the service conversation
Payment data
Relevant signal
AI payment insight"Payment activity moved into overdue status"
Customer + payment context
Service or operations user reviewA person decides
AI does not write customer responses, contact customers, approve refunds, issue credits, make financial decisions, or predict customer intent or churn.
Explore AI payment insights
For service leaders
Visibility into the payment operation behind customer questions
The Payment Command Center gives broader payment-operational context — collected, outstanding, due, overdue and upcoming activity, refunds, customer credits and attention items, alongside recent customer payment activity. It is a payment operations view, not a service analytics dashboard: there is no call or case volume, first-contact resolution, CSAT, NPS, agent productivity or service SLA in it, and none is claimed anywhere on this page.
Explore the Payment Command CenterWhat most companies get wrong
Five Payment-Service Mistakes That Create Unnecessary Customer Friction.
Using the gateway portal as the customer payment record
Processing information sits disconnected from the Salesforce customer relationship it belongs to.
BetterKeep the wider payment context connected to the customer.
Showing only the latest transaction
Refunds, credits, outstanding balances and recurring activity all change the customer story.
BetterShow lifecycle context, not the most recent row.
Treating refunds and credits as separate support issues
The customer sees one relationship while internal teams see several systems.
BetterConnect post-payment activity to the original payment.
Giving service too little or too much financial information
Too little creates handoffs. Too much creates confusion and governance concerns — and neither helps the customer.
BetterSurface payment context aligned to the user's role and authorized process.
Use cases
Where Payment Context Helps Customer Service Most.
Customer asks about a payment
Situation
The customer wants to know whether a payment was received.
Problem
The service team searches another system or asks finance.
Bonza
Keep relevant payment activity connected with Salesforce customer context.
Outcome
Clearer payment context.
Customer asks about an outstanding amount
Situation
The customer believes they have already paid.
Problem
The team sees a transaction but not the wider receivables position.
Bonza
Connect relevant payment and outstanding context.
Outcome
A clearer explanation of the current position.
Customer asks about a refund
Situation
A refund was initiated after the original payment.
Problem
The refund sits outside the customer's Salesforce history.
Bonza
Keep relevant refund context tied to the wider payment lifecycle.
Outcome
Better visibility into the post-payment story.
Customer has credit
Situation
The customer has relevant credit from a previous payment event.
Problem
The service team cannot easily confirm it.
Bonza
Keep customer credit connected with the payment relationship.
Outcome
Clearer customer-value context.
Customer asks about the next payment
Situation
The customer has a recurring payment relationship.
Problem
The service team only sees previous transactions.
Bonza
Connect relevant upcoming recurring payment context.
Outcome
Better forward payment visibility.
Multiple payment gateways
Situation
Customer payments can be processed through different providers.
Problem
Service users search gateway-specific systems.
Bonza
Keep relevant payment activity within the broader Salesforce payment context.
Outcome
More consistent service visibility.
Maturity
How Connected Is Payment Context in Your Service Operation?
A description of how payment context tends to reach service teams, not a score. Not every support team needs or should have the same access.
Level 01
Fragmented
- Customer asks support
- Service checks Salesforce
- Finance checks the payment system
- Gateway checked separately
- Multiple internal handoffs
Level 02
Transaction visible
- Service can see individual payment activity
- Wider lifecycle context may still be missing
Level 03
Payment context connected
- Payment history
- Receivables
- Refunds
- Credits
- Recurring activity
- Connected around the customer
Level 04
Lifecycle-aware service
- Upcoming payment context
- Payment method expiry
- AI payment insights
- Payment Command Center
- Additional operational awareness
No customer is scored here, and no support team is required to have the same access as another.
Outcomes
What Connected Payment Context Actually Gives a Service Team.
Clearer customer payment context
Give authorized service teams the relevant information behind customer payment questions.
Less internal reconstruction
Reduce the need to piece together customer payment history from separate systems mid-conversation.
Better refund context
Keep refund activity connected to the original customer and payment relationship.
Connected customer credit
Make relevant customer credit visible within the wider payment story where supported.
Better recurring payment context
Understand relevant previous and upcoming recurring payment activity.
More consistent payment conversations
Connect customer-facing payment activity with the internal payment context that explains it.
Clearer escalation context
When finance or another team becomes involved, the relevant payment story travels with the question.
Fewer contradictions
When the customer and the record disagree, both facts are visible in one place rather than in two teams.
What is not claimed
No reduction in support tickets, CSAT, NPS, first-contact resolution, handle time, service cost, retention or productivity figure appears on this page.
Why Bonza Payments
Keep Customer Conversations Connected to the Payment Lifecycle.
Salesforce-native customer context
Keep relevant payment activity close to the Salesforce customer relationship the service team already works in.
Complete payment lifecycle
Connect payment history with receivables, recurring activity, refunds and credits.
Customer + internal continuity
Connect customer-facing payment journeys with the internal payment view that explains them.
Multi-gateway context
Keep relevant payment activity visible across the configured gateway environment.
Forward payment visibility
Bring relevant upcoming payment context into the customer payment story.
Payment intelligence
Use payment method expiry, AI payment insights and the Payment Command Center as additional operational context.
Connected suite
The Customer Service Conversation Sits Inside a Bigger Payment Lifecycle.
Customer service does not need a separate payment system. It needs the right view of the same payment lifecycle.
The customer should not be transferred between teams simply because the payment story is fragmented.
Questions
Payment Context for Customer Service, Answered.
How can customer service teams see payment information in Salesforce?
Because Bonza Payments is Salesforce-native, relevant payment activity stays associated with the Salesforce customer record rather than living only in a provider portal. Authorized service users can see the payment context connected to the customer they are already looking at — payment history, current position, refunds, credits and relevant upcoming activity — within their configured permissions and business process.
Can Bonza show a customer's payment history?
Yes. Relevant payment activity can be read as a sequence against the customer: what was paid, when, of what type, through which configured gateway, and with what status. That sequence is what turns a single transaction row into an explanation a service user can give.
Can customer service teams see outstanding, due and overdue payments?
Yes, as context. Outstanding, due and overdue are distinct states of the same obligation, and seeing which one applies is usually what answers "why do I still owe money?" Whether a service user can act on that position is a matter of their configured permissions and the business process, not something this page defines.
Can service teams see refund information?
Yes. Refund activity stays connected to the original payment, so a service user can describe what was raised and where it currently stands. Refund timing is never promised, and customer-initiated refunds, automatic refund approval, chargeback and dispute management are not claimed capabilities.
Can service teams see customer credit?
Yes, including where it came from and how much is available. Customer credit is customer value recorded and managed within Bonza Payments — not a wallet, a cash balance, stored funds or a bank balance — and it is not applied automatically.
Can Bonza show upcoming recurring payments and payment methods approaching expiry?
Yes, as forward context: the recurring arrangement, the expected next payment and its date, and relevant payment-method expiry where it lands before expected activity. Expected and scheduled activity is not guaranteed collection, and expiry context is not a prediction that a payment will fail. Automatic card updating, automatic customer notification and automatic remediation are not claimed.
Can Bonza work with multiple payment gateways?
Yes. Payments processed through different configured gateways can be read together against the customer, with the gateway recorded as context on the payment. There is no smart routing, automatic failover or settlement reconciliation, and provider capabilities are not interchangeable.
Does Bonza replace Salesforce Service Cloud?
No. Bonza provides payment-management context. It is not a case-management, contact-centre or customer-service platform, and it should not be positioned as one.
Does Bonza manage customer service cases?
No. Case routing, omni-channel support, chatbots, voice, email-to-case, escalation workflows, knowledge articles, support SLAs, contact-centre analytics and workforce management are not Bonza capabilities. Those belong to your service platform; Bonza supplies the payment context beside it.
Does Bonza automatically answer customer payment questions?
No. AI payment insights remain an operational insight layer that surfaces relevant changes — such as payment activity moving into overdue status — for a person to review. AI does not write customer responses, contact customers, approve refunds, issue credits, make financial decisions, or predict customer intent or churn.
Can customer service teams issue refunds or credits?
Only where that action is actually supported and appropriate to the configured user permissions and business process in your implementation. This page does not define an authorization model and does not claim that service users can approve refunds or create credits — that is a decision for your own configuration and governance.
Can customer-facing payments remain connected to the Salesforce customer record?
Yes. Where customers make relevant payments through a customer-facing journey, including Salesforce Experience Cloud, the resulting payment activity can remain connected to the wider Salesforce customer relationship — so the service team is not looking at a different payment story from the one the customer just experienced.
Customer service
Help the Customer Without Reconstructing Their Payment Story First.
See how Bonza Payments connects customer payment history, receivables, refunds, credits and upcoming payment activity inside Salesforce so service teams can understand more of the payment conversation before deciding what happens next.