Release Notes - May '22

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

Important Dates:

• Release to Sandboxes: May 01, 2022
• Release to Production: May 29, 2022

New pilot: payment schedule performance

One of the key jobs of payment schedules is to generate installment records, typically for recurring payments (and recurring donations). Generating records is a high-demand job requiring ample processing power. If a payment schedule includes very many new records, the generation step can take quite some time.

With this release, we have made major changes to the generate step in payment schedule runs that should result is significant performance gains. Because these changes impact a important function central to FinDock payment management, we are going to first pilot the changes with select customers. Once we have confirmed the changes achieve the expect results, we will move on to open testing in beta before releasing to general availability.

Core

Deploy Config for custom payment methods

Issue: For historical reasons, the deployment of custom payment methods is dependent on having the SEPA or Bacs extension package installed. Today, it is more likely for custom payment methods to be used in orgs that only have a PSP extension installed, which may lead to errors on deployment.

Solution: With this release, we have removed the deployment dependences, making custom payment methods independent of extension packages.

Recurring Payment Schedule component refresh

Issue: When making a new Recurring Payment Schedule without Auto Run enabled, the Lightning component displaying the forecasted payment schedules should have a Create Payment Schedules button below the list of payment schedules. This button would sometimes not appear, requiring a page refresh to make it visible. It was also possible that certain in-line editing and other indicators would not appear, sometimes requiring double action.

Solution: We identified and fixed the problem causing the issues. The button and other visual indicators should now appear as expected without additional actions.

Payment Schedule processes with timeouts

Issue: When a payment or mandate schedule enters the processing phase, callout messages are sent to ProcessingHub. In some cases, due to the nature of cloud computing, ProcessingHub may not respond within the expected timeframe. This would lead to a timeout error that blocks the schedule process which then would hang and require manual intervention.

Solution: We have made FinDock more resilient to these potential network performance issues. With this release, FinDock now retries the callout to ProcessingHub when a timeout error is encountered. After a set number of retries, if the callout response is still not received, FinDock sets the schedule process to Failed and adds the timeout error in the schedule’s Last Failure Reason field.

Transaction Set Progress component on Transaction Record Page

Issue: When the Transaction Set Progress component is added to the Transaction Record Page, the Recalculate Status Counters option would lead to an error.

Solution: The status counter recalculation is only relevant for Transaction Set records, so to avoid confusion we have removed the option when the progress component is used on the Transaction Record Page.

Update to Generate on recurring level option for direct debit methods

Issue: When activating certain payment methods, FinDock allows you to set reference generation to be on the recurring object level. This setting was visible for Bacs Direct Debit , LSV+ and CH-DD, even though the option is not valid for these payment methods.

Solution: We’ve removed this reference generation option from the advanced settings for Bacs Direct Debit , LSV+ and CH-DD.

ProcessingHub

New automatic process retry

As part of our ongoing development work, we identified certain process errors on ProcessingHub that can be easily resolved simply be retrying the process.

With this release, we have implemented an automatic retry for the creation of Salesforce Bulk API jobs and batches on every push data load task. This should significantly reduce the number of processes that get stuck and require FinDock Support intervention.

CAMT encoding handling improvement

Issue: If a CAMT file does not use the - by the file standard required - UTF-8 encoding (in the entire file), ProcessingHub cannot process the file. The failure reason, however, was unclear.

Solution: We have added a new error message for this type of encoding issue to make it clear that the file encoding is not correct. The new error message is: Invalid XML File: UnicodeDecodeError: 'utf-8' codec can't decode byte xxx in position yyy: invalid start byte.

CAMT.53 date parsing update

Issue: If a date string in a camt.053 is extremely precise, using more than the standard eight decimal places, ProcessingHub could not parse the value.

Solution: We have updated our parsing logic to allow for additional decimal places, so that ProcessingHub can handle camt.053 even if date strings are longer than expected.

PaymentHub file for pain.001 import

Issue: As part of our internal testing, we found that installments from Pain.001 imports are attached to the file level PaymentHub File record when they should instead by attached to the batch level PaymentHub File record.

Solution: We fixed the underlying bug causing the issue so that the installments are attached to batch level as expected.

Pain.008 support for Allied Irish Bank

Issue: The pain.008 file generated by FinDock included optional tags that are not accepted by Allied Irish Banks (AIB).

Solution: We’ve added special filtering that removes the optional tags when the target BIC is an AIB branch.

Giving Pages and PayLinks

Giving Pages custom fields in Safari

Issue: The copy function for custom field names did not work in Safari. Clicking the copy icon indicated the name was successfully copied, but the value was not saved to the computer clipboard.

Solution: The JavaScript used in the custom field component did not work as intended for Safari, so we have added a different solution specifically for Safari.

House name or number character limit

Issue: The House Name or Number field for Gift Aid has a max length of 40 characters. However, the input field on the payment form of Giving Pages (and PayLinks) allowed over 40 characters, which could lead to errors.

