Collecting payments with FinDock

With FinDock you can collect both one-time and recurring payments using a range of payment methods through several different processors. For certain direct debit schemes, FinDock itself can act as a simple payment processor allowing you to self-manage bank file transfers.

FinDock payment data model

When you install FinDock, several new objects are added to the Salesforce CRM data model. The payment-related objects are:

• Installment: stores information about payable and receivable amounts.The installment record is the basis for communicating payment instructions to external systems. It also tracks the status of the expected transaction and can be used as a basis for communication with the payer.
• Mandate: used to store payment authorizations such as direct debit mandates or recurring credit card payment tokens. It enables you to collect payments automatically in the future.
• Recurring Payment: defines a certain amount to be collected from a contact or account at a regular interval over a given time period. This object is only used if FinDock is the source of payment data. If NPSP is used as the source, the Recurring Donation object is used instead.
• Payment: used to track cash flow. Whenever money changes hands (transfer, reversal, credit, debit, etc.), FinDock creates a payment record to reflect that transaction. Payments are always linked to a single installment. However, one installment can have multiple related payments.
• Payment Profile: used to store payment related information such as bank accounts and tokenized Credit Card information.

You can read more about each object in our technical components documentation.

Collecting payments

Getting payment data into your Salesforce CRM is valuable in itself, but the ultimate goal is getting money on your organization’s bank account. Here we present the basic tools available to do just that.

First, let’s clarify a couple of key concepts.

Online / synchronous payment

When the transaction is synchronous and money is transferred immediately, the event is considered an online payment. The term synchronous reflects the timing - the transaction agreement and money transfer happen sequentially without delay. Credit card purchases and bank transfers, for instance, are online, as the payment amount is debited as soon as the payer approves the transaction.

Offline / asynchronous payment

When the transaction is asynchronous and money is transferred with a delay, the event is considered an offline payment. Because it is delayed, this type of payment is also considered asynchronous because the money transfer happens at a different time from the transaction agreement. It can also be called a “payer not present” payment, which highlights the fact that collection requires a payer to have previously authorized you to collect the payment (and future recurring payments).

Online payments

Most payment methods can be accepted through digital channels. You can connect your front-end payment form (app, web page, etc.) to the FinDock Payment API or set up web pages using FinDock Giving Pages. The basic flow looks like this:

1. Customer enters personal information in the front-end payment form.
2. Details are sent to FinDock for creation, update (or deduplication) of contact record.
3. If required by the payment method, additional authorization details are requested and captured by the PSP (e.g. through a Hosted Payment Page).
4. Notification(s) of payment transactions are sent to FinDock for creation of payment records.
5. Follow-up communication, such as a thank-you message or payment confirmation, is sent to the customer according to your customer relations flow.

From a more technical perspective, the online flow involves multiple connections, a bit more like the illustration below. This, however, is also a simplification, but gives you a better idea of what a custom Payment API integration would entail.

When you collect online payments through a PSP, FinDock does not store all payment details like credit card numbers or bank accounts, but a token provided by the PSP that can be used for future payments.

Offline payments

One-time direct debit payments and future installments of recurring direct debit payment are collected with a delay or “offline” as it is sometimes called.

For these 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. This gives you fine-grained control over when, what and how you collect your payments.

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.

In short, this means if the payment collection is through an integrated PSP, the collection is handled via API calls. If the collection is directly through a bank, FinDock generates the required files in the required formats.

Mandate management

A "mandate" is the authorization customers give you to collect money from their accounts. When using external processors, managing these authorizations is largely the role of your PSP.

In the case of direct debit payments manually processed through FinDock, we provide complete mandate handling. This includes both outbound and inbound mandate-related instructions.

File types generated by FinDock

The following table includes the file types that FinDock generates through payment or mandate schedule runs. These files are generated when FinDock is used as a native payment processor.

File	Name	Payment Method	Description	Format
DDI	Direct Debit Instruction	Bacs Direct Debit	Mandate setup instructions for the Bacs Service	Standard 18
DD collection file	Direct Debit payment instruction	Bacs Direct Debit	Payment collection instructions for the Bacs Service	Standard 18
HMRC file	Charities Online Filing	Gift Aid	Charity tax claim for UK donations	HMRC XML for Gift Aid submissions
Pain.001	Customer Credit Transfer Initiation	SEPA Credit Transfer	Instruction from debtor organization to transfer funds to creditor	ISO 20022
Pain.008	Customer Direct Debit Initiation	SEPA Direct Debit, SEPA CBI	Instruction from creditor organization to collect from debtor	ISO 20022
Pain.009	Mandate Initiation Request	SEDA	Instruction from creditor organization to set up a direct debit mandate	ISO 20022
Pain.010	Mandate Amendment Request	SEDA	Instruction from creditor organization to change a direct debit mandate	ISO 20022
Pain.011	Mandate Cancellation Request	SEDA	Instruction from creditor organization to cancel a direct debit mandate	ISO 20022

