• Home

Preparing a project

Here we outline the main topics and actions you should consider when implementing FinDock in a Salesforce project. We include links to FinDock articles, as well as Salesforce sources where relevant.

A quick overview of FinDock

FinDock is a payments management solution built 100% native for Salesforce. You can connect Payment Service Providers (PSPs) and banks directly to FinDock to support a range of payment methods, currencies and regions. FinDock itself natively supports payment processing for several direct debit schemes.

Common use cases of FinDock include:

  • Collect funds through direct debit from customers based on invoices stored in Salesforce
  • Process online transactions through a PSP and maintain real-time payment data in Salesforce
  • Provide follow-up payment options, including alternative payment methods, for missed or failed payments

You can leverage FinDock in many different scenarios and industries to fit specific payment management requirements.

FinDock components

FinDock includes all the necessary logic to handle payments, register cash flow, etc. It orchestrates how and when different extension packages are used. The Core package (also known as PaymentHub in older instances) forms the essential backbone of the entire solution. ProcessingHub refers to the engine which plays a critical role in:

  • Bulk collection file creation (such as direct debit files)
  • Collection file delivery (such as to a PSP or within Salesforce)
  • Bank statement file recognition and parsing
  • Bank statement transaction matching

A FinDock setup includes multiple packages and dedicated Heroku apps for things like file processing and webhook notifications. Alongside the required packages, you can install any number of payment extensions to integrate with PSPs. For certain industry solutions, FinDock also has source connectors to manage creating and syncing data.

Read more about our technical components and objects.

Implementing FinDock

If the FinDock implementation coincides with a broader Salesforce implementation, make sure to plan and align tasks with the project responsible for the Salesforce roll out. The following is a basic outline of the steps for a new FinDock implementation.

Preparation

Before starting your implementation, make sure to get everyone aligned on the required steps and actions. We recommend that you clearly define your project methodology, success criteria and timeline. We also recommend creating a communication plan that keeps key external parties (such as FinDock) in the loop so that changes or potential issues can be resolved quickly. Good governance helps prevent issues and unexpected behavior in the long run.

Especially if the Salesforce org plays a pivotal role in the cash flow and payer registration, you need a comprehensive governance plan covering support, maintenance and future development. Ideally the governance framework is defined with input from the customer as well as external parties, including FinDock.

Integrating systems

In many cases, the FinDock and Salesforce implementation is part of a larger IT landscape, with dependencies and integrations between different systems. For the FinDock implementation, these integrations typically include:

  • Website or mobile app integration for online payments
  • Accounting system integration for exporting the cash flow registration

For custom front-end integrations, FinDock provides a Payment API. Using this API requires some configuration on the Salesforce side, as well as by the internal or external web/app developer.

Planning data migration

Most implementation projects include some form of data migration. We recommend you address at least the following:

  • How much data are you going to migrate? Make sure to discuss with the Salesforce Account Executive how much data will be migrated and calculate the Salesforce Data Storage usage accordingly.
  • How are you going to register past payments? If no further processing of past transactions is needed, consider just storing them. For example, with Salesforce NPSP, you can move them to Opportunities rather than Opportunities with Installments. If FinDock may need to manage changes to past transactions, such as reversing direct debits, make sure to create installments for migrated payment records.
  • Test migrated data. Make sure you can run processes on the migrated data. For example, test payment collection based on the migrated records. This ensures you have migrated the data not only to the right objects, but also the correct fields.
  • Take your time and test often. Data migrations are notoriously difficult. Start data migration as early as possible in the project and give yourself a large time buffer. Create the mappings, plan multiple test migrations, etc. This pays off in the later stages of the project in terms of run time performance, error mitigation and data quality.

More information on data migration and bulk data uploads, please see Migrating payment data.

Configuring communications

Every organization has some form of communications concerning payments. This may include, for example:

  • Direct Debit pre-notifications
  • Confirmation of changes (bank account changes, collection date changes, etc.)
  • Thank-you messages for new payers
  • Summary reports of payments and/or donations

FinDock provides the information required for these kinds of communications, but includes no out-of-the-box templates as the formulations differ greatly from payment method to payment method and country to country. In some payment schemes, communication content needs to be approved by the bank or payment service provider. For example, in the UK all communication relating to direct debit, including confirmation emails, need to be approved by the bank. Make sure to check if this is the case for your customer and plan communication development accordingly.

Handling unpaid payments

Every organization faces unpaid, overdue, failed or reversed payments at some point. based on these transactions. The right message at the right time can significantly speed up payment of unpaid or overdue invoices or pledges. FinDock provides the necessary data to initiate appropriate follow-up actions and journeys, such as:

  • Retry journeys for Reversed Direct Debits: these can be based on the reason code for the reversal, such as insufficient funds.
  • Follow-up query on Failed Direct Debits: failure might be because, for example, the bank account is incorrect, the organization was mistakenly blacklisted, or the payer forgot to add the organization to a direct debit white list. Follow-up may also be needed for unpaid bank transfers and other accounts receivable not actively collected, or overdue invoices payable via bank transfer.
  • Follow-up on failed online donations: this typically happens with ‘abandoned cart’ processes for online transactions.

