Release Notes March '22

We are happy to present the FinDock March '22 Release!

Important Dates:

• Release to Sandboxes: February 27, 2022
• Release to Production: March 27, 2022

GoCardless Instant Bank Pay (beta)

With this release, FinDock introduces support for GoCardless Instant Bank Pay for beta testing, a new offering from GoCardless to instantly setup (authorize) and collect one-time payments using open banking.

The FinDock integration for Instant Bank Pay currently enables one-off payment collection in the UK only. For details on which UK banks GoCardless uses for Instant Bank Pay, please refer to their FAQs.

This new FinDock capability does not change how the GoCardless extension is used to collect Bacs Direct Debit payments.

SIX Saferpay supports cryptocurrency

With this release, we are adding cryptocurrency as a payment method in our SIX Saferpay payment extension package. The new payment method currently supports one-time payments using Bitcoin or Etherium.

SEPA Credit Transfer to GA

Thanks to all our customers who participated in the pilot and beta phases of our SEPA Credit Transfer (SCT) feature rollout. With this release, FinDock support for SCT is now generally available to all customers.

Guided Matching

Improved Guided Review experience

The Guided Review experience has been fully redesigned to:

• Handle reconciliation scenarios where one transaction impacts multiple installments
• Improve the UI of the Guided Review component

These changes mean you can now handle split payments with Guided Matching. Until now this was the last scenario that used to require Manual Review. For further information, please visit our Knowledge Base.

Automatically find and match multiple Installments

With Guided Matching it's now possible to automatically find and match a single transaction to multiple Installments. A typical example of how this is helpful is when a customer does a wire transfer and includes multiple invoice numbers in the description. Using the new functionality you're now able to select the different invoice numbers, find the corresponding Installments in Salesforce and automatically match all those Installments to the transaction.

Automatically ignore records

Guided Matching now supports automatically ignoring a Transaction or Inbound Report record. You can create a Constant rule type for the Status field with the constant value "Ignored." For the entry criteria, simply define your required triggers for the rule. You can ignore the standard is entry criterium, as FinDock does not enforce this anymore on the Status field.

When your Constant rule is implmented, FinDock simply stops Guided Matching when it comes across a Transaction or Inbound Report required with status "Ignored." This is useful, for example, if you want Guided Matching to skip records for internal payments. This can also be used if you want to reconcile only credit transactions, for instance.

Regex rule can return multiple results

For Regular Expression rules, we have added multiple results support for Regular Expression rules on String fields. A new “Multi-Value?” checking is added to the setup. If checked, all matched patterns are returned comma separated. If the total string is longer than fits in the Result field, only what fits is stored.

Multiple results handling for Query rules

In Query rules used for Installment lookup, we have added new multiple results handling. When a query rule is defined on the Installment lookup field, there are two additions:

• A “Multi-Value?” checkbox
  The checkbox appears to the right of the first query criterion Transaction Field. If checked, the value in the Transaction Field is interpreted as a comma-separated list of values, and the query uses any of these values.
• A new “Take All” option for Multiple Results Strategy
  If this option is selected and there are multiple results, the query result is written in field “Multiple Installment Ids” as a comma-separated list of records, and the Installment lookup is left empty. If there is just one result, the Installment lookup is filled with the result and “Multiple Installment Ids” is left empty.

This new functionality works for the Installment lookup on both Transaction and Inbound Report. In the Guided Matching Progress component, multiple results are displayed as shown below:

New operators for entry criteria

Entry criteria for any rule type now support new comparison operators. The new operators are:

• greater than (>)
• greater than or equal (>=)
• less than (<)
• less than or equal (<=)

These operators are only available on Number, Percentage, Date and DateTime fields.

New operators for Query rule type

The new comparison operators in entry criteria are also available for the Query rule setup. The new operators are:

• greater than (>)
• greater than or equal (>=)
• less than (<)
• less than or equal (<=)

These operators are only available on Number, Percentage, Date and DateTime fields.

