Channels for accepting payments
The first step in payments management, and three-step process we refer to as Accept - Collect - Reconcile, is to create ways to accept payments from payers. In practice, the acceptance step is where you capture a payer's intent to donate, purchase or otherwise commit to a monetary transaction. The capture details and authorization are specific to the payment method the payer has selected.
Channel categories
We categorize the ways to accept payments into four generic channels. Each category has unique technical and procedural characteristics.
Online redirect
The online redirect channel enables you to accept payments through digital forms that redirect to a hosted payment page from the payment service provider (PSP) to capture payment method details and authorization. Here is an example from Stripe.

This is a common channel you encounter with online shopping. You first confirm purchase details and contact information, then select a payment method which takes you to a secure hosted payment page from the shop's PSP.
Online direct
The online direct channel is similar to online redirect, but with a difference that impacts the payer's experience. Instead of being taken to a 3rd party hosted payment page, the online direct channel keeps the payer entirely within your own digital (website) context.
Through forms completely under your control, you securely capture all the required payment details from the payer without additional steps or prompts from a PSP. All direct debit schemes natively supported by FinDock can use the online direct channel, for instance.
Data entry
The data entry channel is a broad category that encompasses all the ways you can create records in Salesforce. Through manual actions or custom processes, bulk data import and so forth, you can add payment intents captured outside of FinDock by creating the one-time or recurring payment record in Salesforce.

The payment method details you captured with a Payment Profile record. While data entry can be used for all payment methods, some require additional actions before collection, such as registering the payer's mandate.
Virtual terminal
The virtual terminal (VT) channel is an agent-driven means to capture the payer's intent. The customer support or service agent enter's payment details in Salesforce on behalf of the payer using a virtual terminal. The payment details depend on the payment method, but the key here is that an agent enters the details on behalf of the payer. You often see these called Mail-Order-Telephone-Order (MOTO) payments.
Some PSPs have a dedicated component, like GoCardless Quick Direct Debit, but FinDock provides its own virtual terminal in Salesforce, the FinDock Payments component which can leveraged different ways in Salesforce on page layouts and in Flows. Taking new card payments or updating card details are common virtual terminal use cases. Setting up direct debit payments can also be done via virtual terminal. For further details, see also accepting payments from Salesforce.

Online versus offline payments
Most payment methods can be accepted through online channels. Online payments typically mean immediate collection with the payer present. You can connect your front-end payment form (app, web page, etc.) to the FinDock Payment API or use FinDock's out-of-the-box options like Giving Pages and PayLinks.
The basic online payment flow is:
- Customer enters personal information in the front-end payment form.
- Details are sent to FinDock for creation, update (and deduplicate) of Contact or Account record.
- If required by the payment method, authorization details are requested and captured by the PSP (e.g. through a Hosted Payment Page).
- The PSP sends notification(s) about payment processing status to FinDock, triggering matching and reconciliation to create and Salesforce data.
- Follow-up communication, such as a thank-you message or payment confirmation, is sent to the customer according to your customer relations flow.
Many payment method and processor combinations result in immediate collection of one-time payments and initial payment of new recurring payments. However, in some cases, such as a one-time direct debit natively processed through FinDock, the collection is offline. In all cases of recurring payments, future installments are collected offline.
Offline payments
For offline payments, you use a payment schedule to send instructions to the processor to collect the payments. Payment schedules can be run once, regularly over a specific period, or configured to run automatically. Offline payments are collected without the payer present. Examples include future installments of recurring payments, some bank transfer methods, direct debits, and cash or check transactions that confirmed via bank statement reconciliation.
While the payment schedule tool itself remains the same regardless of the payment method and processor, FinDock automatically handles the related installments according to the given method and processor. If the payment collection is through an integrated PSP, the collection is handled via API calls. If the collection is through a bank or service bureau, FinDock generates the required file, uploads it to Chatter, from where it is manually (or in some cases automatically) transferred to the bank or service bureau.
When you set a collection or processing date on a payment schedule, that data point is used in the payment instructions FinDock generates for the given payment method and processor when required. How that date is translated into processing actions depends on the method-processor combination.
The exact collection steps and collection date depend on the payment method and processor combination. Direct debit schemes, for instance, typically have defined timelines that dictate when accounts are debited and credited. PSPs may have specific processing timelines as well for supported payment methods. Please refer to our payment processor guidance and the documentation of your PSP for further details.
Mandate management
A "mandate" is the authorization payers give you to collect money from their accounts. When using external processors, managing these authorizations is largely the role of your PSP.
For payment methods natively processed through FinDock, we provide complete mandate handling. This includes both outbound and inbound mandate-related instructions.