Release Notes - January '23

We are happy to present the FinDock January '23 Release!

Important Dates:

• Release to Sandboxes: January 02, 2023
• Release to Production: January 29, 2023

GoCardless support expanded

We are happy to announce that our GoCardless for FinDock payment extension now supports two more direct debit schemes in addition to Bacs Direct Debit. With this release, we have added Bg Autogiro, a direct debit scheme for the Swedish market, and SEPA Direct Debit. This includes adding multi-currency support to the GoCardless for FinDock payment extension.

As part of our new support for SEPA Direct Debit and Autogiro through GoCardless, we have added new data quality validation rules for payment collection and mandate management. Learn more about FinDock Data Quality and check out the new rules in our spreadsheet.

With GoCardless direct debit collection, the payer needs to have a mandate with GoCardless. For individual one-time or recurring direct debits, the mandate is managed as part of the process. However, there are cases, such as in-person donation drives, where you have many mandates to create.

Rather than registering each mandate manually, you can now create or cancel mandates in bulk through mandate schedules.

We have have made some important fixes for GoCardless payment and mandate handling in this release, including:

• When a mandate is set up through the FinDock Payment API, FinDock now sets the mandate status to Pending registration acceptance instead of Pending registration (which was not the expected status).
• We fixed a bug that caused incorrect processing of payments and mandates when multi-merchant is enabled.
• Some payments that failed on creation with Gocardless were incorrectly set to Pending processing status. FinDock now sets the records to Failed and adds the error to the Last Status Reason field.

Core

New picklist field for mandate schedules

To enable broader support for direct debit processors, we’ve added a new dependent picklist to Mandate Schedule and Recurring Mandate Schedule. The dependency tells FinDock which payment processor can be used for the selected target on the schedule. This change is rolled out automatically for all orgs.

However, for some existing orgs where (recurring) mandate schedules are already in use, the change may temporarily block Deploy Config operations. If this occurs, a straight-forward, one-time action is needed to unblock configuration deployments. We’ve created special instructions to resolve the error should it arise and included a link to this article also as part of the Deploy Config error notification.

Logging for queueable framework used with mandate and payment schedules

Issue : With the November '22 release, we rolled out the new queueable framework for mandate and payment schedule processing (LDV performance enhancement). Since then, processing errors were not captured as expected, resulting in Log records without the error details.

Issue: We identified the bug causing the issue and fixed it so that logs are created as expected and available for troubleshooting.

LWC update for component error with mandate and payment schedules

Issue: With the new queueable framework, some customers were getting a random popup error (pictured below) when running mandate and payment schedules. The error is not related to the schedule run and can be dismissed.

Solution: The error is caused by how the LWC determines a dynamic label used on the schedule layout. If the data is not available yet the component could not select the label. To avoid this error, the LWC will now use a fallback label if the data for the dynamic label is not ready yet.

FinDock Heartbeat resilience to failed jobs

Issue : If the heartbeat scheduler contains several different jobs and one job fails (for any reason), in some cases the remaining scheduled jobs are not executed.

Solution : We’ve implemented a method to isolate failed jobs that allows the following jobs to still execute on schedule.

New rate limit framework for PSP integrations

Recently, FinDock introduced a new queueable framework to significantly improve performance of certain processes, like running payment schedules. The performance enhancements are for all customers, but are particularly beneficial for large data volume (LDV) orgs.

With the improved performance, however, FinDock is more likely to exceed the payment processing capacity of PSP APIs. Therefore, we have built a new rate limiting mechanism within the queueable framework to enable artificially slowing down processes as needed. The rate limiting itself is part of the FinDock Core package. PSP-specific limits are implemented in the relevant payment extension package.

For now, we have implemented rate limits for GoCardless. Limits for other payment processes will be evaluated as needed.

New system exception handling for queueable framework

Issue: The new queueable framework FinDock uses for mandate and payment schedules silently fails when Salesforce system exceptions are encountered. For example, a poorly performing query could cause a specific queueable to fail due to a system timeout error. The system exception prevents FinDock jobs from continuing, and customers could not see from FinDock that processes are stuck.

Solution: The queueable framework implementation has been expanded to explicitly handle system exceptions. These types of errors are now caught and trigger retries as with other error types. If the retries are unsuccessful, the error is properly reflected on the impacted jobs and processes. For example, the payment schedule record is set to Failed and the system exception is added to the Last Status Reason field.

