FinDock Standalone

When FinDock is use as a source, we call this setup FinDock Standalone. It means FinDock objects for one-time and recurring payments, Installment and Recurring Payment, respectively, are the primary source of payment data in an org.

FinDock Contact Layout

When using FinDock standalone, you can use the Contact FinDock layout on the contact record detail page to have the FinDock objects included on the layout. For more information on how to assign page layouts, see Assign Page Layouts from a Customize Page Layout or Record Type Page in the Salesforce Help.

One-time payments

Single invoices, other amounts receivable, as well as amounts payable are captured by Installment records. The default status for newly created Installment records is Outstanding.

Recurring payments

Recurring Payment records define the amount, payment method, frequency and other information for recurring collections. A recurring payment can be created for a contact or an account.

With the layout of the FinDock Recurring Payment Record Page (Lightning Record Page), you get a complete overview of recurring payment details, a dynamic list of open (uncollected) installments, as well as a Lightning Web Component that previews upcoming installments.

Collection frequency

When creating a new Recurring Payment record, the Frequency field determines how often the amount is collected.

With certain payment processor and method combinations, an initial payment may be optional or required when setting up the new recurring payment. The initial payment amount can also differ from the recurring amount and is collected as part of the setup process.

Installment generation mode

FinDock Standalone supports two installment generation modes: generate by payment schedule or generate by FinDock Heart Beat. The heartbeat mode is the default for new FinDock installations after the September '25 release.

The generation mode is determined by the custom setting Generate Installments From Heartbeat under PaymentHub Settings*(cpm__PaymentHub_Settings__c). For new FinDock Core installation after September '25, the default is true (checked).

Installment generation via heartbeat

When installments are generated via FinDock Heart Beat, a dedicated heartbeat (GenerateInstallmentsBeat) checks all active recurring payments on a daily basis. If the Last Collection Date for a recurring payment is on or before today, then a new installment is generated. The Next Collection Date is then automatically recalculated and updated.

Installment generation via payment schedule

With payment schedule generation, Installment records are created within a given payment schedule run in the Generate step of the prepare phase. For selected recurring payments, if the Next Collection Date is on or before the Selection Date of the payment schedule, and installment is generated and attached to the schedule (and the recurring payment collection dates updated accordingly)

Changing installment generation modes

If you want to switch from schedule-based to heartbeat generation, you can do so by updating the custom setting Generate Installments From Heartbeat from false (unchecked) to true (checked).

When planning the switchover, keep in mind the following:

• Change the custom setting after all payment schedules for the day have completed.
• Make sure no new payment schedules runs start before the next heartbeat (by default at 01:00 the next day).
• If the payment schedule auto-run heartbeat (GeneratePaymentSchedulesBeat) has been modified, make sure it starts at least an hour after the installment generation heartbeat.
• Existing recurring payments that are behind will get new installments for each missed collection. For example, if monthly recurring payment has missed three months, a new installment is generated each day up to the current payment period, i.e. three new installments in three days, with due dates a month apart.

Key dates on recurring payments

Key dates on a Recurring Payment record can be modified by

• Explicitly setting the field values as part of the payment intent call to the Payment API
• Creating a custom process to set the field values using Salesforce tooling such as Flow
• Manually creating the records and adjusting dates as needed

Start Date

This is the date the recurring payment becomes active. By default, FinDock uses today as the Start Date for newly created recurring payments.

If the Collection Day of Month is after the Start Date for that month, then the first collection occurs within the starting month. For example, if the Start Date is June 1st, the Collection Day of Month is 31, and today’s date is June 26, then the Next Collection Date will be June 31st.

For Daily and Weekly frequencies, the Start Date is the first Next Collection Date value. So, for example, if the Start Date is equal to Today, then the first installment has a Due Date of Today.

Collection Day of Month

By default, FinDock uses 1 (first day of the month) for the Collection Day of Month. If you set a custom Collection Day of Month that is 29, 30 or 31, FinDock falls back to the last calendar day of the month if a given month, such as February, has fewer days.

End Date

This is an optional date for recurring payments. If there is no end date, the recurring collection continues until the payer ends the agreement, and the recurring payment (and mandate) is deactivated. If there is an End Date, no further installments are generated once that date has passed. Should a Next Collection Date calculation equal End Date, that date is still used and results in an installment with a Due Date equal to the End Date of the recurring payment.

Next Collection Date

When a new Recurring Payment record is saved, the Next Collection Date field is automatically populated with a value that determines when the next installment is due. This value is the next Collection Day of Month based on the Last Collection Date or the Start Date if the Last Collection Date is empty.

Last Collection Date

When an installment is generated, the current Next Collection Date becomes the Last Collection Date. The Last Collection Date is used as the Due Date and Original Due Date on the generated installment.

Closing recurring payments

If a payer wants to close a recurring payment, you will typically have business-specific logic to handle this scenario. The business logic needs to ensure the related mandate is inactive and no open installments are eligible for collection.

You can create a custom Flow, for example, to stop recurring payment collection. The closing process is:

1. Deactivate the related mandate by changing the Active checkbox from marked to unmarked.
2. Set the status of existing open installments to a closed state, such as Cancelled.
3. Deactivate the recurring payment by changing the Active checkbox from marked ot unmarked.
4. If relevant for the business case logic, change the Status value to e.g. On Hold.

Mandate management

Mandate records represent the payer's agreement to allow you to collect money. Mandates can be generated by FinDock when required based on your Core Mandate service settings.

FinDock auto-generates a new mandate if one of the following occurs for the given recurring payment:

• The payment method is changed
• The payment processor is changed
• The target is changed
• The payment profile is changed
• The mandate field is emptied
• The recurring payment frequency is changed

The need for and role of the Mandate record in FinDock depends on the payment processor and method combination for the given installment or recurring payment. For native direct debit processing through FinDock, mandates are your primary record of payer authorization. For processing through PSPs, the mandate reflects the authorization stored and managed by the PSP.

Mandates must be Active with status Success before they can be used for collection. In some cases, mandates need to be registered before you can start collecting payments. The registration process is carried out through mandate schedules.

Collecting payments with FinDock Standalone

When using FinDock Standalone, you can collect and disburse payments using the standard payment schedule process.

Depending on the payment processorW, when a payment schedule is processed successfully, either the finished status is set or the installments are closed as completed.