Release Notes - February '21

We are happy to present the FinDock February '21 Release!

Important Dates:

• Release to Sandboxes: February 07, 2021
• Release to Production: February 21, 2021

FinDock Giving Pages moves to GA

We're very proud to announce that FinDock Giving Pages will be Generally Available with this release. What started many months ago, end of June '20, with a closed pilot has steadily grown and matured and we're very happy, thanksfull and proud on the result. Many thanks to all our partners and customers who have been working with us on FinDock Giving Pages. Your feedback and testing has made it possible to reach this final step of making Giving Pages Generally Available to all FinDock customers.

For those of you who have already been using Giving Pages, we have more than a few improvements, enhancements and fixes to announce.

New out-of-the-box FinDock Giving Pages templates

Based on learnings & feedback during the pilot and beta phase, we have designed and implemented two new templates. These templates replace the old templates, without breaking the old templates.

The templates are fully responsive and render beautifull on all common screen sizes, browsers and devices, both desktop and mobile.

Two templates are now available:

• Activate: a large, page-width hero image with a title and subtitle set above a donation form with space for copy on the left.
  
• Excite: focused on just the donation form with a full-height image on the left, without distraction.
  

Templates come with example images, text and titles out-of-the-box

It's our goal to make it very easy to create a beautiful page based on the two new templates. Therefore we have included example images, text and titles in the templates. These assets & texts are included when you first create a page from a template. Pictures include instructions on the optimal size in pixels. The payment form will also have some example values included.

All example assets, text & values can be edited. But this gives you the ability to create a tryle beautifull pages, for example the two screenshots above, in minutes.

FinDock Giving Pages support for Google Analytics

We’ve added a new setting to Giving Pages that enables collecting traffic data from pages into your Google Analytics account. Simply add your Google Tracking ID to the page settings, and FinDock generates the necessary JavaScript to send data to your Google Analytics account and property. For instructions on how to find your Tracking ID, see Google support. This new Google Analytics settings is available for both new and existing pages in your org.

Visit our Knowledge Base for updated Giving Pages set up instructions.

Payment form Thank-you and Error page

We’ve upgraded the customization options for the thank you and error pages that are part of the Payment Form setup. The new options allow you to adjust font appearance and add images to the pages. Here is what the new options look like:

Smaller enhancements and bug fixes

500 error results in frozen page

Issue: If the GET /PaymentMethods call returns a 500 error, the page would freeze and no longer function.

Solution: 500 errors are now redirected to the expected failureURL.

IBAN validation and transformation

We’ve added new transformation rules to handle IBAN values that are valid on front-end user entry, but are otherwise invalid for Salesforce and the FinDock Payment API. The new transformation rules remove empty spaces in the IBAN value and convert lower case letters into upper case letters.

Address handling update for Payment Form

Issue: Previously, the Payment Form address option provided two fields - one for street name and one for street number - for donors to fill in. These two fields were concatenated in Salesforce, but the ordering of street + number did not work for all countries.

Solution: The address entry on the front end of the Payment Form only has one field, so donors can write their street address as needed. The address value will be stored in one Salesforce field based on your Personal Details mapping.

New page & domain deletion flow

Issue: Previously, subdomains could be deleted even if there were existing pages for that domain. These pages would appear again when a new subdomain is created, but they could not be used. You could delete pages, but it was not possible to delete the last page as this was automatically set as the default page for the domain.

Solution: We’ve changed the domain and page deletion logic so that you cannot delete a subdomain if there are any pages associated with it. All pages under a domain need to be deleted, including the last (default) page, before you are allowed to delete your subdomain. After all pages are deleted, the subdomain can be deleted. When a new subdomain is created, it starts with a clean, empty list of pages.

Page Builder: new targets not visible in payment settings

Issue: New targets added to FinDock were not available in the list of targets under the Payment Form settings for existing pages.

Solution: We identified and fixed the bug causing this issue. The list of target options in the Payment Form settings for both new and existing pages now shows all available targets.

Page Builder: enhanced amount configuration

We’ve added new options and additional customization features to the Amounts & Frequency settings for the Payment Form configuration.

Default payment period: you can now select which payment period (currently one-time or monthly) is shown to page visitors when they fill in the payment form

Hide decimals: new toggle for showing or hiding decimals places in the donation amounts for page visitors