Giving Pages

Payment Form builder speed improvement

Issue: If orgs have many fields on objects, such as Contact and Account, that are used in the Payment Form settings, opening the Payment Form in the Page Builder can be very slow. In some cases, the builder may freeze.

Solution: The issue was caused by how the object data is pushed to the Page Builder when loading the Payment Form component. We’ve now changed the method for collecting and pushing this data to speed up loading times in orgs that use many fields on key objects.

MOTO (PILOT)

Installment status not updated because it cannot be found

Issue: FinDock creates inbound reports for PSP notifications that are matched to installments using the PaymentIntent Id. With the introduction of MOTO payments where FinDock executes payments directly with the PSP, it became possible for payment success notifications to arrive before the original PaymentIntent confirmation is received and stored as an inbound report. This would result in the installment not being updated as paid because no PaymentIntent Id is stored on the installment yet.

Solution: With standard API payment flows where the payer is first redirected to the PSP’s hosted payments page to complete the payment, PSP notifications arrive in a predictable order, and FinDock updates installments accordingly. With the new MOTO flow, however, this order may not always hold. To resolve this, we have added a new checking mechanism in inbound report handling that will pause the success message handling in certain situations. This ensures that the notification from the PSP indicating the payment has succeeded cannot be processed before the initial PaymentIntent inbound report is created.

Card CVC number validation correction

Issue: If a CVC value starts with one or two zeros, FinDock incorrectly stripped the leading 0 or 00 before sending the value to Stripe. As a result, the CVC would be rejected by Stripe.

Solution: We updated the CVC handling on FinDock’s side to keep the leading zero(s) in place so the full 3-digit value is sent to Stripe as expected.

ProcessingHub

Data handling improvement

Issue : ProcessingHub runs multiple tasks to prepare data. In certain scenarios, tasks running in parallel could end at the exact same moment. This could result in errors on ProcessingHub that would prevent data handling from completing.

Solution : We updated the task management component of ProcessingHub to correctly handle the data workflow even when tasks end at the same time.

Auto retry for invalid generated file

Issue: Though not a blocking error, ProcessingHub may report in ProcessingHub Manager a Generated file is invalid error, with instructions to contact FinDock Support. This error only appears on occasion with SEPA Credit Transfer file processing. The same error may also be seen as an auto-generated comment in the file exchange Chatter Group.

Solution: The error was caused by a miscalculation of an amount value that was used to validate the file. We’ve now introduced additional checks to ensure the final calculation stays in line with the actual amount from the generated records.

Enhanced error handling for missing Chatter Group

Issue: If ProcessingHub does not have an assigned active Chatter Group for file exchanges, file processing will fail. This tends to happen with groups that are automatically archived. However, errors also arise when, for example, file processing is attempted before a group is assigned in the ProcessingHub configuration, or when the originally assigned group is deleted.

Solution: We have built a new Chatter Group check mechanism and created special error messages for Last Status Reason when ProcessingHub runs into a missing or archived group.

New MT 940 support for Volksbank and GLS Bank

We’ve added specific support to our MT 940 file parsing for Volksbank Raiffeisenbank Dachau eG (GENODEF1DCA) and GLS Bank (GENODEM1GLS).

MT 940 parsing update for Triodos

Issue: MT 940 files from Triodos Bank can include 2-letter values for the Identification Code subfield which FinDock did not parse correctly.

Solution: We have updated the parsing rules for MT 940 files from Triodos Bank to support both 2- and 3-letter codes in the 61: Statement Line field for Identification Code.

Pain.008 parsing update for Ireland

We have added new rules to our pain.008 parsing to support specific content used by Irish banks. These new rules enable FinDock to support pain.008 files from any Irish BIC.

Enhanced handling of deleted data

Issue: Deleting a contact by merging with another contact can result in stuck processes on ProcessingHub. This occurs when the merge is done while bank statement file processing or payment schedule runs are ongoing. Once this happened, manual intervention from FinDock was required to restart processing on ProcessingHub.

Solution: If contacts are merged during bank statement file processing and payment schedule runs, ProcessingHub will automatically re-query the contact and account fields on installments to re-sync data with Salesforce and then retry affected process.