Initiating payments through Salesforce user

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 Payment for MOTO payments
• GoCardless Quick Direct Debit
• Worldpay MOTO
  • Corporate Gateway
  • Business Gateway 350

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

Payment requests

Payment requests are payments initiated by you, the creditor, rather than the debtor. The requests can be used to handle, for example, recurring membership fees, or they can be generated for non-binding payments, such as a direct mail fundraising campaign with a pre-filled payment slip.

One option is to use the Payment Request Generator. The generator "stamps" Salesforce records with a unique payment reference that can be used. Depending on the payment method, the requests can be reference IDs (e.g. used on printed payslips), links and QR codes. This feature is ideal for creating donation requests, without having to create corresponding installments upfront. The references can be used for print and digital channels, and they make matching successful payments easy.

Another option is to use paylinks. FinDock PayLinks is a paid add-on feature that automatically adds a payment URL to every installment in your org. Once you configure PayLinks is configured, you can use paylinks for most anything, including payment requests.

Some markets may have unique payment request methods. One such example is Tikkie in the Netherlands. FinDock supports bulk Tikkie generation as well as Quick Tikkies.

Reconciling payments

When you have payment data in more than one place, you need to regularly check that everything lines up correctly. This is an important step to ensure there are no mistakes, gaps, or unexplained discrepancies that need further investigation. It’s also your way to ensure your financial reports are accurate.

Typically the realm of accountants and financial offices, reconciliation is certainly the hard bit of payments. Particularly in small organizations where the checking is often completely manual, the reconciliation process is arduous and error prone.

In its simplest form, you compare three data points: your bank account, your CRM and your accounting ledger.

However, the complexity of the modern payment landscape changes the reconciliation picture. The reality of your payments on Salesforce may include a wide range of payment data sources.

This is why FinDock includes tools for reconciling payment data. The express goal of these tools is to unify payment data into a single data model with actionable data.

With accurate payment data in your Salesforce CRM, you can use any number of Salesforce features and apps to report, compare or automate workflows that support your business.

Out of the box, FinDock processes several standard bank file formats and automatically reconciles payment notifications from integrated PSPs.

With the right set of matching rules, you can process data faster, increase your matching rate and help guide reviewers of unmatched entries to the right data.

For all PSPs supported by FinDock, Guided Matching is already part of the integration. You also can set up reconciliation for any online payments. The Guided Matching rules provided by FinDock are extensive, but you can freely extend the matching logic by creating your own matching rules.

To give an idea of how much you can do, check out our blog post about inbound payment data for Salesforce.

Use cases

The following typical uses cases provide a simple outline of the main steps of different kinds of payment collection flows.

One-time credit card payment with PSP

1. Payer authorizes payment online through a custom payment form, FinDock Giving Pages or a hosted PSP page.
2. Required data is automatically created at PSP and in FinDock.
3. PSP notifications to FinDock are automatically processed for reconciliation.

Examples of other payment methods that follow this flow: iDEAL, SOFORT, Bancontact, GoCardless Instant Bank Pay

Recurring SEPA direct debit with FinDock

1. Payer authorizes recurring payment online through custom payment form or Giving Page, or offline through phone or paper.
2. FinDock creates a mandate and recurring payment record; if authorization is offline, the records are created manually by a Salesforce user.
3. Creditor runs a payment schedule, triggering FinDock to generate an installment and create a payment collection file.
4. Creditor submits collection file to bank.
5. Creditor uploads bank statement(s) from the bank, and FinDock automatically reconciles payment(s) for the submitted installment.

Examples of other payment methods that follow this flow: LSV+ and CH-DD. Using FinDock to process Bacs Direct Debit is similar, but requires a separate flow to first register mandates (Direct Debit Instructions) before collecting.

Recurring credit card or direct debit with PSP

1. Payer authorizes recurring payment online through custom payment form or Giving Pages.
2. FinDock creates a mandate and recurring payment record.
3. Creditor runs a payment schedule (manually or through auto-collection), triggering FinDock to generate the next installment.
4. The required data to collect the installment is automatically created in FinDock and at the PSP.
5. PSP notifications about payment status are sent to FinDock and automatically processed for reconciliation.