Open Amount error messages: you can use the default texts from FinDock or create your own.

Page Builder: personal details dropdown lists ordering

Issue: The dropdown lists in the personal details mapping table where sorted chronologically by CreatedDate instead of by name, making it difficult to find certain values in the lists.

Solution: We have reordered the lists to be alphabetical according to name.

Page Builder: user interaction improvements

Several of the Page and Payment Form settings in the Page Builder need to be properly filled in for a page and form to work correctly. This includes, for example, page metadata, at least one payment method is selected, a target is defined for direct debits and so forth.

To ensure these settings are filled in (and saved), we’ve added a number of new prompts and messages to help guide users when creating new pages.

Page Builder: unsaved changes warning

In the Page Builder, we’ve added a new prompt if there are unsaved changes when you try to publish the page. The message gives you the opportunity to either cancel publishing or continue with saving the changes and publishing.

Page Builder: new info texts and tooltips

To make it easier to understand the Giving pages builder functionality, we have added info text and tooltips to many fields.

FinDock Core

Payment Intent rule for Guided Matching overwritten

Issue: With every release, the Payment Intent rule for Guided Matching was updated, overwriting customizations and returning the rule configuration to the default setup.

Solution: We changed the update process so that this rule is not overwritten if there have been any modifications done to the default rule configuration.

Recurring Payment Schedules: missing preview on edits

Issue: When adding business hours for weekly or monthly recurring payment schedule setup, the preview of the schedule was not generated as expected.

Solution: We identified the bug causing the issue and resolved it. Previews are generated as expected now.

Recurring Payment Schedules: automatic BACS processing date calculation

We’ve added the automatic calculation now so that the Bacs processing date is calculated according to Collection Date (taking business hours and holidays into consideration) and added to the generated payment schedules accordingly.

Recurring Payment Schedules: payment journey lookup not mapped correctly

Issue: If there is a payment journey value set on the recurring payment schedule, it was not added to the generated payment schedules.

Solution: We identified the source of the bug and fixed it. If payment journey is defined on a recurring payment schedule, it is now reflected in the generated payment schedules.

Guided Matching: auto-retry on locked rows enhancement

Issue: Guided Matching uses auto-retry when locked row exceptions are encountered. If the locked row happens to be the on the main Transaction or Inbound Report record, auto-retry could lead to already executed rules being re-run and causing unexpected results.

Solution : The Guided Matching auto-retry functionality now checks the type of record which caused the locked row exception. If the type is Transaction or Inbound Report, the Guided Matching job is not retried. Instead, a clear error message is generated, which can be found under Setup > Apex Jobs. The affected records remain in the “Processing” state when this error occurs.

Manual Review: split payments to different campaigns

Issue: In Manual Review, if you split payments to different campaigns, FinDock would save the last selected campaign to all related installments.

Solution: We fixed the mapping logic so that FinDock always maintains the individual campaign mappings per installment as it does with payments.

ProcessingHub

MT940 file support expanded

We’ve added specific support to our MT940 file parsing for specific banks/BIC's from BancoPosta (Italy), Barclays (UK) and Triodos Bank (Belgium).

Improved locked row exception handling

Issue: ProcessingHub automatically retries create and update operations when locked row exceptions are encountered. However, the retries were only for master records and ignored locked row exceptions on records updated via triggers.

Solution: We have updated the retry mechanism so that retries are attempted for all possible locked row exceptions.

Incorrect account extracted from CAMT

Issue: In most cases, the the IBAN of the debtor can be extracted from a specific element within the CAMT file. However, in some cases this location is not specifying the debtor account, but rather the creditor account. The debtor account is instead a BBAN value that is stored in a different element within the CAMT file. FinDock parsing rules did not account for this edge possibility and always used the IBAN in the file.

Solution: We have updated our CAMT parsing rules to include extracting BBAN values which may be for the debtor or creditor accounts. FinDock first looks for IBAN values and checks these values against the IBAN of the target to determine the IBAN/BBAN of the debtor.

FinDock for NPSP

Close date updated incorrectly

Issue: When the status of an opportunity is changed to closed-won, the close date on the Opportunity is updated to today, different then standard SFDC behavior. This occurs when the Last Collection Date is empty.

Solution: We have changed the relevant data processing logic so that Last Collection Date from Installment is used to set the close data on opportunities only if the Last Collection Date field is not empty. If Last Collection Date is empty, no changes are made to the opportunity close date, and standard SFDC behavior applies.