New Create Campaign Member rule type

With this release we are adding a new Guided Matching rule type, the Create Campaign Member rule. This new rule can be used to create Campaign Member records much like the Create Record rule type does for Contact (and other objects). For further information, please refer to our Knowledge Base.

New Find Duplicate rule type

With this release we are adding a new Guided Matching rule type, the Find Duplicate rule. This new rule can be used for deduplication using any reference field on Transaction and Inbound Report records. For further information, please refer to our Knowledge Base.

New rule type selector

When creating a new rule, we have added a new type selection step, pictured here:

The book icon in the right-top is a link to our Knowledge Base article about rule types.

Click on any of the rule types to create a new rule. Once a rule type has been selected, the rule type cannot be changed from the rule editor.

Progress Component update

We’ve updated the Guided Matching Progress component to make the Show All Rules and Retry All Rules actions more easily accessible. These two actions used to be present as buttons on the top and bottom of the component. Now they are both available from a drop-down list at the top of the component.

Rule setup validation

Issue: The Guided Matching rule setup is stored as JSON in Salesforce. The content is in a long text field on the Guided Matching Setup object. If this field is edited directly, and the resulting content is no longer valid JSON, Guided Matching could not function.

Solution: We have implemented a validation check on the rule setup when the rules are loaded. If the JSON is not valid, FinDock throws an exception with the error message: Value in the Guided Matching Setup Rules field must be valid JSON.

Giving Pages

Extended options for URL parameters

We are adding more capabilities to URL parameters for Giving Pages. The query parameters in the URL can be used for:

• Pre-filling fields on the donation form
• Sending additional (hidden) data to Salesforce

In addition to supporting all payment method parameters, the queries enable you to:

• Set donation amounts
• Set narrative labels
• Set default donation frequency
• Set currency

For further information, please refer to our Knowledge Base.

New merge fields capability for default values on any field

With this release we are adding field merging support for default values. This can be used in default values for input fields and payment method parameters (that are text fields). The merged field notation follows standard Salesforce practices. For example, the default value Donation from {!firstname} where firstname = "John" returns "Donation from John."

Some important points to keep in mind in merge fields:

• If the field to be merged (in the example, firstname) is not populated, an empty value is returned (in the example, it would be just “Donation from”)
• If the field to be merged does not actually exist, a non-blocking warning is triggered indicating you are trying to use a merge field which does not exist.

Ability to clone an existing Giving Page

We received a lot of feedback on how hard it was to maintain and create several, similar pages. To make it even easier to create new pages, we have added a cloning option to Giving Pages. With this option you can copy an existing Giving Pages page configuration to use as a baseline and quickly create a new page.

Ability to only offer one-time or recurring payment options

With this release, we are adding new show/hide toggles for the one-time and recurring payment frequency configuration on Giving Pages payment forms. Prior to this release, payment forms would always present both one-time and recurring frequency options to page visitors.

Loading speed optimization

Issue: The payment method icons on the payment form (method picklist) take too long to load, leading to a noticeably slow user experience for payers. The slowness is in part caused by payment method icons being somewhat large.

Solution: We’ve reduce icon sizes and implemented some page loading optimization actions to provide an overall faster load time.

Pages restored after WebHub reconnect

Though not recommended, on occasion it may be necessary to change the integration user account for the FinDock WebHub connection. Disconnecting WebHub renders certain FinDock features, including Giving Pages, non-functional. For this reason, it has not been possible to disconnect WebHub if you have any Giving Pages page configurations.

With this release, we are making Giving Pages more resilient to allow WebHub disconnections. Pages still become inaccessible when WebHub is disconnected. However, once you reconnect to WebHub, FinDock automatically restores all pages, including URLs.

Defaults for required payment method parameters

With this release we are making a minor change to the default settings for Giving Pages payment method parameters. In most cases, if a parameter, like IBAN, is required by the payment method, the default settings in the Giving Pages payment form configuration have both the required toggle and visibility toggle on.

