Payment Management

Manage Every Payment. Without Losing Sight of What Happens Next.

Bring payment collection, tracking and customer payment activity into Salesforce, with the visibility to know what’s paid, what’s due, what’s overdue and what needs attention. Bonza Payments is a Salesforce-native payment management suite that connects customer payment activity with relevant Salesforce customer and business context.

Part of the Salesforce-Native Bonza Payments Suite

One customer · one connected payment story Illustrative
Northbank ServicesSalesforce account · customer and business context
Payment expected $10,000 invoiced
Collected$5,500 Outstanding$4,500 Recurring$1,200 / mo Refund$500 returned Customer credit$300 recorded AttentionOverdue · expiry
Bonza Payment Management Configured gateways process the relevant payments beneath this layer

One customer.
Multiple payment events.
One connected payment story.

Definition

What Is Payment Management in Salesforce?

Payment management is the process of managing customer payment activity across collection, status, receivables, recurring payments, refunds, customer credits and relevant future payment activity. It is the work that surrounds the transaction rather than the transaction itself.

Bonza Payments provides a Salesforce-native payment-management layer that keeps customer payment activity connected with relevant Salesforce customer context while configured payment gateways perform the underlying payment processing. Payment management is broader than payment processing. Payment processing handles the transaction, while payment management covers the wider lifecycle around collection, receivables, recurring activity, refunds, customer credits and relevant future payment activity.

Bonza Payments can support one-time and recurring payment management, invoices and receivables, due and overdue visibility, refunds, customer credits, multiple configured gateways, customer payment experiences, forecasting and payment insights. The distinction between the three layers below is what keeps each of those honest.

Layer Salesforce Customer and business context. Who this is, what they buy, who owns the relationship. Salesforce does not process the payment.
Layer Bonza Payments Payment management. The lifecycle around the transaction — what is expected, collected, open, returned, recorded and expected next.
Layer Configured payment gateway Relevant payment processing. Bonza Payments is not positioned as a payment gateway, bank, accounting platform or ERP.

The real problem

Most Payment Problems Begin After the Business Adds More Than One Way to Pay.

Nobody sets out to build a fragmented payment operation. It arrives one reasonable requirement at a time, and each one is solved on its own.

Requirement 01

“We need to take payments.”

Connect one gateway. One integration.

Requirement 02

“We also need recurring payments.”

Build another process. Two places to look.

Requirement 03

“We need invoice payments.”

Add another workflow. Three.

Requirement 04

“Finance needs to know what is overdue.”

Build reporting, or a spreadsheet. Four.

Requirement 05

“We need refunds.”

Create another process. Five.

Requirement 06

“We want customer credits.”

Create another record and process. Six.

Requirement 07

“We need another payment gateway.”

Build another integration. Seven.

Requirement 08

“Customers need to pay through Experience Cloud.”

Build another customer journey. Eight.

Requirement 09

“We need upcoming payment visibility.”

Create another reporting layer. Nine.

The business did not intentionally build a fragmented payment operation. It grew into one, one requirement at a time.

Each of those nine decisions was defensible on the day it was made. What none of them did was ask what the whole payment lifecycle should look like — which is the question this page is about.

Education

Taking Payments and Managing Payments Are Different Problems.

They are often treated as one, because the first is the visible part. The second is where most of the operational work actually sits.

Payment processing

“Can this transaction be processed?”

  • Payment authorization
  • Provider-specific processing
  • Transaction response
  • Provider infrastructure

Usually handled byA configured payment gateway or payment provider

Payment management

“What is happening across the customer’s payment lifecycle?”

  • Payment context, attached to the customer
  • One-time payment activity
  • Recurring activity
  • Invoice and receivable context
  • Due and overdue visibility
  • Refunds, kept against the original payment
  • Customer credits, recorded and available
  • Customer payment experience
  • Relevant upcoming payments
  • Operational visibility and attention signals

Managed throughBonza Payments

A gateway processes a payment. Payment management connects that payment to what happened before, what is true now and what may happen next.

Explore the Payment Lifecycle

The lifecycle around the event

