Skip to main content

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 payer agreements such as direct debit mandates or authorization token for a card. The mandate is used to collect future payments without additional authorization from the payer.
  • 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 used as the source. If another source is used, the source-specific objects replace the role of Recurring Payment. In the case of NPSP, for example, a recurring payment is defined by Recurring Donation.
  • 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 details for a payment method the payer has used, such as a bank account or tokenized credit card details.

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.

Overview of online payment 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.

Technical view of online payment flow

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

Some one-time payments and future installments of recurring payments are collected with a delay when the payer is not present, 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.

Technical view of offline payment flow

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.

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.

FileNamePayment MethodDescriptionFormat
Autogiro Mandate FileMandate FileAutogiro direct debitMandate setup instructions for Bankgirot service80-character fixed length
Autogiro Payment InitiationPayment InitiationAutogiro direct debitPayment collection instructions for Bankgirot service80-character fixed length
DDIDirect Debit InstructionBacs Direct DebitMandate setup instructions for the Bacs ServiceStandard 18
DD collection fileDirect Debit payment instructionBacs Direct DebitPayment collection instructions for the Bacs ServiceStandard 18
HMRC fileCharities Online FilingGift AidCharity tax claim for UK donationsHMRC XML for Gift Aid submissions
Pain.001Customer Credit Transfer InitiationSEPA Credit TransferInstruction from debtor organization to transfer funds to creditorISO 20022
Pain.008Customer Direct Debit InitiationSEPA Direct Debit, SEPA CBIInstruction from creditor organization to collect from debtorISO 20022
Pain.009Mandate Initiation RequestSEDAInstruction from creditor organization to set up a direct debit mandateISO 20022
Pain.010Mandate Amendment RequestSEDAInstruction from creditor organization to change a direct debit mandateISO 20022
Pain.011Mandate Cancellation RequestSEDAInstruction from creditor organization to cancel a direct debit mandateISO 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:

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.

Technical view of MOTO payment flow

  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 to "stamps" Salesforce records with a unique payment reference. 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. For more information, see Payment requests with FinDock.

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.

Simple triangle of reconciliation

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.

Full scope of reconciliation

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.

Reconciliation process in FinDock

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