Solution: The input field on the payment form now limits the entry to 40 characters.

Bank statement description handling update

With FinDock PayLinks, a bank statement description is shown on the form, but the value was not passed to payment service provider (PSP). This means the description is not available for the payer’s bank statement or the PSP payment page.

To improve FinDock PayLinks behavior here, with this release we have changed how these descriptions are handled. If the selected payment method for PayLinks has a description parameter, FinDock now sets the value for that parameter using the value from the Bank Statement Description field on the installment (which is the text shown to the payer).

Using an image with a paylink

Issue: A URL can be added to an image (e.g. logo) in the FinDock PayLinks configuration, but the URL link was not active in the rendered paylink view.

Solution: We fixed the bug causing this issue so the URL is active now in the rendered view on the PayLink page as expected.

Validation update for FinDock PayLinks

Issue: When opening the PayLinks configuration page, FinDock would show a validation error for personal detail field mappings.

Solution: The personal details validation rules should not be applied to FinDock PayLinks, but only for FinDock Giving Pages. We’ve now excluded the rules so that PayLinks configuration does not display validation errors for things like address and birthday, which are not available in PayLinks.

Gift Aid

Reversal process for Gift Aid installments

Issues: The Gift Aid reversal process changes from our November '21 release introduced the possibility that Gift Aid installments in Pending Reversal may be changed to Cancelled, incorrectly not reversing the Gift Aid claim with HMRC. This would happen when an update was done on a receivable installment that already has a Gift Aid with status Pending Reversal. For example, the parent installment is set to Reversed, triggering the Gift Aid installment to be set to Pending Reversal. After that, the open amount on the receivable installment is changed or the Excluded from Gift Aid checkbox is marked. These actions would automatically change the Gift Aid installment status from Pending Reversal to Cancelled.

Solution: We have updated the logic of when and how to set Gift Aid installments to Cancelled, so that once a Gift Aid installment is set to Pending Reversal, it remains in that status until the installment is selected and processed by a Gift Aid payment schedule. This will correctly reverse the Gift Aid claim with HMRC.

For impacted customers

We recommend checking for Gift Aid installments that were changed to Cancelled after the November '21 release to production (November 14, 2021). You can do this by running a report on Installment History with the filters shown in the screenshot below:

If cancelled Gift Aid installment are found that need to be reversed, you can set the status back to Pending Reversal a couple of ways:

• Use Apex to run a script to query Gift Aid installments with the same parameters as the report and update the status to Pending Reversal.
• If Apex is not an option or there are only a few affected records, you can add Pending Reversal to the Installment object Status field picklist in S and manually change the status of the cancelled Gift Aid installments.

Once all Gift Aid installments that need to be reversed have Pending Reversal status, you can run a Gift Aid schedule to process them.

Update to Excluded from Gift Aid field behavior

Issue: Though it is typically only done by FinDock processes, it is technically possible to change the Excluded from Gift Aid checkbox on a reversed receivable installment from false (unchecked) to true (checked). If this occurred, FinDock would incorrectly change any related Gift Aid installment with Reversed status to Collected.

Solution: We’ve fixed the field handling behavior so that in the above scenario, reversed Gift Aid installments maintain Reversed status. The underlying flow is as follows:

1. Receivable installment is reversed, and Excluded from GA is changed to true. Related Gift Aid installment status changes with status Collected changes to Pending Reversal.
2. A Gift Aid schedule is run. Gift Aid installments with status Pending Reversal change to Reversed.
3. The Excluded from Gift checkbox is changed to false on the receivable installment with status Reversed. The related Gift Aid installment status remains Reversed.

Payment API

Campaign value handling update

Issue: When an installment has a value in Originating Campaign field and the Pay Existing Installment endpoint is called using a message body without a campaign value, the Originating Campaign field is cleared instead of ignored.

Solution: We correct the API behavior so that the Originating Campaign field is only updated if a campaign value is passed in the API call.

Notification timing improvement for open communities

Issue: Open community pages implement a user switch with the FinDock Payment API to handle authorization requirements. The user context switch is a queued job which could lead to timing issues. If the payment notification from the PSP arrived before FinDock finished processing the payment intent, FinDock could not match the incoming payment notification.

Solution: We have updated the code controlling the timing of the various message processing tasks. Now inbound payment notifications are not processed until payment intent jobs are completed and the associated inbound reports are created.

Enhanced logging

To improve debugging and troubleshooting of API-related issues, we have added logging for outbound webhook failures. FinDock now creates a log record with the relevant data for each failed webhook (which is an implementation of queueable Apex).

Guided Matching

Process Installment details in progress view

Issue: In the Guided Matching progress component, the Process Installment step did not correctly show the currency of the installment. The component always presented the Euro symbol, while the amount and currency code was correct for the actual currency.

Solution: We have fixed the issue so that now when new records are processed, the Process Installment step shows the correct symbol of currency used to pay the installment.

