Education
Manage one-time and recurring payment activity, receivables, due and overdue balances, refunds, customer credits and upcoming payments inside Salesforce with Bonza Payments.
Salesforce-native payment management suiteIllustrative payment relationship for one sample learner, Demo Student, held against a Salesforce account. The current payment position shows $2,000 collected, $3,000 outstanding, $3,000 due and nothing overdue. The payment lifecycle runs from a payment obligation of $5,000, through a payment of $2,000, to a remaining amount of $3,000, a next payment on a relevant date, and recurring activity where relevant. Payment context alongside it records relevant refund activity, relevant customer credit, the relevant payment method and the configured gateway. Every figure on this page is illustrative sample data. Expected payment activity is not collected payment, and Bonza does not hold customer funds.
The short answer
Payment management inside Salesforce — not a student system.
Bonza Payments provides Salesforce-native customer payment management for education organizations that need to keep learner or payer payment activity connected to the wider Salesforce relationship. It can support relevant one-time and recurring payments, receivables, due and overdue payment visibility, refunds, customer credits, configured payment gateways, customer-facing payment experiences and upcoming payment visibility. Put plainly: Bonza Payments can connect relevant one-time payments, recurring payments, receivables, refunds, customer credits, configured payment gateways and upcoming payment visibility inside Salesforce.
Bonza should not be positioned as a student-information, enrollment, learning-management or education-accounting platform. It is not an SIS, LMS, admissions or enrollment platform, financial aid or scholarship system, campus ERP, student accounting or tuition-management platform, and it does not calculate fee structures or hold customer funds.
The real problem
Education payment relationships can include multiple payment events over time. A connected payment-management model helps teams understand what was paid, what remains outstanding and what payment activity is expected next.
A course or programme, an organization they deal with, and a set of amounts they have paid or still owe. From where the payer sits there is no boundary between the learning and the invoice for it.
The payment operation becomes harder to understand when each payment event lives in a different place.
Five realities
A learner or payer may have multiple relevant payment events across the relationship — a one-time payment, a recurring payment, an invoice-related payment or another supported payment obligation.
The person paying is not always the person receiving the educational service, so this page uses neutral terms — student, learner, payer, customer, account — and assumes no particular sponsor arrangement.
"Was a payment processed?" is the easy half. What remains outstanding, what is due, what is overdue, what is expected next, whether there was a refund and whether credit is available are the operational questions.
The payer should be able to understand what they are paying, how much, what relevant payment option is available, and what happened after payment — without learning the organization's internal architecture.
Finance needs receivables, due and overdue, and upcoming payments. Customer-facing teams need payment history, refund and credit context, and the next payment. Both should read the same relationship.
Education payments are rarely a single transaction. They are a series of payment moments, and the position that matters is the one that moves as those moments accumulate.
One learner, many payment moments
Step forward through eight payment moments in a single payer relationship. The position on the right recalculates at each one — because that is what a payment event actually does.
Collected falls when a refund is raised. Due appears when a date is reached, not when an amount changes. Expected activity is never counted as collected.
The organization may see multiple transactions. The customer experiences one continuing relationship.
Beyond processing
Processing tells you whether a payment event occurred. Payment management tells you what that event means for the relationship.
Two readings of one payment
Accurate, and silent on everything an education team is usually being asked about.
Education payment relationships often need more context than one transaction can provide.
Capability by capability
Each one is an ordinary payment scenario, and each stays attached to the same payer.
Not every payment relationship is recurring. Organizations may need relevant one-time or ad hoc payments while keeping the activity connected to Salesforce.
The operational question is not only "was payment received?" It is also "what remains unresolved for this payer relationship?"
Timing gives operational meaning to an outstanding amount. An unpaid amount that is not yet due is a different situation from one that has passed its due date, even though the number is identical.
Where the whole position matters, improve receivables visibility covers it across past, present and future.
Explore due & overdue paymentsWhere a payer makes relevant repeated payments, Bonza can manage recurring payment activity within the broader Salesforce payment lifecycle.
Education finance and operations teams may need visibility into relevant payment activity expected in future periods, particularly where recurring arrangements run alongside one-off obligations.
Post-payment changes should remain part of the wider payment history rather than becoming a separate record nobody can reconcile to the payer.
Customer credit is credit recorded and managed within Bonza Payments — never a wallet, a cash balance, stored funds or a bank balance.
Explore simplify refunds & creditsAn education organization may need more than one configured payment provider. Configured payment gateways handle relevant underlying payment processing, while Bonza Payments manages the broader Salesforce payment context around those transactions — so gateway flexibility does not split the payment operation into one view per provider.
The payer should not need to understand the organization's internal payment architecture. Where Salesforce Experience Cloud is part of the customer environment, relevant payment journeys can remain connected to the Salesforce relationship.
Where payers pay through a portal, Experience Cloud payments covers that environment in full.
Explore improve customer payment experienceAttention, not automation
One story, two audiences
Different teams need different levels of payment context. They should not have to reconstruct different versions of the same payer relationship.
The Payment Command Center brings collected, outstanding, due, overdue and upcoming activity together with payer receivables, upcoming payment activity, attention items and recent payment activity. It is a payment-operations view — no enrollment, attendance, grades or student-record data sits in it, and none is claimed.
Explore the Payment Command CenterUse cases
A learner or payer needs to make a relevant one-time payment.
The payment becomes disconnected from Salesforce customer context.
Keep the payment activity connected to the wider payment lifecycle.
Clearer payment history.
The payer makes repeated relevant payments.
Each payment cycle is viewed separately.
Manage recurring payment activity inside the wider Salesforce relationship.
Better lifecycle continuity.
A relevant payment obligation remains unresolved.
The team needs to know what is outstanding, due or overdue.
Connect receivables and payment timing.
Clearer operational visibility.
Relevant payment value changes after collection.
The new value state becomes disconnected from the payment history.
Keep refund or credit context connected.
Clearer post-payment understanding.
A payer makes a payment through a Salesforce-connected experience.
The customer-facing journey becomes separate from internal payment operations.
Connect relevant payment activity back to Salesforce.
A more connected payer experience.
The organization uses more than one configured payment gateway.
Each provider starts creating a separate operational payment view.
Keep relevant payment activity within the wider Salesforce payment model.
More consistent operational context.
What most education organizations get wrong
The long-term payer relationship disappears, and each new payment starts the explanation over.
Processing activity sits separated from Salesforce customer context, so every question starts in the wrong system.
Payment and customer context must be reconstructed manually, and the spreadsheet quietly becomes the system of record.
Teams have limited visibility into what is due or expected next — which in a recurring relationship is most of the picture.
The payment story becomes difficult to explain the moment anything changes after collection.
Maturity
A description of how education payment operations tend to develop. It is not a score, no visitor is being assessed, and no institution needs this exact progression.
Plenty of institutions operate perfectly well without reaching level five.
Outcomes
Keep relevant payment activity tied to Salesforce customer context.
Understand collected, outstanding, due and overdue payment activity.
See relevant upcoming and recurring payment activity before the date arrives.
Reduce the need to piece payment information together across systems.
Keep refunds and customer credits inside the wider payment story.
Use multiple configured providers within one broader payment-management model.
Connect customer-facing payment activity with internal payment operations.
Give authorized users more payment context before deciding what needs attention.
No reduced DSO, higher collections, faster payment, improved enrollment or retention, lower churn, higher satisfaction, productivity gain or ROI appears on this page.
Why Bonza Payments
Keep payer and payment context in Salesforce, where the relationship already lives.
Connect one-time payments, recurring payments, receivables, refunds, credits and future payment activity.
Keep payment activity connected to the learner or payer relationship rather than a transaction log.
Support multiple configured gateways without making every provider a separate payment operation.
Connect customer-facing payment journeys with Salesforce.
Use recurring payment context, payment forecasting and payment method expiry where relevant.
Use AI payment insights and the Payment Command Center for additional operational context.
Not an SIS, LMS, admissions, enrollment, financial aid, scholarship, campus ERP or tuition-management system.
Connected suite
The same payment foundation serves finance, business operations, customer service and Salesforce teams without becoming a different system for each.
The payment relationship should not break away from the customer relationship.
Questions
By keeping the payment operation in the same environment as the learner or payer relationship. Bonza Payments is Salesforce-native, so one-time and recurring payments, invoice-driven obligations, receivables, refunds, customer credits and upcoming payment activity stay associated with the Salesforce record rather than living in a gateway portal or a spreadsheet beside it.
Yes, both. A one-time or ad hoc payment stays attached to the payer's payment history rather than becoming an isolated transaction. Where a payer makes relevant repeated payments, recurring payment management works within the wider payment lifecycle — though this is not complete tuition-plan or subscription billing software.
Yes. Outstanding, due and overdue are distinct states of the same obligation, and timing is what tells a team whether an amount is simply still expected or needs a person to look at it. No automated dunning, collection outreach, automated late-fee rules or autonomous payment recovery is claimed.
Yes, and both stay connected to the original payment and the payer. Customer credit is credit recorded and managed within Bonza Payments — not a wallet, a cash balance, stored funds or a bank balance — and refund timing is not promised.
Yes, where Experience Cloud is part of the customer environment. Relevant payment journeys can remain connected to the Salesforce relationship, so the payment a learner or payer makes is the same payment the internal team sees. No student self-service, enrollment, course management or account administration functionality is implied.
Yes. Bonza supports multiple configured gateways, including a configured default and explicit selection where a scenario calls for it, while payment activity stays connected to Salesforce. There is no automatic routing, automatic failover, least-cost routing, gateway optimisation or settlement reconciliation, and provider capabilities are not interchangeable.
Yes, as forward context: relevant expected and recurring payment activity across future periods, and payment-method expiry where it lands before an expected payment. Expected activity is never guaranteed cash, revenue or collection, and expiry context is not a prediction that a payment will fail.
No. Bonza focuses on customer payment management in Salesforce. It is not an SIS, learning management system, admissions or enrollment platform, campus ERP or student accounting system, and it holds no enrollment, course registration, scheduling, attendance, grade or transcript data.
No to both. Tuition calculations, fee structures, installment-plan management, financial aid, scholarship management, student loans, government funding, education grants and sponsorship billing are not claimed capabilities, and no education-specific billing rule is implied anywhere on this page.
No. Bonza is payment management, not accounting. It does not provide a general ledger, revenue recognition, tax accounting, bank reconciliation or settlement reconciliation, and it is not a campus or education ERP.
No. Automatic dunning, automatic student or customer outreach, automated late-fee rules, autonomous payment recovery, debt collection and collections-agency functionality are not claimed capabilities. Bonza surfaces what is due or overdue; a person decides what happens next.
AI payment insights surface relevant changes for a person to review — that payments have moved into overdue status, that relevant payment methods approach expiry, or that upcoming payment activity has changed. There is no student-risk scoring, enrollment-risk or dropout prediction, default prediction, credit scoring, autonomous collections or automatic outreach.
Education
See how Bonza Payments connects one-time and recurring payment activity, receivables, refunds, customer credits, upcoming payments and configured gateways inside Salesforce for education organizations.