Reference Material for Money That Repeats.

A subscription is a commercial arrangement: a customer has access to something for a period, and a billing system decides what to charge for it. A recurring payment is the money obligation that results: an amount expected on a date, which may or may not be collected. One business can have subscriptions without recurring payments, if the customer pays a year up front, and recurring payments without subscriptions, such as an instalment plan on an existing balance. Bonza Payments manages the recurring payment, not the subscription.

They share a shape and differ in a way that matters. A payment plan splits an amount that is already owed into instalments, so it has a known total and a known end from the first day. An ongoing arrangement has neither. The practical consequence is that “how much is left?” is a real question for a plan and a meaningless one for an open-ended arrangement, which is why decision six on this page asks whether they should be modelled the same way.

Because it is the state that most payment setups cannot describe. A gateway reports that a transaction succeeded, which is true, and the customer is still not settled, which is also true. If the system records only the transaction result, those two facts cannot both be held, and the shortfall stops being visible. Recurrence makes this worse rather than better, because the next cycle arrives before anyone has noticed.

No. Retrying a declined payment is performed at the processing layer by the configured gateway, and dunning — the escalating sequence of reminders and actions against unpaid charges — belongs to billing systems. Bonza surfaces what is overdue and what needs a person’s attention. It does not chase customers, apply fees, record promises to pay, or take action on its own.

That is decision one, and it has two defensible answers. Holding it on the agreement gives you one place to change a date or an amount. Holding the expectation on each payment record means every cycle remembers what was expected of it, so history survives a change. The question to ask is what you want to be true a year after someone edits the amount: if past cycles must still show what they were originally for, the expectation has to live with the payment.

Expiry is the only recurring failure that is fully knowable in advance. The expiry date is known and the next payment date is known, so the collision between them can be seen before it happens. It usually is not seen, because the two facts live in different systems. Putting them in the same view is what turns expiry from an after-the-fact decline into something a person can act on early.

The arrangement continues, so the refund changes the position of something still in motion rather than closing a matter. For the arrangement’s totals to stay true, the refund has to remain attached to the payment and the arrangement it came from. Where value is retained rather than returned, it can be recorded as customer credit for supported future payment use — which is a record, not stored cash.

The vocabulary, decisions and failure modes apply wherever recurring payments are managed. The context is Salesforce, because that is where Bonza Payments operates, and because keeping the payment relationship on the customer record is what makes several of these questions answerable at all. The Salesforce-specific design decisions — where payment records belong, which states are distinct — are on the Salesforce Payment Guides page instead.

Yes, and it is common. The reason it matters is that the two obey different rules: a one-time payment is finished when it is paid, and a recurring one is not. A view that treats every payment the same way will report an arrangement as settled every time an instalment lands. Keeping both kinds against the same customer record, with their differences intact, is the point of managing payments rather than transactions.

No. No recurring payment guide, template, spreadsheet or PDF has been published, so there is no title, author, date, page count or file to offer, and this page does not imply otherwise. The reference is delivered in full on the page, which means it can be read, linked to and quoted without requesting anything or providing an email address.

You need to know which answers a system forces on you. Most of the eight decisions are made implicitly by whatever tool is adopted, and the first time anyone notices is the first time someone asks what a past cycle was for. Reading the eight and deciding which ones you have a strong view about is a useful hour before any evaluation, including an evaluation of Bonza.

The answers you already have, and the ones you do not. Which of the ten questions above your current setup answers quickly, which take an afternoon, and which of the eight decisions were made deliberately rather than by default. That makes a conversation about your actual arrangement rather than a demonstration of features.