Payment schedule fails with incomplete SEPA target

Issue: If a SEPA target does not have all the required information for a given payment schedule, the payment schedule run would get stuck on ProcessingHub and require manual intervention.

Solution: Now if a SEPA target is missing required information, ProcessingHub will set the payment schedule to Failed. An error messing in Last Status Reason indicates the SEPA target details are incomplete. These are details that can be confirmed by running FinDock Data Quality validation.

Camt.053 parsing update

Issue: A camt.053 file can have an <Ntry> element with multiple <TxDtls> elements, but with <Amt> only set on the <Ntry> level. This indicates the file entry is a single transaction, but FinDock created a record for each <TxDtls> element, leading to duplicate transactions.

Solution: We’ve updated our parsing rules to ensure this sort of file structure results in a single transaction record for the a <Amt> set on the <Ntry> level as expected.

Update to file total calculations for SEPA Credit Transfer

Issue : With SEPA Credit Transfer files, the total amount and the sum of all individual transaction amounts in a generated SEPA Credit Transfer file could differ due to rounding in ProcessingHub. This would lead to the file being rejected by the bank.

Solution: We changed how ProcessingHub handles rounding to ensure the calculated total and the sum total are equal in generated SEPA Credit Transfer files.

Updated encryption procedures

To further enhance the security of all ProcessingHub instances, we have added additional encryption measures to our existing practices and the standard security framework that is part of Heroku Private Spaces. We do not expect the new encryption measures to impact ProcessingHub performance.

WebHub

Improved peak performance

We have increased the number of concurrent requests support by our Heroku dynos used for WebHub operations including Giving Pages, PayLinks, and PSP notification handling. The additional performance will help particularly during peak months, such as end-of-the year holiday season. However, the changes are permanent, so the performance gains will persist for all scenarios.

Adyen

Failed installment due to second failed payment

Issue: When two payments for an existing installment are started through the FinDock Payment API and the first is paid, the installment is set to Collected when the first payment is successful. However, if the second payment is not completed (abandoned) while the payer is already on the Hosted Payment Page of Adyen, FinDock would change the installment status to Failed based on the abandonment notification from Adyen for the second payment.

Solution: FinDock now does not change the status of a collected installment if an inbound report for an abandoned payment arrives. The inbound report is matched to the collected installment as expected, but no change is made to the installment status. If changes are refunded or cancelled in other ways FinDock does update the status of the installment as notified by Adyen.

Missed payment data due to second incoming payment

Issue: When two payments for an existing installment are executed in a very short time period through PayLinks or the FinDock Payment API, FinDock may only create one payment record. This is caused by how the payment intent identifier is stored. A payment intent ID is saved on the installment from the first payment action. However, this is overwritten by a new ID with the second incoming payment. Once this happens, the inbound report from the first payment cannot be matched to the installment, resulting in no payment record being created. The payment would, however, still be collected through Adyen.

Solution: We have added additional matching logic for inbound reports. If the installment cannot be found by searching payment intent IDs on installments, FinDock carries out a second search for payment intent IDs on inbound reports to locate the correct installment. This way FinDock can be certain to find any payment intent ID and the related installment because inbound reports are created for every API call, including the initial callout to start the payment process.

Bacs Direct Debit

Duplicate reports with Guided Matching

Issue: When Guided Matching was expanded to process Bacs Direct Debit reports in the January '22 release, duplicate inbound reports were created for Bacs Manual or SmartDebit payments that go through Guided Matching. This would lead to duplicate payments in Salesforce for customers using the new Guided Matching capabilities. Depending on the Bacs report type and Reason code, the logic based on the instruction in the report could be triggered twice leading to double reversals etc.

Solution: The issue was caused by Guiding Matching starting before FinDock completed the standard duplicate check based on incoming report checksum values. We have now added the duplication check to Guided Matching where it is executed in the Handle Bacs inbound report rule. If a duplicate is detected, the rule is skipped and a link to the existing inbound report is provided.

Auto-retry of frozen SmartDebit processes

Issue: When Bacs reports from Smart Debit are picked up by ProcessingHub, the report handling process may freeze for unspecified reasons. When this happens, all further processing is blocked.

