Initiating payments from Salesforce

In many common scenarios, payment acceptance includes direct actions from the payer. Entering card details in a payment form, setting up a bank transfer, direct debit, etc. - these are all payments initiated by the payer entity.

There are also scenarios where payments are initiated from Salesforce as Salesforce user entity. 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 payment 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 for MOTO payments
• GoCardless Quick Direct Debit

For payment methods where FinDock can be the processor, such as SEPA and Bacs Direct Debit, payments can also be initiated directly in Salesforce. A service agent simply creates the needed records (for the given payment method) manually, or you can do this with a custom Salesforce workflow, for example.

MOTO payments with FinDock

The Mail Order Telephone Order (MOTO) payment scenario is unique compared to normal online or offline payments. With MOTO payments, payers share payment their details, typically over the phone or on paper, with a customer service agent (or marketing agent, etc.). The agent enters the details and then initiates the payment for the payer.

FinDock supports MOTO payments natively through the FinDock Payment component. However, additional PCI compliance and security measures are required before an organization can collect MOTO credit card payments.

1. 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.

Custom processes

In addition to simply creating records one by one, you can use Salesforce tooling, such as Flows, to create custom processes for initiation 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 handling 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.