A Payment Transaction Is an Event. Payment Management Is the Lifecycle Around It.

The transaction is the middle column. Three quarters of what a team needs to know sits either side of it.

Phase 01

Before payment

  • Invoice or payment obligation
  • Outstanding amount
  • Recurring schedule
  • Customer context from Salesforce

Something is expected. Nothing has moved yet.

Phase 02

Payment moment

  • Customer payment experience
  • Configured gateway performs the processing
  • Payment activity recorded against the customer

The part most systems treat as the whole thing.

Phase 03

After payment

  • Collected position
  • Remaining receivable
  • Refund, where value is returned
  • Customer credit, where value is recorded
  • History that reads as one sequence

A successful transaction does not tell you the whole payment story.

Phase 04

What comes next

  • Next recurring payment
  • Upcoming payment activity
  • Payment method expiry
  • Payment forecast
  • What deserves attention

The phase reporting on history never reaches.

If you only manage the transaction, you lose the context around the transaction.

One customer, many moments

One Customer Can Have Many Different Payment Moments.

Walk one illustrative customer through twelve payment moments. The position is shown at every one, and it reconciles at every one — which is the whole point of managing the lifecycle rather than the transactions.

12 payment moments · one customer · the position reconciles at 12 of 12 · recorded credit counted as collected cash: 0 times

All amounts and dates on this page are illustrative and do not represent real customer data.

The customer has one relationship with your business. The payment history should not read like twelve unrelated transactions.

The payment management model

One Payment Management Layer Across the Customer Lifecycle.

Four layers. Every connected Bonza capability sits in exactly one of them, and each has its own page — this page connects them rather than replacing them.

14 connected capabilities across 4 layers · each sits in one layer only · 14 with a page of its own · 0 described here in place of that page

Every capability solves a different payment problem. Payment management connects them into one lifecycle.

From history to forward visibility

Good Payment Management Should Explain More Than What Already Happened.

Most payment reporting stops at the first column. The same connected data supports all four.

Past tells you what happened. Present tells you where you stand. Future tells you what may be coming next.

Both paths

Payment Management Is Not Only About the Happy Path.

Most payments follow the first chain. The operation is judged on how well it handles the other two.

Normal flow

Payment expected Payment Collected Next payment

Nothing needed a person. The value of managing it is that the record stays attached to the customer, so the next question about them already has an answer.

Attention flow

Payment expected Due Overdue, or another relevant signal Attention Human review Relevant next step

The chain ends at a person deciding, not at an automated action. Nothing here contacts the customer on its own, chases an overdue balance or decides what the next step should be.

Post-payment flow

Collected Change required Refund or customer credit Updated payment position

A refund or credit should not become an unrelated financial event. It belongs to the same customer payment story, and it changes the position rather than ending it.

A complete payment management model has to explain the normal payment flow and the exceptions around it.

Operational view

The Operational View Over the Connected Payment Layer.

Payment management is the connected capability layer. The Payment Command Center is the operational view across that layer — not the product itself.

Bonza PaymentsPayment Command Center Illustrative figures
Total collected$412,800This quarter
Outstanding$128,400Across 86 customers
Due$41,200Next 14 days
Overdue$36,900Date has passed
Upcoming$74,600Expected, not guaranteed

Payment forecast Expected activity by week

Wk 40$18,400
Wk 41$23,100
Wk 42$16,000
Wk 43$17,100

Solid bars are scheduled activity. Dashed bars are expected activity. Neither is guaranteed collection, and neither is a cash-flow or treasury forecast.

Receivables position

Not yet due · $50,300 Due · $41,200 Overdue · $36,900

$128,400 outstanding in total. Outstanding describes unresolved value; due and overdue add timing to it.

Recent payment activity

Recent illustrative payment activity by customer, type, amount and status
CustomerTypeAmountStatus
Northbank ServicesInvoice$6,000Overdue
Harlow InstituteRecurring$1,200
Verity PartnersOne-time$3,450
Northbank ServicesRefund$500Returned
Calder GroupInvoice$8,900Due
Harlow InstituteRecurring$1,200Scheduled