Solution: We’ve implemented a monitoring solution that will check for frozen Smart Debit processes on a regular basis and automatically notify FinDock Support so that we can restart the process as quickly as possible.

Payment schedule handling with aggregated installments

Issue: When the FinDock Heartbeat runs, payment schedule for Bacs Manual or SmartDebit in status Generated could be set back to status Aggregating Installments. This would happen when the schedule is in Generated for a extended period (more than 24 hours) and results in blocked payment schedule processing.

Solution: This issue was caused by the installment counter calculation job automatically triggering the installment aggregation job, regardless of whether the aggregation is needed for the given payment schedule. We have now updated the logic that starts the installment aggregation batch to ensure the job is only run if it is needed.

Buckaroo

Select supported card brands

Issue: When using Buckaroo as payment processor, by default you can select three card brands on a FinDock payment form. However, not all brands may actually be available in the merchant contract with Buckaroo.

Solution: We’ve added an option to Buckaroo extension setup to select the card brands you want to use. The FinDock Payment API will only expose the selected card brands in the response to the GET /PaymentMethods endpoint and only those brands are used to build the card picklist values on FinDock Giving Pages payment forms.

Support for lowercase values in payment notifications

Issue: To process iDEAL QR payments, FinDock needed to receive notifications from Buckaroo that use all uppercase. This caused if customers did not modify the 3.0 BPE Return Fields setting in Buckaroo Plaza to use uppercase, leading to unprocessed payments in FinDock.

Solution: Though we still recommend using uppercase for BPE Return Fields, we’ve updated the regular expressions used for handling Buckaroo notifications to allow both lowercase and uppercase letters.

Improved nonce generation for callouts

Issue: When creating the authHeader for callouts to Buckaroo, FinDock includes a nonce (unique string) which needs to be unique for each callout. However, because FinDock based the value on a timestamp in seconds, it was possible for callouts in quick succession to have the same nonce. The second callout with the same nonce would then fail.

Solution: We’ve updated the nonce generation to use milliseconds, and if a a duplicate nonce is detected by FinDock in the same job run, an additional random number is added to the second instance to ensure uniqueness.

Configurable iDEAL QR image size

Issue: The size of the generated iDEAL QR images was hardcoded by FinDock to be 100x100 pixels. This relatively small size does not work well for certain QR use cases.

Solution: We’ve added a new QR image size parameter to the Payment Request Generator run setup. The input parameter defines a pixel value, between 100 and 2000. For example, if you enter 250, the resulting QR images are 250x250 pixels. The parameter is optional. If left empty, FinDock uses 100 pixels as before.

Guided Matching rule order for iDEAL QR payments

Issue: With the November '22 release, the Guided Matching setup for Buckaroo was updated incorrectly. The changes to support iDEAL QR (transaction report subtype C021) were not inserted in the right order, preventing FinDock from processing iDEAL QR payments. The Handle Notification rule was too early in the rule execution plan, when it should have been after all extract rules.

Solution: We’ve updated the order of the rules to put the Handle Notification rule in the correct position. With this update, FinDock overwrites the existing rules for the C021 report subtype with the new order.

New Guided Matching rules for iDEAL QR

To improve the success of matching iDEAL QR payments, we have added two new rules to the out-of-the-box ruleset for Buckaroo payments. The new rules are:

• Search campaign when source is campaign member
• Find Activate Payment Profile query on Contact + IBAN

Gift Aid

Data Quality updates

Issue: A Gift Aid payment schedule run will fail if an installment has a valid Gift Aid Declaration, but the Acquisition Method field is empty.

Solution: The Acquisition Method field could not be empty due to unnecessarily strict rules in ProcessingHub. We’ve now removed this requirement so the field can be empty. While analyzing the issue, we also noticed that the Gift Aid Data Quality rules were missing a validation rule for Due Date on installments. So, we have also updated the Data Quality component to include a rule to check that the due date on installments is later than today.

Stripe

Encoding of non-ASCII characters in SuccessURL

Issue: When using Stripe and the FinDock Payment API, the successURL sent to Stripe would fail if the URL contained non-ASCII characters. This would cause Stripe to throw a non-ASCII characters are not allowed error.

Solution: The issue was caused by FinDock incorrectly encoding non-ASCII characters which has now been fixed.