Status mapping ignored for forward-to-source

Issue: The forward-to-source rule used in API calls, Guided Matching and Manual Review, ignored the status mapping in FinDock for NPSP settings when the status of an installment was manually changed. The status of the related opportunity was hardcoded (to posted status) and did not allow for mapping.

Solution: We have introduced a new custom setting NPSP4Hub_Settings__c and added checkbox for this to the FinDock for NPSP general settings. The new option, “Use Status Mapping in Forward To Source,” is selected by default for new installations. For existing installations, this option is not enabled to ensure backwards compatibility with current org settings. When this new option is selected, FinDock checks first if there is a status mapping. If not, the related opportunity is set to the default NPSP closed opportunity stage setting. If this default setting is not defined, FinDock uses sets the status to ’Posted'.

SEPA

Support for UK bank processing

Issue: The SEPA Direct Debit Core scheme has been updated to take into account the status change of UK banks due to the regulatory impact of Brexit. Collection files (pain.008) now require additional information if the debtor is using a UK bank account. Specifically, the collection files need to include the full address of the debtor and the BIC code of the debtor bank.

Solution: We’ve updated the field mapping for pain.008 file creation to include BIC and address fields on the Payment Profile object. These fields will only be mapped if the IBAN of the payment profile record indicates the debtor is in the UK. FinDock does not validate the values for BIC and address fields as part of this mapping. Customers need to ensure the fields are correctly filled in for pain.008 compliance (of UK collections). Please also note that for this collection scenario, the country field on Payment Profile needs to use the Alpha-2 ISO country code (e.g. "GB" for United Kingdom) for the pain.008 to be valid.

SEDA: same mandate recurring in one file not processed

Issue: If the same mandate appears in an SEDAD file more than once, processing the Inbound Report record would fail.

Solution: Mandates are normally not repeated in a SEDAD file. However, there are cases when, for example, a bank amends or cancels a mandate on the same day (or very soon after) it was created. These cases are unusual and need further attention. With this release, if a mandate is found more than once in a SEDAD file, the Inbound Report record in question is set to manual review.

Buckaroo

Duplicate transactions with Buckaroo and FinDock Payment APIv1

Issue: If the redirect URL for a Buckaroo payment was opened more than once (e.g. the browser tab was refreshed), this would create additional transactions in Buckaroo.

Solution: We added a new parameter to the redirectURL that prevents multiple transactions from being created at Buckaroo if that URL is used more than once.

Mollie

Duplicate transactions with Mollie and FinDock Payment APIv1

Issue: If the redirect URL for a Mollie payment was opened more than once (e.g. the browser tab was refreshed), this would create additional transactions in Mollie.

Solution: We added a new parameter to the redirectURL that prevents multiple transactions from being created at Mollie if that URL is used more than once.

Axerve

Error message handling updated

Issue: The message content and code for Axerve errors were being added to the same field in Salesforce, installment.cpm__Last_Failure_Reason__c. Based on customer feedback, this approach made certain business logic unnecessarily complex.

Solution: The error code and error message are now stored in separate fields. The error code is stored on installment.cpm__Last_ReasonCode_Received__c, and the error message is stored on installment.cpm__Last_Failure_Reason__c.

Redsys

Redsys integration now with FinDock Payment API support

We have upgraded the Redsys for FinDock integration to support the FinDock Payment API based on the request submission form integration option from Redsys. This new implementation supports both one-time and recurring credit card payments taken by Redsys directly into Salesforce.

Incorrect handling of card expiration date

Issue: In the Redsys ProcessingHub process credit cards were considered expired on the first day of the expiration month instead of the last day of the month.

Solution: We fixed the bug causing the incorrect interpretation of the expiration date. Now, for example, if the expiration date is 1/2020, the card is valid until 1/2/2021 as expected, instead of being considered expired already on 1/1/2021.

Endpoint setting misaligned

Issue: The endpoint setting in the Redsys for FinDock extension configuration page was hard coded to point to the Redsys test environment.

Solution: We updated the code so that the endpoint value entered in the FinDock configuration page is used for the Redsys integration.

Checkout.com

Checkout.com integration compatible with FinDock Payment APIv2

With this release, Checkout.com for FinDock is compatible with version 2 of the FinDock Payment API.