Payments requiring attention

Overdue with recorded credit availableNorthbank Services · $4,500 overdue, $300 credit recorded
Payment method expires before next paymentHarlow Institute · expiry 31 Oct, next expected 15 Nov
Part-paid invoice past its due dateCalder Group · $8,900 open of $12,000 invoiced

Each item is surfaced with the context behind it. The decision stays with a person; nothing here acts on the customer.

All figures in this view are illustrative and do not represent real customer data.

Explore the Payment Command Center

Architecture

Where Bonza Fits in the Payment Architecture.

The same architecture, read three ways. The boundary between the layers does not move whichever way you read it.

Layer 01 Customer and business context Salesforce: the customer, the account, the relevant business process, and Experience Cloud where it applies. Does not process the payment.
Layer 02 Payment management Bonza Payments: one-time, recurring, invoices, receivables, due and overdue, refunds, credits, customer payment experience, forecasting and insights. Not a gateway, not a bank, and does not hold customer money.
Layer 03 Payment processing Configured payment gateways — for example Stripe, Razorpay or PayU, named only as examples of configured options. No smart routing, failover or least-cost routing is performed above them.
Layer 04 Payment operations The Payment Command Center: collected, outstanding, due, overdue, upcoming and attention. An operational view over the layer, not the product itself.

Salesforce provides context. Bonza manages the payment lifecycle. Configured gateways process relevant payments. The Command Center provides the operational view.

Where each one fits

Payment Gateway vs Payment Management vs Accounting System.

Three different jobs that are often expected of one tool. Bonza does one of them.

A neutral comparison of three distinct roles in a payment operation.
RolePrimary jobThe question it answers
Payment gateway Process relevant transactions. “Can this payment be processed?”
Bonza payment management Manage the customer payment lifecycle in Salesforce. “What is happening across this customer’s payment activity?”
Accounting system or ERP Broader accounting and financial record-keeping processes. “How is this represented within the organisation’s accounting process?”

Bonza does not replace an accounting system or ERP, and does not perform general ledger accounting, revenue recognition, tax accounting or bank reconciliation.

What goes wrong

Seven Ways Payment Operations Become Fragmented.

None of these is careless. Each is a reasonable decision that becomes expensive once the next requirement arrives.

  1. Building the business process around the first gateway

    The gateway that happened to be first ends up defining how the business thinks about payments. Better: keep gateway processing beneath a wider payment-management layer, so changing or adding one is a configuration question rather than a redesign.

  2. Treating every payment type as a different system

    One-time, recurring and invoice-driven payments get their own process, their own reporting and their own gaps. Better: connect them, while keeping them distinct capabilities rather than pretending they are the same thing.

  3. Tracking only successful transactions

    A transaction log answers what arrived and nothing else. Better: understand collected, outstanding, due and overdue as four different facts that can all be true at once.

  4. Treating refunds as the end of the story

    The refund is recorded somewhere else, and the customer’s position quietly stops adding up. Better: keep post-payment changes connected to the original payment and to the position they change.

  5. Managing customer credit outside the payment lifecycle

    Credit lives in a note, a spreadsheet or someone’s memory, and is found only when a customer mentions it. Better: connect recorded credit with the future payment context where it will actually be used.

  6. Reporting only on history

    Every report looks backwards, so the first sign of a problem is that it already happened. Better: add relevant forward payment visibility, while being clear that expected activity is expected rather than guaranteed.

  7. Building customer and internal payment experiences separately

    What the customer did and what the team can see are assembled from different places. Better: keep both sides connected to the same payment lifecycle, so one explains the other.

The hidden cost

The Hidden Cost Is Reconstructing the Payment Story.

The cost of fragmentation is rarely a failed payment. It is the twenty minutes it takes to answer one ordinary question.

Fragmented

“What is happening with this customer’s payments?”

  • 01Check Salesforce
  • 02Check the gateway
  • 03Check the invoice
  • 04Check the spreadsheet
  • 05Check the recurring process
  • 06Check refunds
  • 07Check customer credit
  • 08Check future payments
  • 09Manually reconstruct the answer