However, if the payment method has a required Description parameter, the default visibility setting is toggled off. This is because description parameters are typically for internal use and do not need to be shown to payers.

In addition, previously it was not possible to toggle off visibility for required parameters. Now this is possible for any required parameter.

Multi-merchant support

Issue: When a single-merchant payment processor is configured in Giving Pages, everything works as expected. However, if multi-merchant is enabled for that payment processor, modifying existing Giving Pages pages that use that processor would break the payment form.

Solution: We’ve added some additional checks for multi-merchant support to prevent configuration-related issues on payment forms.

Decimal separator

Issue: The decimal separator, comma (,) or full-stop (.), was not updated correctly based on locale. This impacted both Giving Pages and PayLinks.

Solution: We found the bug causing this issue and fixed it so that the correct decimal separator is displayed for the locale.

Core

Payment and Mandate Schedule auto-refresh of path component

Issue: When using the payment or mandate schedule path component, the auto-refresh option (checkbox in upper right corner of schedule) was not enabled by default.

Solution: Because refreshing is a common and useful way to follow schedule progress, auto-refresh is now enabled by default.

Mandate schedule validation update

Issue: The current Bacs mandate validation rules require surnames to be no less than three characters. This resulted in valid 2-letter surnames being rejected.

Solution: We have updated both the inline validation rules and the data quality rules to allow surnames with two or more letters.

Mandate schedules with no selected mandates

Issue: Mandate schedules that have no mandates after generating are set to Failed. If the schedule is manually set back to Generated, the schedule can be set to Processing again, which causes it to eventually freeze. This issue only affect mandate schedules that are run manually. Automated schedules (using auto-run and auto-create) are set to Done if no mandate records are selected by the given schedule.

Solution: If a mandate schedule fails because no mandate records were selected, it can still be set back to Generated. However, with this release, FinDock automatically sets the schedule to Failed, similar to Payment Schedules.

Recurring Payment Schedule settings

Issue: As part of our internal testing, we uncovered two minor issues affecting weekly recurring payment schedules:

• It was not possible to set the Selection Day Strategy to be the end of the month (though it should be possible).
• When the recurring schedule did not use auto-create, it was possible to generate schedules with run dates in the past which should not occur.

Solution: We identified and fixed the bugs causes these issues so that weekly recurring payment schedule configuration works as expected.

ProcessingHub

Fix retry from ProcessingHub Manager

Issue: ProcessingHub uses the Salesforce Bulk or Rest API to transfer data to Salesforce. If there is a data load error while ProcessingHub is using the REST API and the processes is retried, the process would fail with the error: Undefined index: externalIdFieldName.

Solution: We identified and fixed the underlying issue. Retrying after a data load error when the REST API is used is now carried out as expected.

Handling long house name or number field values

Issue: FinDock used a limit of 15 characters for House name and number field on Payment Profile. In some cases, this limit was not long enough, and that prevented ProcessingHub from syncing the relevant installments.

Solution: We’ve updated to limit to match the Salesforce limit of 255 characters.

Installments with missing due date

Issue: When a payment schedule selects an installment that has an empty due date, the ProcessingHub process would fail with the following error message: Call to a member function format() on null.

Solution: FinDock now checks the due date on every selected installment of the payment schedule. If one or more installments have an empty due date, the ProcessingHub process is rejected with the following message: Installment(s) found in this payment schedule with empty due date fields. In addition, the installments with empty due dates are set to Failed with the following message: Due Date field is empty. Please add a due date or remove the installment from the payment schedule.

CAMT file entries without TxDtls tag

Issue: When FinDock parses CAMT files, it expects NtryDtls tags to include TxDtls tags. Some CAMT files, however, may include entries with NtryDtls but without the TxDtls tag. When the TxDtls tags are missing, FinDock would not save these entries to the transaction records, resulting in incomplete data.

