Accepting payments with FinDock

The first step in payments processing is to create ways to capture the payment intent of your customer. In practice, accepting a payment is how you capture the details required to process the donation, gift purchase or other financial commitment. The required details, including payer authorization, are specific to the payment method the payer has selected.

Online payment collection

Online payment collection requires the payer to be present to complete the payment. In many cases, when completed, the payment is also immediately collected. The basic online payment flow with FinDock is:

1. The customer enters personal information in a payment form.
2. Details are sent to FinDock for creating, updating (and deduplicating) a Contact or Account record.
3. If required, further details and authorization are requested and captured by the PSP (through a Hosted Payment Page).
4. After the payer completes the payment, the PSP sends notification(s) about payment processing status to FinDock, triggering automatic reconciliation with Salesforce data.
5. Follow-up communication, such as a thank-you message or payment confirmation, is sent to the customer according to your business-specific flows.

Online payment flows

The payment method and processor combination determines the payment flow used to complete the payment. There are two essential variants: online redirect and online direct.

Online redirect

The online redirect payment flow uses a two-step process to gather the payment details needed to complete the payment. The first step is a digital form you control. The form captures the payer’s general information, such as name and email address, that is stored in Salesforce as a Contact or Account record (and deduplicated).

When the customer (payer) selected the given payment method, FinDock automatically redirects to the hosted payment page from the payment service provider (PSP). This is where the payer securely enters the details and authorization required for the payment.

With the online redirect payment flow, one-time payments and initial installments for recurring payments are collected and reconciled automatically. Future installments of recurring payments are collected through payment schedules.

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 payment flow keeps the payer entirely within your own digital (website) context.

Through forms 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.

With the online direct payment flow, both one-time and recurring payments are collected through payment schedules.

Online integration patterns

For online payment collection, FinDock supports several integration patterns. All patterns are in practice different implementations of the FinDock Payment API.

There are also integration patterns for accepting payments directly from Salesforce. For further information, see below.

Offline payment collection

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 are 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. Most payment requests also are collected offline.

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.

Accepting payments from Salesforce

There are also scenarios where payments are initiated from Salesforce by a Salesforce user. There are few processor and method options for this route, but they are important for certain scenarios.

Generally speaking, for payments initiated from Salesforce, there are two paths for creating the necessary records:

• Through a managed component from FinDock
• Through custom processes using Salesforce tooling (or simply manually one by one)

Managed payment components

For certain payment processors and methods, FinDock provides a managed Salesforce component that service agents can use to create payments. The following components are currently available:

• FinDock virtual terminal (see below)
• GoCardless Quick Direct Debit
• Quick Tikkie

FinDock virtual terminal

The FinDock Virtual Terminal (VT) channel is an agent-driven means to capture the payer's intent. The customer support or service agent enters payment details in Salesforce on behalf of the payer. 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 be leveraged in different ways in Salesforce on page layouts and in Flows to collect credit card and direct debit payments.

Taking new card payments or updating card details are common virtual terminal use cases. However, additional PCI compliance and security measures are required before an organization can collect MOTO credit card payments.

1. The customer shares credit card details over phone or on paper.
2. Service agent enters details in FinDock Payment component.
3. Component sends the Primary Account Number (PAN) to PSP and receives an authorization token.
4. FinDock completes payment collection with PSP.

The payment details captured by the component are used to set up an authorization token with the PSP. This allows FinDock to initiate the payment, and if it is a one-time payment, immediately collect the payment. For recurring payments, FinDock creates a recurring payment record. Individual installments for the recurring payment are then collected through payment schedules.

Data entry

Data entry is a broad category that encompasses all the ways you can create records in Salesforce. Through agent actions and 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.

While data entry can be used for many payment methods, some require additional actions before collection, such as registering the payer's mandate, 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.

In addition to simply creating records one by one, you can use Salesforce tooling, such as Flows, to create custom processes for accepting payments from Salesforce. When using this approach, the actions you need to take as a Salesforce user are dependent on the payment method and processor combination. For example, mandate requirements differ across direct debit schemes.

In most cases, however, you can safely assume you need the following records for payments initiated from Salesforce:

• Payer details: basic information about the payer, such as name and address, is captured in standard Salesforce objects such as Account, Business Account, Contact and Person Account.
• Payment method details: a Payment Profile record captures the details required for a given payment method, such as bank accounts for direct debit.
• Payment details: the payment itself (amount, due date, etc.) is defined by an Installment record or a Recurring Payment record (or source-specific equivalents such as Recurring Donation)
• Payer authorization: if the payment method requires authorization, as in the case of direct debits, this is captured by a Mandate record.

For further details on required actions for payments initiated from Salesforce, please refer to the specific payment processor article.