Connected

“What is happening with this customer’s payments?”

  • 01Customer
  • 02Salesforce customer context
  • 03Bonza payment management
  • 04Connected payment lifecycle
  • 05Current position, history and forward context

If users have to reconstruct the payment story every time they need an answer, the payment operation is still fragmented.

How it develops

How Payment Collection Becomes Payment Management.

Five things an organisation can say about its payment operation. They tend to arrive in this order.

Level 01

Transaction

“We can take a payment.”

The payment works. What it meant is elsewhere.

Level 02

Visibility

“We can see what happened.”

There is a record, and someone can find it.

Level 03

Connected lifecycle

“We can see the payment in customer and receivables context.”

The payment, the customer and what is still open are one view.

Level 04

Forward visibility

“We can see what is expected next.”

Expected activity is visible before its date arrives.

Level 05

Attention-driven

“We can identify what may need review.”

Signals are surfaced with context, for a person to judge.

This is not a score and not a ranking. No organisation is graded against it, nothing here says a business at level two is behind, and there is no requirement to reach level five — plenty of payment operations are complete at level three because that is all their payment model needs.

By role

One Payment Lifecycle. Different Operational Questions.

Five teams, five sets of questions, one underlying payment story. The questions differ; the answer should not have to be assembled twice.

Finance & AR

  • What has been collected?
  • What is outstanding?
  • What is due?
  • What is overdue?
  • What is expected next?
Finance & Accounts Receivable

Revenue operations

  • What happened after the commercial event?
  • What was collected?
  • What remains open?
  • What comes next?
Revenue Operations

Business operations

  • What happened?
  • What is open?
  • What is next?
  • What needs attention?
Consolidate Payment Operations

Customer service

  • What happened to this customer’s payment?
  • Was anything refunded?
  • Does relevant customer credit exist?
  • What is the current payment context?
Customer Service

Salesforce teams

  • How do payment capabilities stay reusable rather than becoming another custom integration for every requirement?
Salesforce Teams

Everyone at once

  • Different teams ask different questions. Should the underlying payment story change depending on who is asking?
Improve Receivables Visibility

Different teams ask different questions. The underlying payment story should stay connected.

In practice

Where Connected Payment Management Matters.

Eight ordinary situations, and what staying connected actually changes about each.

01

A customer needs to make an individual payment.

One-Time & Ad Hoc Payments

The payment stays connected with Salesforce customer and payment context rather than existing only as a gateway transaction.

02

Customer payments repeat.

Recurring Payments

Current and relevant future payment activity stay connected, so the schedule is not a separate operation.

Recurring payment management is not full subscription billing.

03

A customer has paid only part of what was expected.

Receivables

Collected and outstanding positions both stay understandable, instead of a successful payment hiding an open balance.

This is about visibility of the position. It is not a claim about partial-payment processing itself.

04

A payment becomes overdue.

Due & Overdue Payments

The relevant payment can be surfaced for attention with the context behind it.

Nothing contacts the customer automatically.

05

A collected payment later changes.

RefundsCredit Management

Post-payment activity stays part of customer payment history rather than becoming an unrelated financial event.

Refund timing depends on the configured gateway and the customer’s provider.

06

The business uses more than one configured gateway.

Multiple Payment Gateways

Gateway choice sits inside the wider payment-management model instead of defining it.

Gateways are configured and selected. There is no smart routing, failover or automatic retry through another gateway.

07

A customer pays through Salesforce Experience Cloud.

Experience Cloud Payments

The customer payment journey stays connected to relevant Salesforce context on both sides.

Experience Cloud is the customer-facing environment; it does not itself process the payment.

08

Finance wants to understand upcoming payment activity.

Payment Forecasting

Relevant expected payments become visible before their dates arrive.

Expected activity is not guaranteed collection, and this is not treasury, cash-flow or bank-balance forecasting.

See Payment Management in Salesforce

Industry relevance

Payment Management for Salesforce-Powered Customer Relationships.

The payment model comes first. The industry decides which parts of it matter, not what Bonza claims to be.