Solution: We have updated our CAMT parsing rules to map data of entries even when they do not include a TxDtls tag.

CAMT.053 processing of empty IBAN/BBAN

Issue: ProcessingHub checks for IBAN vs. BBAN values to determine if it needs to extract data from credit or debit elements. If both IBAN and BBAN are empty, ProcessingHub would incorrectly assume the record is a credit and ignore address fields.

Solution: ProcessingHub now correctly extracts address fields even if there is no IBAN or BBAN value available.

CODA file upload special characters

Issue: CODA files containing special characters may be blocked from importing with an unsupported file error from ProcessingHub.

Solution: This issue was caused by how file types are determined by ProcessingHub when uploaded. While ProcessingHub could parse special characters within the CODA file, if they appeared in the initial lines of the file that are used to determine the file type, ProcessingHub could not recognize the file. We’ve now updated the file recognition step to support special characters as well.

Gift Aid

Gift Aid reversals for refunded or canceled donations

Issue: If the status of installments with related claimed Gift Aid installments is manually changed to Reversed, Refunded, Rejected or Cancelled, the claimed Gift Aid installment is reversed. However, due to the way FinDock handles the Gift Aid Claimed checkbox and how the status of main installment (donation) is used, a new Gift Aid installment was incorrectly created for the closed installment (donation). In addition, FinDock would incorrectly update a reversed Gift Aid installment status if the Exclude from Gift Aid checkbox value on the main installment is changed after reversal.

Solution: We have updated Give Aid installment status handling as follows:

• The Is Eligible for Gift Aid check automatically excludes installments with status Reversed, Refunded, Rejected or Cancelled.
• If Exclude from Gift Aid is changed from false to true, the status of a related Gift Aid installment is changed to Cancelled only if the Gift Aid installment is not already in a closed state (Reversed or Collected).
• If Exclude from Gift Aid is changed from true to false, the status of a related Gift Aid installment with status Pending Reversal is changed to Collected.

Bacs

Updated mandate reference Id generator

Issue: Generating very large numbers of Bacs Direct Debit mandate references could lead to duplicate Ids due to the way the values are generated.

Solution: We’ve updated the algorithm used to generate mandate references to incorporate variations that make it practically impossible to end up with duplicate values.

Buckaroo

Support for Bancontact

With this release, we have added Bancontact as a supported payment method in the Buckaroo for FinDock payment extension package.

Notifications with ampersand

Issue: If a Buckaroo notification contains an ampersand (&) in a payload value, such as “Digital Marketing & SEO,” FinDock could not correctly parse the notification.

Solution: We’ve updated how Buckaroo notifications are handled so that the complete payload value is parsed as expected even when it contains an ampersand.

Notification processing update

Issue: In certain circumstances, different notifications about the same transaction may arrive to FinDock at nearly identical times. This can lead to duplicate record creation, such as double payments or duplicated payment profiles.

Solution: To help mitigate the chances of duplicate record creation, we have changed some of the default actions FinDock uses when processing incoming Buckaroo notifications.

Mollie

Collection date handling with delayed processing

Issue: If a payment notification from Mollie is delayed (for any reason) and not processed on the same date as it arrived, FinDock incorrectly sets the collection date to today (system date) instead of the actual collection date.

Solution: The issue was caused by a problem in how Guided Matching handles retrying the notification processing. This has now be resolved so that the collection date is recorded correctly in Salesforce even in the event of a processing delay.

NPSP

Empty Amount on Installment or Opportunity

Issue: When the amount on an NPSP Opportunity or Installment record cleared instead of updated to zero (0), regardless of how, an error occurs when you try to update the amount on the Installment record to a number again. The errors is caused by the background calculation of the installment amount that expect only numerical values.

Solution: We updated the amount calculation formula to handle cases where the “old” amount is an empty value (null) so that the new amount is a correctly determined numerical value. In addition, if you clear the Amount Open, FinDock checks for payments and deducts the sum of the payments from the installment amount.