FinDock Documentation

website·Indexed 33 days ago

https://docs.findock.com/

Documentation for FinDock, a payment integration for Salesforce. Includes guides on the Payment API v2 for one-time and recurring payments, Giving Pages for fundraising, and integration with Salesforce Experience Cloud and Person Accounts.

Tokens
258.4K
Snippets
374
Records
2K
Agent score
61%

What's inside FinDock

  1. Overview of FinDock pain.008 Direct Debit Processing

    FinDock uses the ISO 20022 pain.008 (Customer Direct Debit Initiation) message format to submit payment instructions to banks. It is used for native direct debit processing of SEPA, SEDA, CH-DD, and LSV+ payment collections.

    Supported versions include:

    • Pain.008.001.02
    • Pain.008.001.08
    • CBI variants for SEDA
  2. Overview of ProcessingHub Manager

    The ProcessingHub Manager is a tool available by default through the FinDock app. It allows developers and administrators to track the progress of processes (such as payment schedules, mandate schedules, and file imports/extractions), troubleshoot setup or data load errors, and monitor record deletions.
  3. Overview of Access PaySuite integration with FinDock

    FinDock integrates with Access PaySuite (formerly SmartDebit) to facilitate one-time and recurring direct debit payments in the UK using the Bacs Direct Debit scheme. FinDock's primary role is to create payer and collection files and process Bacs reports. The transfer of files and reports between FinDock and the Access PaySuite Direct Debit and Credit Management System (DDCMS) is handled automatically via ProcessingHub.
  4. Overview of Bacs report processing in FinDock

    FinDock processes Bacs reports uploaded to Chatter (for Bacs Manual targets) or fetched from SmartDebit targets. Reports are parsed as Inbound Report records and processed in two phases: first, ProcessingHub matches related mandate and installment records; second, Guided Matching rules handle the report actions.

    Processed reports are assigned one of the following statuses:

    • Matched: Successfully processed and matched.
    • Guided Review: Report type identified and rule set assigned.
    • Failed: Error during processing.
    • Manual: Report type could not be identified; requires manual review.
  5. Overview of AvtaleGiro direct debit in Norway

    AvtaleGiro is a direct debit payment scheme used in Norway, managed and operated by Mastercard Payment Services (MPS), formerly NETS. Payments are executed based on a pre-existing agreement between the payer and the merchant; this agreement must be approved and active before any payments can be collected.
  6. Overview of payment reconciliation with FinDock

    Payment reconciliation involves comparing data across three primary points: the bank account, the CRM (Salesforce), and the accounting ledger to ensure financial reports are accurate and free of discrepancies. FinDock simplifies this process by providing automatic and custom matching capabilities to reconcile multiple data sources, including integrated Payment Service Providers (PSPs) and standard bank file formats.
  7. Overview of pain.002 file processing in FinDock

    FinDock uses Customer Payment Status Reports (pain.002) to identify direct debit rejections (status RJCT), signaling that an originating installment will not be collected. This processing is available for accounts configured as SEPA targets. Supported versions include:

    • pain.002.001.03
    • pain.002.001.10
    • CBI variants for SEDA (CBISDDStatusReport)
  8. Overview of online payment processing and reconciliation

    FinDock automatically processes and reconciles online payments triggered by the FinDock Payment API or Payment Service Provider (PSP) notifications (webhooks). The workflow follows these steps: 1. The API call or notification is captured as a Message record. 2. FinDock creates an Inbound Report record from the message. 3. The Inbound Report is processed and matched using Guided Matching rules. The full content of the original notification is stored in the Raw Message field of the inbound report, which can be used in custom Guided Matching rules.
  9. Overview of the Recurring Payment Schedule object

    The Recurring Payment Schedule object (cpm__Recurring_Payment_Schedule__c) is used to manage multiple payment collection runs for a specific source, payment process, and payment method. It acts as a template that defines the scope of individual Payment Schedules and determines how installments are selected or generated for each run.
  10. Overview of FinDock Batch Reconciliation

    Batch reconciliation allows you to manually group installments that were not collected via FinDock but are expected to be paid in a single lump-sum transaction (e.g., a group of checks). When a bank statement file containing the lump-sum payment is processed, FinDock automatically matches the transaction to all installments in the group and marks them as collected.

    Constraints:

    • Only supports credit transactions.
    • Debit transactions (like reversals) cannot use this batch method; instead, use Guided Matching by adding up to 13 installment IDs to the 'Multiple Installment Ids' field of the transaction.
  11. Overview of Bacs Manual self-managed setup

    Bacs Manual is a self-managed configuration for collecting one-time and recurring direct debit payments in the UK. In this setup, FinDock generates Standard 18 files for lodgement and collection and processes incoming Bacs reports. The organization is responsible for compliance with Bacs rules and the actual transfer of files to the Bacs system using Bacstel-IP software or other Bacs service arrangements.