Financial & professional servicesKeep client payment activity connected with the relationship behind it.
EducationManage relevant customer and payer payment activity without positioning Bonza as a student information or tuition-management system.
HealthcareConnect relevant customer payment activity without positioning Bonza as medical billing, claims or patient accounting.
Technology & SaaSConnect one-time and recurring payment activity without positioning Bonza as full subscription billing.
Membership & associationsConnect relevant recurring and other payment activity without positioning Bonza as membership-management software.
Real estate & propertyConnect relevant customer payment activity without positioning Bonza as property-management or real-estate accounting software.
NonprofitsConnect relevant supporter and customer payment activity without positioning Bonza as fundraising or donor-management software.
Other Salesforce-powered businessesStart with the payment model rather than forcing the business into an industry template.

Explore Industries

What changes

What Connected Payment Management Changes Operationally.

Eleven things that are different once the lifecycle is connected. All of them are about visibility and continuity, because those are the things that can be stated honestly.

More connected payment visibility

Clearer customer payment context

One-time and recurring payment continuity

Better visibility into outstanding, due and overdue activity

Connected refund and credit context

Forward visibility into relevant upcoming payment activity

Multiple configured gateway flexibility

Clearer customer payment journeys

Less manual payment-story reconstruction

More useful operational attention signals

Connected payment visibility across relevant teams

What is deliberately not on that list: a percentage improvement in collections, a reduction in days sales outstanding, a revenue or retention increase, an authorization or payment-success uplift, headcount or cost savings, or a return-on-investment figure.

Those depend on your customers, your terms and how your team works, none of which a product page can know. Connected visibility is what Bonza provides; what an organisation does with it is what produces a result.

Why Bonza

Why Bonza Payments for Salesforce Payment Management?

Eight reasons, each one a boundary as much as a capability.

01

Salesforce-native payment management

Payment activity stays connected with relevant Salesforce customer and business context, rather than beside it.

02

More than payment processing

Bonza addresses the lifecycle around the transaction. The transaction itself is the gateway’s job.

03

Multiple payment models

One-time, ad hoc, recurring, invoice-related and receivables activity in one connected model.

04

Post-payment continuity

Refunds and customer credits stay connected with the payment story instead of ending it.

05

Multi-gateway flexibility

Configured gateways sit beneath one payment-management layer. Selection is configured, not automated.

06

Customer and internal experience

What the customer does and what the team sees stay connected to the same lifecycle.

07

Forward payment visibility

Upcoming activity, forecasting and payment-method timing extend visibility past transaction history.

08

Payment intelligence

Bonza AI Payment Insights support human review and payment decision-making rather than autonomous financial action.

Bonza is not trying to become the gateway, the bank or the accounting system. It is the Salesforce-native payment management layer that connects the customer payment lifecycle.

The suite

One Suite Across the Payment Lifecycle.

Fourteen capabilities in four groups. Payment Management is the foundation they connect through.

Salesforce-Native Payment Management Suite

Questions

Payment Management, Answered.

What is payment management in Salesforce?

Payment management is the process of managing customer payment activity across collection, status, receivables, recurring payments, refunds, customer credits and relevant future payment activity. In Salesforce, it means keeping that activity connected to the customer record that explains who the payer is, rather than holding it in a gateway dashboard or a spreadsheet beside Salesforce.

How is payment management different from a payment gateway?

A gateway answers one question: can this transaction be processed? Payment management answers a different one: what is happening across this customer’s payment activity? The gateway handles authorization, provider-specific processing and the transaction response. Payment management handles what the payment was for, what remains open, what was returned, what is recorded and what is expected next.

Does Bonza Payments process payments itself?

No. Configured payment gateways perform the relevant payment processing. Bonza is the Salesforce-native payment-management layer above them, and is not positioned as a payment gateway, a bank, an acquirer, an accounting platform or an ERP. Bonza does not hold customer money.

Can Bonza manage one-time payments?

Yes. One-time and ad hoc payment scenarios are supported, and the resulting activity stays connected with the Salesforce customer and with the wider payment lifecycle rather than existing only as a standalone transaction.