The Salesforce ecosystem provides a variety of tools to help you implement these flows, from mail merge tools for physical mailings, to online customer journey management tools such as Marketing Cloud and Pardot.

Testing and validating implementation

Before go-live, perform extensive testing on your entire setup to ensure the business processes run smoothly and the goals of the implementation are being met. Testing should be an integral part of the entire implementation process.

The final testing round before go-live brings all the (independent) configurations together and tests the implementation as a whole. The purpose of testing is to validate the implementation and find gaps or deficiencies. Make sure to plan for development time to fix issues that may be discovered so that the go-live date can be met. Testing FinDock in any phase is best done on a full-copy sandbox with exactly the same data and settings as the production org. If you don’t have a full-copy sandbox, inquire with the Salesforce Account Executive about the possibilities.

Test scripts & scenarios

We recommend documenting detailed testing scenarios and validating them with the organization to ensure you cover all aspects of the business processes and day-to-day activities. A typical test scenario should include:

  • A high level overview of the process/functionality being tested, together with a high process level flow.
  • Step-by-step test flow that includes:
    • Context (language, currency, configuration dependencies, etc.)
    • Input conditions (such as the data entered)
    • Sequential test actions
    • Expected outcome
  • Success & failure criteria

We recommend using at least the following tests.

Penny tests

Penny tests are tests with actual cash flow. For instance, these can be direct debit runs for a few individuals with low amounts (hence the name, "penny test"). These tests are essential to confirm cash flow works as expected. Perform penny tests for every payment method configured in the production org. These tests might conflict with other on-going activities, such as direct debit reporting which can’t distinguish between penny tests and real-world production transactions. In such cases, together with the customer organization, contact the bank or payment service provider to discuss how the tests can be run without disrupting normal business.

Scale tests

If the organization performs large payment collection runs, make sure to test for scale. Perform test runs that exceed the largest predicted collection run to ensure the Salesforce org is configured to handle the high volume of record update and/or create actions performed by FinDock.

End-to-end tests

Many individual aspects of the configuration are tested as stand-alone functions during implementation. It is important to test end-to-end processes before go-live. For instance, a payer lifecycle test should cover everything from initial sign-up to upgrades and downgrades, renewal, and end-of-agreement processes to ensure every aspect of these individual functions work together seamlessly.

Go-live preparation

When all configurations are done, it is time to make the final preparation for go-live. At this point, make sure everybody involved in the project is up to speed on the planned go-live arrangements. This includes informing external parties that go-live preparation is now underway and remind them of the planned go-live date. While many configurations can be deployed from your sandboxes to the production org, some items require manual work in the production org. These include:

  1. FinDock packages and versions: check that your production org has all the required packages with the same versions as in your sandbox org. Also make sure the packages and payment methods are activated on your FinDock Setup page in the production org and verify if the packages are correctly configured. Make sure IsTest is disabled when you use any Payment Service Provider.
  2. FinDock general settings: make sure the configuration is complete in the production org prior to go-live. This includes assigning permissions.
  3. Target configurations: target configurations can be deployed between Salesforce orgs. All information is stored in the cpm__target__property__c object. However manually creating the targets in production is usually the easiest way to ensure only the required right targets are in production.
  4. Guided Matching: if you use Guided Matching and have created or adjusted any custom Guided Matching rules, you can copy those rules by copying the data in the cpm__guided_matching_setup__c object.
  5. Page-layout assignments: if you have updated any page-layout assignments, make sure you apply these on the production org as well.
  6. Sanity check: before go-live you should make sure all payment flows and integrations are tested, such as:
    • Direct Debit (file creation)
    • Automated upload of bank reports and bank statement files
    • Payment API integrations
    • Payment schedule runs for every processor, method and account (target)
  7. Initial Sync The first process that runs on ProcessingHub requires an initial data sync. Depending on the number of records, this may take significant time. Save time during go-live day by triggering the initial sync early. You can do this, for example, by uploading an empty bank statement file or running a payment schedule directly after the org data is migrated. When that is finished, you can migrate the remainder of the data as close as possible to your go-live date.
  8. Other planned steps: complete any other planned post-deployment or pre-go-live actions as decided by the implementation project team.

Further guidance

Following the best practices and tips outlined in this article helps your implementation and subsequent go-live to be successful. However, if you would like further guidance and more involvement of FinDock especially at the start of your implementation project, FinDock offers an implementation kick-off workshop. If you’d like to know more, please contact sales@findock.com.

Was this page helpful?