- Home
- Industries
- One-Time Payments
One-Time Payments Across Industries
The Payment May Happen Once. The Customer Relationship Doesn't.
Give customers a connected way to complete individual and ad hoc payments while keeping the transaction tied to Salesforce, the customer relationship and the wider Bonza payment lifecycle.
Part of the Salesforce-native Bonza Payments suiteIllustrative one-time payment for one sample customer, Demo Customer, whose Salesforce context is connected. The payment shows an amount of $1,250.00, a relevant payment context and a configured payment option, passing through Bonza Payments to a configured gateway. Payment activity shows $1,250.00 collected on a relevant date, connected payment history, and what may happen next: a refund, a customer credit, a receivable update or a future payment. Every figure on this page is illustrative sample data. The configured gateway performs the underlying payment processing; Bonza manages the wider payment lifecycle, and Salesforce does not process the payment.
One payment event. Connected payment story.
Answer-ready
What Is a One-Time Payment in Bonza Payments?
One-time does not mean disconnected.
A one-time payment is an individual customer payment that does not itself operate on a recurring schedule. Bonza Payments can manage relevant one-time and ad hoc payment activity while keeping it connected with Salesforce customer context. The payment stays tied to the customer, the transaction context and the wider payment lifecycle.
So can Salesforce collect customer payments? A business can collect them in Salesforce, through a Salesforce-native payment application with a configured gateway performing the underlying processing. Salesforce holds the customer context; it does not process the payment itself.
This page is about where those payment requirements appear across different Salesforce-powered businesses and how to structure them. For how the capability itself collects and manages an individual payment, that is a separate page: One-Time & Ad Hoc Payments in the platform.
The real problem
One-Time Payments Are Easy to Underestimate.
It usually starts as "we just need to take a payment." That does sound simple — until the business needs to answer ten more questions about it.
"We just need to take a payment."
One amount, one customer, one transaction. A payment form and a gateway will do it, and for exactly one payment they will.
Ten operational questions a success message doesn't answer
- Who paid?
- What was the payment for?
- How much was collected?
- Which configured gateway handled it?
- What is the payment status?
- Is anything still outstanding?
- What happens if it needs to be refunded?
- Should relevant value become customer credit instead?
- How does this appear in the customer's wider payment history?
- What if the same customer needs to pay again later?
The transaction may be one-time. The operational questions around it are not.
Two models
A Payment Form Solves the Moment. Payment Management Solves What Surrounds It.
The same payment, drawn twice. The difference is where the diagram stops.
The diagram ends at success
What the endpoint does not say: who it was for, what it was for, what the customer position is now, what happens if the value changes later, and where Finance sees it.
The diagram keeps going
Processing answers "did the transaction occur?" Payment management also needs to answer "what does this payment mean for the customer now?"
The distinction
"One-Time" Describes Frequency—not Importance.
A payment can occur once while still being connected to the customer, the account, an invoice or relevant payment obligation, receivables, a refund, a customer credit, the configured gateway that handled it, the customer's payment history and future payment activity. Frequency is a property of the payment. Isolation is a property of the architecture around it — and the second one is a choice.
One-time does not have to mean standalone.
Signature · where one-time payments appear
Different Businesses. Same One-Time Payment Pattern.
Eight business contexts. Select any one and the pattern below does not move — only the context and the list of things Bonza does not do there. Each panel is mostly a denial on purpose: that is how a page can cover eight sectors without inventing a single sector-specific capability.
This row is identical for all eight contexts below, and nothing on this page changes it. The business context changes; the payment pattern does not.
The business context changes. The payment pattern can still be customer → payment need → one-time payment → connected payment activity.
The journey
From Payment Need to Connected Payment Activity.
Select → define → choose → collect → record → manage.
Select customer / context
Identify the relevant customer or Salesforce context.
Define payment
Establish the relevant payment requirement and amount.
Choose payment route
Use the relevant configured payment gateway or option.
Collect
The relevant configured gateway performs the underlying payment processing.
Record & track
Keep payment activity connected through Bonza and Salesforce.
Manage what happens next
Where relevant: payment history, receivables, refund, customer credit, another future payment.
Afterwards
Today's One-Time Payment Can Still Matter Tomorrow.
One-time payments can still have post-payment activity. Depending on the supported use case, relevant payment value may later be managed through a refund or customer credit.
The payment happens
It becomes history
Not an archive — the record the next question gets answered from.
Where relevant
- Refund
- Customer credit
- Another independent payment requirement
- Relevant receivable context
- Future customer payment activity
The payment does not need to recur for the customer payment relationship to continue.
The architecture
Keep the Payment With the Customer Context Salesforce Already Knows.
Bonza Payments does not replace the underlying payment gateway. Configured gateways perform relevant payment processing, while Bonza manages the wider Salesforce payment lifecycle. That is also the answer to whether a payment gateway is needed for Salesforce payments: yes, and Bonza is not one.
Relevant customer and business context
The customer, the account and the business context the organization already maintains. Salesforce does not process the payment.
The payment-management lifecycle
The payment requirement, the payment activity, its status and its history — plus receivables, refunds, customer credits and the wider lifecycle where relevant.
Underlying relevant payment processing
The configured provider that actually processes the transaction. Bonza is not a payment gateway and does not replace one.
The gateway answers a processing question. Bonza answers a payment-management question.
What connects to it
Six Things a One-Time Payment Can Be Connected To.
Use the capabilities that match the payment journey. Not every one-time payment uses every one.
One-Time Payments Don't Have to Be Hard-Wired to One Gateway.
Bonza supports multiple configured payment gateways. A relevant default gateway can be configured, while another configured gateway may be selected where appropriate — so multiple gateways can serve one-time payments.
Make an Individual Payment Clear for the Customer Too.
A one-time payment experience should make the immediate action clear without disconnecting the payment from the customer's wider relationship with the business.
Bring Relevant One-Time Payments Into the Salesforce Customer Experience.
Where the business already uses Salesforce Experience Cloud for a customer-facing journey, Bonza can support relevant connected payment experiences — which is how customers pay through Experience Cloud.
A One-Time Payment Can Still Have a Post-Payment Lifecycle.
The payment happened once. What happens to its value may still need to be managed — which is how a refund after a one-time payment is handled, and how a refund can instead be recorded as customer credit.
Customer credit is recorded and managed within Bonza Payments. Bonza does not store customer money, and there is no Bonza wallet, cash balance or stored-value account.
Explore Refunds & CreditsPayment Collected and Amount Owed Are Not Always the Same Question.
Where receivables are relevant, the payment transaction is only one part of the picture. Bonza's wider suite can provide context around what has been collected and what remains outstanding.
Individual Payments Should Still Contribute to the Operating Picture.
Even when payments happen individually, Finance and Operations may still need an aggregate operational view — collected, outstanding, due, overdue and upcoming, with recent payment activity by customer, amount, payment type, gateway and status.
Choosing the model
One-Time Payment or Recurring Payment?
One-time payments and recurring payments describe different payment patterns. One-time payments occur individually, while recurring payments repeat according to a relevant schedule or arrangement.
Payment does not inherently repeat
Best conceptual fit: individual and ad hoc payment requirements.
Payment activity repeats by arrangement
Best conceptual fit: relevant repeating customer payment activity.
Explore Recurring PaymentsSome organizations need both
- One-time and recurring on the same customer
- Both inside one Bonza payment lifecycle
- Neither becoming the other
Businesses can use both one-time and recurring payment models. Bonza Payments is designed to keep relevant payment activity connected within a wider Salesforce-native payment-management suite.
The question is not which payment model is better. The question is which model matches the payment requirement.
How it escalates
The First One-Time Payment Is Simple. The Tenth Payment Requirement May Not Be.
Eight requests, and what each one actually adds to the architecture.
Take one payment.A payment form and a gateway
Use another gateway.The first one is now hard-wired
Put payment in Experience Cloud.A second customer-facing surface
Show Finance the status.An internal view the form never had
Refund it.A post-payment state to track
Keep value as customer credit.A balance against the customer
Also support recurring payments.A second payment motion
Show what is due and overdue.Timing states, and a payment position
You are no longer solving only a payment-form problem. You are managing a payment lifecycle.
What often goes wrong
Five Mistakes Businesses Make With One-Time Payments.
Treating every payment as an isolated event
Building directly around the first gateway
Stopping at "payment success"
Building a new flow for every one-off requirement
Forgetting the post-payment journey
Before and after
From One-Off Transaction to Connected Payment Event.
One-time payment does not have to mean one-off architecture.
Outcomes
What Connected One-Time Payment Management Is Actually For.
Defensible outcomes only. No figure is promised.
Keep individual payment activity connected to Salesforce.
Avoid treating every relevant one-time requirement as an entirely separate payment operation.
Support relevant configured gateway choices.
Keep payment activity connected with the customer relationship.
Keep refunds and customer credits connected with the original payment story.
Bring individual payment activity into the wider payment operation.
Connect customer-facing payment actions with internal payment context.
Use the same payment-management layer for the next requirement.
Why Bonza Payments
Why Manage One-Time Payments Through Bonza?
Salesforce-native
Keep payment activity connected to relevant Salesforce customer context.
More than one-time
Connect individual payments with the wider payment lifecycle when other capabilities become relevant.
Multiple configured gateways
Avoid making the payment-management experience synonymous with one processing provider.
Customer payment experience
Connect customer-facing payment activity with internal context.
Post-payment management
Keep refunds and customer credits connected.
Receivables visibility
Understand relevant payment position beyond transaction history.
Connected operations
Bring payment activity into the Payment Command Center and wider suite.
Connected suite
One-Time Payments Are One Part of the Bonza Payment Lifecycle.
Use the capabilities that match the payment journey. Not every one-time payment uses every capability.
Use the capabilities that match the payment journey.
FAQ
One-Time Payment Questions.
Twelve answers, including the ones that are a plain no.
What is a one-time payment?
A one-time payment is an individual customer payment that does not itself operate on a recurring schedule. It is collected once, for a relevant payment requirement, rather than repeating according to an arrangement. Being one-time describes the payment's frequency and says nothing about whether the payment record should be isolated from the customer's wider context.
What is the difference between a one-time and recurring payment?
One-time payments and recurring payments describe different payment patterns. One-time payments occur individually, while recurring payments repeat according to a relevant schedule or arrangement. A one-time payment runs payment need → payment → status; a recurring arrangement runs schedule → payment → status → next payment. Neither is better — the question is which matches the payment requirement.
Can I collect one-time payments through Salesforce, and how does Bonza manage them?
Bonza Payments is Salesforce-native, so the payment requirement, the payment activity, its status and its history stay connected to the Salesforce customer record. The journey is select the customer or context, define the payment and amount, choose the relevant configured payment route, collect, record and track, then manage what happens next — payment history, receivables, a refund, customer credit or another future payment where relevant.
Does Bonza process the payment itself, and does it replace Stripe, Razorpay or PayU?
No to both. Bonza Payments does not replace the underlying payment gateway. Configured gateways perform relevant payment processing, while Bonza manages the wider Salesforce payment lifecycle. Provider names are used only as configured-gateway examples and imply no endorsement or partnership. Salesforce does not process the payment either.
Can Bonza work with multiple payment gateways for one-time payments?
Yes. Bonza supports multiple configured payment gateways, with a relevant default that can be configured and another configured gateway selected where appropriate. There is no automatic intelligent routing, least-cost routing, failover, cascading, automatic retries through another gateway, AI gateway selection, authorisation optimisation or universal gateway compatibility.
Can customers make one-time payments through Experience Cloud?
Where the business already uses Salesforce Experience Cloud for a customer-facing journey, Bonza can support relevant connected payment experiences inside that environment, with payment activity flowing back to Bonza and Salesforce. Experience Cloud itself does not process the payment — the configured gateway does.
Can one-time payments remain connected to receivables?
Where receivables are relevant, yes. The payment transaction is only one part of the picture: Bonza's wider suite can provide context around what has been collected and what remains outstanding, including due and overdue states. No partial payment support, payment plans or installment plans are claimed.
What happens if a one-time payment needs to be refunded, and can a refund become customer credit?
A one-time payment can still have a post-payment lifecycle. Depending on the supported use case, relevant payment value may later be managed through a refund via the relevant configured refund process, or recorded as customer credit. Customer credit is recorded and managed within Bonza Payments and is available for relevant future payment use. Bonza does not store customer money — there is no wallet, cash balance or stored-value account, and no instant or guaranteed refund timing is claimed.
Can the same customer make another one-time payment later?
Yes, and that is the point of keeping the first one connected. A second independent payment requirement is simply another one-time payment on the same customer, and because the first is part of the customer's payment history rather than a standalone record, the second arrives with context rather than starting from nothing.
Does one-time payment mean the payment record is standalone?
No — that is the most common misreading. A payment can occur once while still being connected to the customer, the account, an invoice or relevant payment obligation, receivables, a refund, a customer credit, the configured gateway that handled it, payment history and future payment activity. One-time describes frequency, not isolation.
Does Bonza support both one-time and recurring payments?
Yes. Businesses can use both one-time and recurring payment models, and Bonza Payments is designed to keep relevant payment activity connected within a wider Salesforce-native payment-management suite. Both can run on the same customer without either becoming the other.
Does Bonza replace accounting or ERP software?
No. Bonza manages the customer payment lifecycle, not the general ledger or the accounting close. It does not produce accounting entries, revenue recognition, automatic reconciliation, bank reconciliation or settlement reconciliation, and it is not a bank and does not hold customer funds.
One-Time Payments
The Payment May Be One-Time. Your Payment Architecture Shouldn't Have to Be.
See how Bonza Payments can connect individual customer payments with Salesforce, configured gateways and the wider payment lifecycle.