Can Bonza manage recurring payments?

Yes. Recurring payment management covers what has been collected, what is current, what is expected next and what may need attention. It is not full subscription billing: there are no pricing plans, usage or metered billing, proration or product catalogs.

Can Bonza show outstanding, due and overdue payments?

Yes, and the distinction between the three matters. Outstanding describes unresolved value regardless of timing. Due means the relevant date has arrived. Overdue means it has passed. Attention adds operational priority on top. An amount can be outstanding without being due, and the amount does not change when the timing does.

Can Bonza manage refunds and customer credits?

Yes, and both stay attached to the payment story. A refund remains connected to the customer, the original payment, the relevant history and the updated position. Customer credit is recorded and managed within Bonza for supported future payment use. Refund timing depends on the configured gateway and the customer’s own provider, so no instant, same-day or guaranteed timing is promised.

Can Bonza work with multiple payment gateways?

Yes. Bonza can support multiple configured payment gateways, including examples such as Stripe, Razorpay and PayU, without positioning gateway selection as autonomous smart routing. Businesses configure the gateways they use and select a relevant default or another configured option where supported. Those names are examples of configured options and imply no partnership.

Does Bonza automatically choose the best payment gateway?

No. There is no smart routing, no least-cost routing, no automatic failover, no cascading and no automatic retry through another gateway. Gateway selection is configured by the business. What Bonza provides is one payment-management experience regardless of which configured gateway performed the processing.

Can customers make payments through Salesforce Experience Cloud?

Relevant payment journeys can operate through Salesforce Experience Cloud. Experience Cloud provides the customer-facing Salesforce environment, Bonza provides the payment-management capability, and a configured gateway performs the processing. Salesforce itself does not process the payment, and Bonza does not provide identity management or the entire portal.

Can Bonza show upcoming payment activity?

Yes. Bonza Payment Forecasting focuses on relevant upcoming customer payment activity rather than treasury or bank-balance forecasting. Expected, scheduled and upcoming activity become visible before their dates. Expected activity is not guaranteed collection, and it is not described as certain or committed cash.

Does Bonza automatically chase overdue customers?

No. Overdue payments can be surfaced for attention with the context behind them, and the next step is a person’s decision. There is no automatic dunning, no autonomous collections and no automatic customer outreach.

What is the Bonza Payment Command Center?

It is the operational view across the connected payment layer — collected, outstanding, due, overdue, upcoming activity and what needs attention, in one place. It is a view over payment management rather than the product itself: the capabilities it reads from are what actually manage the lifecycle.

How does AI Payment Insights support payment management?

Bonza AI Payment Insights support human review and payment decision-making rather than autonomous financial action. Payment activity, customer context, receivables, due and overdue state, recurring activity, upcoming payments and payment-method timing are used to surface a signal with its context and a priority. The decision stays with a person. Nothing scores customers, predicts default, approves refunds or creates credits on its own.

Is Bonza an accounting or ERP system?

No. Bonza does not perform general ledger accounting, revenue recognition, tax accounting, bank reconciliation or universal settlement reconciliation, and it does not replace an accounting system or ERP. Receivables in Bonza are about the visibility of the customer payment position, not about how that position is represented in an organisation’s accounting process.

Is recurring payment management the same as subscription billing?

No. Recurring payment management covers payments that repeat on a schedule and the operational context around them. Full subscription billing adds pricing plans, product catalogs, usage and metered billing, proration and plan changes, none of which Bonza is positioned as providing.

Does a payment method expiring mean the next payment will fail?

No. Payment Method Expiry is a timing signal: it shows that a stored method expires before an expected payment date, while there is still time to do something about it. It does not predict failure, it does not update cards automatically, and it does not contact anyone automatically.

One payment story

Your Customer Has One Payment Story. Manage It That Way.

See how Bonza Payments connects collection, recurring activity, receivables, due and overdue payments, refunds, customer credits, configured gateways and forward payment visibility through one Salesforce-native payment-management suite.

Payment expected·Collect·Track·Manage·Anticipate·Next payment