01
Collect
Initiate individual customer payments when the business needs them, including payment situations that sit outside a recurring schedule.
One-time & ad hoc payments
Collect Any Payment. Keep Every Payment Connected.
Collect one-time and ad hoc customer payments while keeping payment activity connected to Salesforce, customer records and your wider payment lifecycle.
Part of the Salesforce-native Bonza Payments suiteIllustrative Bonza Payments interface inside Salesforce. A one-time payment is being collected from Acme Customer for $2,500, related to invoice INV-2044, through the configured gateway and an available card payment method, with a status of Ready to collect. Alongside it, the resulting payment record appears in that customer's Salesforce payment history: payment PAY-10731 for $2,500, recorded against the customer and the related invoice, sitting after an earlier invoice raised and before ongoing recurring payment activity.
Definition
What Are One-Time and Ad Hoc Payments?
One-time and ad hoc payments are individual customer payments collected outside a recurring payment schedule. Bonza Payments enables businesses to manage these payments within their Salesforce payment operation.
They cover the payments that don't fit a billing cycle: an outstanding balance, an additional charge or service fee, a customer-requested payment, an invoice-related collection, or an exceptional amount that falls outside the normal automated process.
The capability is not simply taking the transaction. It is collecting an individual payment while keeping the transaction, the customer context, the payment status and the downstream payment activity connected.
Bonza Payments is a Salesforce-native payment management suite, and one-time and ad hoc payments are one capability within it. Bonza is not a payment gateway, a payment link tool or a checkout widget — the configured gateway processes the payment, and Bonza manages the payment experience and lifecycle inside Salesforce.
Why it gets hard
Taking the Payment Is Easy. Managing What Happens Around It Is Harder.
A one-time payment can be collected successfully and still become a disconnected operational event. The transaction completes; the context doesn't follow it.
Traditional approach
The payment lands somewhere else
The transaction succeeds in the gateway. Everything after it is assembled by hand, in whatever order someone remembers.
CustomerSalesforce
Payment requestAd hoc
GatewayOutside Salesforce
Manual status checkBy hand
Spreadsheet / separate recordBy hand
Salesforce updateBy hand
Each hand-off is a place where the payment and its context can drift apart — and where the answer to "what did this customer pay, and for what?" has to be rebuilt.
With Bonza Payments
The payment stays where the customer is
The gateway still processes the transaction. What changes is that the payment is created, recorded and managed from within the Salesforce customer context.
CustomerSalesforce
PaymentBonza
Configured gatewayProcessing
Salesforce customer contextConnected
Payment status
Payment history
Invoice / receivable
Refund
Customer credit
Reporting & visibility
One record, several places it remains reachable from. Nothing here removes the gateway — it removes the re-typing.
A payment may be collected without difficulty and still leave teams asking which customer or account it belongs to, why it was collected, whether an outstanding amount remains, which gateway processed it, whether it relates to an invoice, whether a refund or customer credit is later required, and how it affects the customer's payment history. Those questions are the actual work.
The approach
One-Time Payments Without One-Off Processes.
The payment itself is ad hoc. The process around it shouldn't be — the same four things should happen whichever situation produced it.
02
Connect
Keep the payment associated with the relevant Salesforce customer or account and the business context that produced it.
03
Track
Maintain visibility into the payment and its status as part of the wider payment operation rather than as a one-off lookup.
04
Continue
The transaction doesn't become a dead-end record. Where applicable it stays connected to the rest of the suite.
One-time doesn't mean one use case
Five Situations. The Same Connected Payment.
Pick a situation on the left. The collect-payment view, the resulting record and what the payment stays connected to all change with it — because the difference between these situations is context, not process.
What this payment stays connected to
All customers, amounts, payment references and invoice numbers shown are illustrative sample values, not real customer data.
The flow
From Payment Request to Payment Record.
Six steps, the last of which is the one most ad hoc payment processes never reach.
1Select customerIdentify the Salesforce customer or account the payment belongs to.
2Define paymentEnter the relevant payment information, including a related invoice where applicable.
3Choose payment routeUse the configured payment experience or gateway where applicable.
4Collect paymentThe individual payment is processed through the configured gateway.
5Record & trackPayment information stays connected to Salesforce and the customer.
6Manage what happens nextTrack status and connect downstream activity such as receivables, refunds or credits where applicable.
Use cases
Where Ad Hoc Collection Actually Shows Up.
Outstanding balance
SituationA customer has an amount that needs to be collected outside a normal recurring payment schedule.
PaymentAn individual payment is collected against that customer and, where applicable, the related invoice.
VisibilityThe outstanding position updates in the customer's payment context rather than in a side record.
Additional service or fee
SituationA customer needs to make an individual payment for an additional charge or service fee.
PaymentThe charge is collected as a one-time payment with the reason recorded alongside it.
VisibilityThe payment remains associated with the customer, so later questions about it have an answer.
Customer-initiated payment
SituationA customer needs a way to make an individual payment themselves.
PaymentThe payment is made through the available customer payment experience.
VisibilityThe resulting payment lands in the same Salesforce customer payment history as any other.
Invoice-related collection
SituationA payment needs to be collected in relation to an invoice.
PaymentWhere applicable, the payment is collected with the relevant invoice associated to it.
VisibilityPayment and invoice stay readable together through the payment lifecycle.
Exceptional payment
SituationA business needs to collect an amount that does not belong to its normal automated or recurring payment process.
PaymentThe exception is collected through the same structured payment-management process as everything else.
VisibilityThe exception is recorded rather than remembered.
Partial payment toward a larger amount
SituationA customer pays part of what is owed rather than the full amount.
PaymentThe individual payment is collected and recorded against the customer.
VisibilityWhat was collected and what remains outstanding are read from the same receivables context.
Multi-gateway
One Payment Experience. More Gateway Flexibility.
Bonza Payments supports multiple payment gateways. Businesses can connect different gateways and configure a default or preferred one while keeping flexibility around how payments are processed.
Architecture. A customer or Salesforce user initiates a payment. Bonza Payments manages the payment experience within Salesforce and routes the transaction to one of the configured payment gateways, such as Gateway A, Gateway B or Gateway C. The gateway processes the payment. The resulting payment record is kept in Salesforce against the customer.
The gateway processes the payment.
Bonza manages the payment experience and lifecycle in Salesforce. Gateways commonly discussed in this context include Stripe, Razorpay, PayU and other configured providers. Naming them does not imply partnership or endorsement, and capabilities can differ between providers.
Bonza manages the payment experience and lifecycle in Salesforce. Gateways commonly discussed in this context include Stripe, Razorpay, PayU and other configured providers. Naming them does not imply partnership or endorsement, and capabilities can differ between providers.
Customer context
A Payment Shouldn't Become an Isolated Transaction.
The same $2,500 means something different inside a gateway portal than it does beside the account, the invoice and what happens afterwards.
Acme Customer
Account
ILLUSTRATIVE
Illustrative customer payment timeline for Acme Customer. Account information is recorded in Salesforce. Invoice INV-2044 for $2,500 is raised on 04 September. A one-time payment of $2,500 is collected today and recorded as payment PAY-10731. Its payment status is collected, processed through the configured gateway. Where required, a refund or customer credit can follow against that payment. Future payment activity, including a recurring payment of $5,000 expected on 01 October, continues in the same history.
Payment information becomes more useful when it is read in the context of the customer relationship rather than only inside a gateway portal. That is the whole argument for collecting the ad hoc payment where the customer already lives.
The wider suite
One-Time Payments Are Only One Part of the Journey.
Each of these is its own capability. What matters here is that an ad hoc payment can reach them.
Payment ManagementThe wider payment operation this capability sits inside.Explore
Recurring PaymentsThe scheduled payment activity an ad hoc payment sits outside of.Explore
InvoicesWhere a one-time payment relates to an invoice.Explore
ReceivablesWhat was collected, and what remains outstanding.Explore
CreditsCustomer credit recorded within the payment relationship.Explore
RefundsWhere collected value later needs to be returned.Explore
Multiple Payment GatewaysThe configured providers that process the transaction.Explore
Payment Command CenterWhere individual payments appear in the operating view.Explore
Payment IntelligenceRelevant changes in payment activity, surfaced with context.Explore
Business outcomes
What a Connected Ad Hoc Payment Gives You.
Understand individual payment activity in the context of Salesforce.
Reduce reliance on disconnected payment records and manual status checking.
Handle individual payments through a structured payment-management process.
Keep payment activity connected to the customer relationship.
Support payment scenarios that fall outside recurring or standard billing cycles.
These are operational outcomes. No claim is made here about percentage improvements, processing speed, cost reduction or collection rates.
Why Bonza
Why Manage One-Time Payments with Bonza?
Payment management lives within the Salesforce environment rather than operating as an isolated payment application beside it.
One-time payments connect with broader payment-management capabilities instead of standing alone.
Support multiple configured payment gateways rather than designing the whole payment operation around one provider.
Connect payment activity with Salesforce customer information, so a transaction carries its reason with it.
Continue managing the lifecycle through payment tracking, receivables, refunds, credits and payment visibility where applicable.
The payments that don't fit the billing cycle get the same structured process as the ones that do.
FAQ
One-Time and Ad Hoc Payments, Answered.
What is an ad hoc payment?
An ad hoc payment is an individual customer payment collected outside a recurring or standard billing schedule. It covers situations such as an outstanding balance, an additional charge or service fee, a customer-requested payment, an invoice-related collection or an exceptional amount that falls outside the normal automated process.
What is the difference between a one-time payment and a recurring payment?
A one-time payment is an individual payment collected when the business needs it. A recurring payment is part of an ongoing scheduled payment arrangement. Both are managed within Bonza Payments, and both appear in the same customer payment history — the difference is whether the payment belongs to a schedule.
Can Bonza Payments manage one-time payments in Salesforce?
Yes. One-time and ad hoc payment collection is a capability within the Salesforce-native Bonza Payments suite, so the payment is created, recorded and managed inside Salesforce rather than only in a gateway dashboard.
Can a one-time payment be associated with a Salesforce customer?
Yes. The payment is associated with the relevant Salesforce customer or account, which is what allows the payment, its status and its downstream activity to be read as part of that customer's payment history.
Does Bonza Payments support multiple payment gateways?
Yes. Multiple payment gateways can be connected and a default or preferred gateway configured, while retaining flexibility around how payments are processed. Bonza is not itself the gateway — the configured provider processes the transaction, and capabilities can differ between providers.
Can customers make one-time payments through a customer-facing experience?
Where the customer payment experience is configured, a customer can make an individual payment through the available payment journey, and the resulting payment is recorded in the same Salesforce customer payment context as any other.
How are one-time payments tracked?
Each payment becomes a record associated with the customer, carrying its amount, its status and the context it was collected in. That record is what makes the payment visible as part of the wider payment operation rather than something to look up in a separate system.
Can one-time payments be connected with invoices or receivables?
Where applicable, a one-time payment can be collected in relation to an invoice, and the payment activity forms part of the receivables picture for that customer. This is operational payment visibility, not accounting treatment — general ledger posting, revenue recognition and bank reconciliation remain with your accounting or ERP platform.
What happens if a one-time payment needs to be refunded?
Where a change is required later, refund activity connects back to the original payment rather than becoming a separate event. Refund capability and timing depend on the configured payment gateway and the financial institution involved.
Can customer credits be used as part of the wider payment lifecycle?
Customer credit is recorded and managed within the customer payment relationship in Bonza and can be available toward a relevant future payment where supported. It is a credit record, not held customer funds, and it is not applied automatically.
How do one-time payments appear in payment reporting or the Payment Command Center?
Individual payments appear alongside the rest of the payment operation in the Payment Command Center, so ad hoc collection is visible in the same operating view as recurring activity, receivables and post-payment events rather than sitting outside it.
Is Bonza Payments a payment gateway?
No. Bonza Payments is a Salesforce-native payment management suite. The configured payment gateway processes the transaction; Bonza manages the payment experience and the payment lifecycle within Salesforce. It is not a gateway, a payment link tool, a checkout widget or a standalone card-payment application.
Need to Collect Payments That Don't Fit the Standard Billing Cycle?
See how Bonza Payments helps you collect one-time and ad hoc payments while keeping every transaction connected to your Salesforce payment operation.