What to Understand About Payments in Salesforce Before You Build Another Payment Process.

Managing the customer payment lifecycle inside Salesforce rather than only processing transactions outside it. It covers what a customer was expected to pay, what was collected, what remains outstanding, what is due or overdue, what changed through a refund or recorded credit, and what payment activity is expected next — all connected to the Salesforce customer record the payment belongs to. Processing itself stays with the configured payment gateway.

Attached to the customer, not to whichever record was open when the first requirement arrived. A common pattern is a custom object built beside the Opportunity for the first payment type; the difficulty appears with the second type, because a recurring payment is not an invoice line and a refund is not a negative payment. Modelling the lifecycle around the customer means later payment types extend the model rather than requiring a new one.

A payment status describes what happened to one transaction. A customer payment position describes where that customer stands across the relevant payment lifecycle — whether an amount remains open, whether it is due or overdue, whether value was later refunded or recorded as credit, and whether further activity is expected. A payment can be collected while the customer is still unsettled, and the status alone does not say so.

The question matters less than whether they stay attached to the payment they came from. Refunds and recorded credits are post-payment changes to the same customer payment story; when they become unrelated records elsewhere, nobody can answer what the customer actually owes without rebuilding the history by hand. Recorded customer credit is value retained for supported future payment use — not stored cash, not a bank balance and not a wallet.

As three distinct states rather than one balance with a date filter. An amount is outstanding while it is still open, becomes due when its date arrives, and becomes overdue only once that date has passed. Nothing about the amount changes between those states — only the calendar does — and that distinction is precisely what tells a finance or operations team whether anyone needs to act today.

Yes, and the design question is whether payment management sits above the gateway layer or inside it. Bonza supports multiple configured payment gateways, including a default or another configured gateway where relevant, with the business deciding which applies. Bonza does not perform smart routing, least-cost routing, automatic failover, cross-gateway retry or success-rate optimization, and claims no universal gateway support.

No, and conflating them oversizes the build. Recurring payment management covers a payment that repeats on a schedule, with the history behind it and the activity expected next. Full subscription billing adds usage billing, metering, proration and product catalogs, none of which Bonza provides. If the requirement is genuinely metered or usage-based billing, that is a different system.

No. Seeing what a customer still owes within the payment lifecycle is not a general ledger. Bonza is not an accounting system, an ERP or a treasury platform, and performs no bank or universal settlement reconciliation. Treating payment visibility as accounting usually leads teams either to overbuild or to abandon the visibility they actually needed.

Yes, and the reason to do so is that the customer-facing journey and the internal payment context then describe the same event. Experience Cloud is the customer-facing environment; it does not itself process the payment, which remains the configured gateway's role. Where the relationship already lives in Salesforce, keeping the payment experience connected to it means service and finance are not answering questions from a system the customer never saw.

Forward visibility into relevant expected customer payment activity — upcoming and recurring payments, and payment-method timing read against the next expected payment. It is not cash-flow, treasury, revenue, liquidity or bank-balance forecasting, and expected payment activity is not guaranteed collection. The design point is that this is a modelling decision rather than a report built after the fact.

To narrow the work, then hand it to a person. Bonza AI Payment Insights observes payment activity against its customer context, surfaces situations that may deserve review, explains them and prioritises them. It does not collect payments, contact customers, approve refunds, create customer credit, select gateways, write off receivables, change recurring schedules, or predict default or payment failure. Financial decisions stay with people.

No. No guide, ebook or PDF has been published on this site, so there is no download, no gated form, no author, no publication date and no page count anywhere on this page. The guidance is simply written out here instead. If long-form guides are published later they will appear in the Guides & eBooks library.