Update for Bollettino Postale reconciliation

Issue: For Bollettino Postale reports without images, FinDock incorrectly parsed the amount from the raw message. The Guided Matching Regular Expression rule assumed that the last two digits were always cents and did not allow for amounts with decimals. For example, 0000000550 was parsed as 5.50 (instead of 550), and 000000089.8 would fail.

Solution: We have updated the managed ruleset for Bollettino Postale to accept decimals which are used in reports without images to denote cents.

Bacs

Mandate Id data quality

Issue: Running a Bacs Manual payment schedule would fail if a Mandate Id value uses an underscore. The error (shown on ProcessingHub Manager): Invalid Standard Record!

Solution: Underscores are not allowed according to Bacs Direct Debit mandate reference rules, so we have added an explicit rule in our Data Quality component to check for underscores in Mandate Id values (in payment or mandate schedule runs). These records are then flagged for fixing before the schedule is processed.

Support for 18-character references

For historical reasons, FinDock has generated a 7-character value for Bacs DD reference Ids. While this was sufficient for most orgs, large data volume (LDV) orgs need longer references to ensure uniqueness. With this release, we are adding the option to generate 18-character references (the max. length for Bacs DD) to better support LDV orgs and ensure uniqueness for all orgs large or small.

The new option is controlled by a managed custom setting that is enabled by default for new installations. If you have an existing FinDock installation and would like to use the longer reference values, please contact FinDock Support.

Buckaroo

Support concurrent use of Buckaroo packages

Issue: Buckaroo can send notifications in two formats: HTTP Post and JSON. FinDock works with HTTP Post, but Buckaroo has its own package for Salesforce that requires the JSON format. If this is installed alongside the Buckaroo for FinDock payment extension, either FinDock or the Buckaroo package could not properly handle the format of incoming notifications required for the other.

Solution: We’ve added support for parsing the different notification formats that can come from Buckaroo, so that FinDock can handle both HTTP Post and JSON. This ensures FinDock can work side-by-side with Buckaroo's own package in the extremely rare case this is required.

Batch fetch of notifications with ampersand

Issue: In our March '22 release, we updated how Buckaroo notifications are handled to properly parse payload values with an ampersand (&). This fix was for individual notification handling and did not correct the same parsing issue for batch fetching of notifications. This batch is implemented to sweep installments with a Pending status and check its the status with Buckaroo.

Solution: We have now also updated FinDock’s batch notification handling process to correctly parse ampersand in payload values.

Payment update notifications from Buckaroo

Issue: In our March ‘22 release, we changed how Buckaroo notifications are handled. This resulted in payments not getting updated in FinDock when the push settings in Buckaroo were configured for GET rather than POST.

Solution: We’ve updated FinDock WebHub so GET messages are handled correctly as they were before the March '22 release. We recommend checking for discrepancies between the status of payments in Buckaroo and installments in Salesforce (since the March '22 release). If you see installments with Pending status that are completed payments in Buckaroo, you can either manually push update notifications from Buckaroo Payment Plaza or schedule the sweeper batch in FinDock.

Digital signatures

Issue: FinDock was running into errors with Buckaroo digital signatures in a couple of instances. In orgs that were not multi-merchant, FinDock was incorrectly encoding and decoding the ampersand sign. In addition, if the signature used uppercase (a setting in Buckaroo Payment Plaza), FinDock could not calculate the signature correctly. These issues would prevent updating installments in FinDock based on the latest notifications from Buckaroo.

Solution: We’ve updated our handling of Buckaroo signatures to resolve these issues. The ampersand is now interpreted correctly regardless of multi-merchant status, and signatures can use upper or lowercase letters, so no Payment Plaza setting changes are needed. To be sure all your installments are up to date, you can schedule the optional sweeper Apex job.

Status code handling update

Issue: Buckaroo status codes for payments that are not collected (e.g. failed, timed out, reversed, etc.) would lead to FinDock throwing technical errors like Attempted to upsert a null list. The installment status was updated correctly, but due to how FinDock commits payment record upserts, it would fail if there is no payment entry from Buckaroo.

Solution: If the status code from Buckaroo indicates no payment, FinDock now does not try upsert a payment record.

SIX Saferpay

New support for (migrated) credit card aliass

With this release, we are introducing support for aliases to be used with recurring credit card payments processed through SIX Saferpay. This is part of the Secure Card Data capabilities offered by SIX Saferpay. A new checkbox field (Is Alias) has been added to the Mandate object with this release that is used to make the distinction between alias and transaction reference Ids from Saferpay. When you run a payment schedule, FinDock handles the callouts as required for both old and new mandates based on the Is Alias checkbox. Existing recurring installments (where Is Alias is false) continue to work as normal.

The FinDock integration to Saferpay now also includes an extension setting called Use Secure Alias Storage to enable RegisterAlias in all initial recurring payment callouts. This stores the alias on the Saferpay side. In FinDock, the alias is stored on the mandate reference field.