Release Notes - November '24

We are happy to present the FinDock November '24 Release!

Important Dates:

• Release to sandboxes: October 27, 2024
• Release to production: Cancelled

FinDock Setup updates

You can now install and configure the following payment extensions through the enhanced FinDock Setup:

• Axerve
• Mollie
• Redsys
• Tikkie

We have also made a few minor adjustments in this release, such as fixing the numbered steps on the setup guide, part of the enhanced FinDock Setup, which in some cases did not appear in the expected order.

FinDock e-mandates

Support for customized PDF

With this release, we are introducing support for customized PDFs to the FinDock e-mandates feature. Customers can design their own branded PDF using Visualforce and include data fields provided by FinDock.

As part of this update, we have also modified how Apex class permission are handled. Access to the Apex classes for the eID service are included in the FinDock Sweden Integration permission set.

The Apex class for the PDF generation, because it uses Visualforce, needs to be manually configured. The class can be added to a permission set if the integration user has a standard user profile. If the integration user is API only, the user profile needs to be added to the Enabled Profiles for the MandatePDF Visualforce page.

Please note that FinDock e-mandates is an add-on feature that is not yet generally available.

Core

New report component for payment schedules

The default Payment Schedule page layout shipped with FinDock includes report charts for key stats such as total number of installments. Deleting the reports for these layout elements prevents FinDock from pushing standard updates to those orgs.

To remove this report dependency and provide an improved reporting experience, we are rolling out a new Lighting Web Component (LWC) for payment schedules. The new Payment Schedule Stats component provides the same details as existing reports that leverage the design and interaction features of of LWC.

This update is a breaking change for orgs that use the default page layout for payment schedules. Clones of the default layout and custom layouts are not impacted, and the new component can be easily added to these layouts.

If you want to keep the old layout, simply clone the updated default layout, remove the new component, and add back the report charts as before. You can choose to apply your visibility logic in the layout builder. Those are:

• Installment Count / Status

• Installment Amount / Status

• Installment Last Failure Reason

Guided Matching Forward to Source rule

Issue: With the introduction of tributes support in the Sept. 24 release, we added a field dependency in the Forward to Source rule. In a very limited number of Payment API implementations, this dependency caused Guided Matching to fail on Forward to Source. Payment collection itself is not impacted, but the Forward to Source rule failed instead of being skipped as before.

Solution: We have modified how the field dependency is handled to support all possible Payment API implementations, allowing the Forward to Source rule to be skipped when the dependency is not applicable.

Permission set update

Issue: A permission related to our Sept. '24 Content Security Policy enhancement was missing from the FinDock Core Giving Pages and PayLinks permission set. This meant users who only had that permission set assigned (and did not have a system admin profile) could no longer work with Giving Pages and PayLinks.

Solution: The missing cspTrustedSiteController permission has now been added to the FinDock Core Giving Pages and PayLinks permission set.

Update for bank statement matching

Issue: A change in our Sept. 24 release caused the status of matched Transaction records to be set back to Processing by Guided Matching.

Solution: The underlying logic that caused the status change has been fixed. If a Transaction record is matched on ProcessingHub and further handled by Guided Matching, the status remains Matched.

Enhanced handling of protected target settings

Settings for targets (merchant accounts) created through the enhanced FinDock Setup may include protected settings such as API keys and passwords. This release includes strengthened security measures for handling these protected settings.

API version updates for Winter '25

This release brings FinDock up to date with the latest Salesforce API versions included in Salesforce Winter '25.

Giving Pages / PayLinks null values in message body

Issue: After the September '24 release, the message body from Giving Pages and PayLinks calls to the Payment API changed. Instead of leaving out empty arrays, they were included as null values. For example, a one-time payment message would include "Recurring": null, which could cause issues with parsing or other processes.

Solution: The new JSON format change resulted from lifecycle-related software updates for WebHub. We’ve now made adjustments to WebHub so empty arrays are not included as before.

Notification Gateway

Update for Winter '25

Issue: With the Salesforce Winter '25 release, Salesforce redirects to legacy URLs are removed.

Solution: We have enhanced Notification Gateway to ensure org URLs are refreshed when the given sandbox or production instance moves to Winter '25, eliminating the need for redirects.

ProcessingHub

Errors in Bulk Data Load logs

Issue: In our Sept. 24 release update for the Payment Request Generator, we introduced changes to our statistics monitoring to reflect the generator update. Obsolete fields were removed from permissions that resulted in errors seen in the Bulk Data Load job logs.

Solution: Thee errors caused by the permission changes do not impact FinDock features and operations. However, we’ve removed the obsolete fields from our statistics queries that were causing the errors.

General performance enhancements

ProcessingHub uses auto-scaling and other techniques to handle workloads and the timing of processes on Heroku. In this release, we have refactored several aspects of ProcessingHub to further boost overall performance and improve how processes are triggered. These changes help improve stability by reducing the chances of processes getting stuck. In addition, based on internal testing results, we expect customers to see significantly faster processing after these updates.

Support for non-Euro accounts for SEPA

We have added support for non-Euro bank accounts that are used for SEPA Direct Debit collection or SEPA Credit Transfer disbursement. You can enable support on a SEPA target by toggling on the new Multi-currency account option on the target settings. When enabled, FinDock adds the CCY entry to pain.001 and pain.008 XML files to set the payment instruction currency to Euro.

MT940 support for Commerzbank

With this release, we have added support for an additional Commerzbank BIC (COBADEFFXXX) to MT940 processing.

Heroku apps maintenance

As part of ongoing software lifecycle management, we have upgraded software components for ProcessingHub. These upgrades do not require any action from customers.

AvtaleGiro

Locked rows in Guided Matching

Issue: If Guided Matching is used to create a new contact, Salesforce can sometimes throw a locked row error, blocking further processing by Guided Matching.

Solution: We identified and removed a potential cause of locked rows in the AvtaleGiro context. The Customer Id (KID) generation triggers could result in a row remaining locked longer than necessary. We’ve optimized those triggers to reduce the need for row locking during record creation and update processes.

Bacs Manual

Change in handling of installments pending recollection

Issue: Installments with status Pending recollection that share the same mandate Id could not be reconciled correctly when ARUDD reports arrive for those installments. Instead of marking them all Reversed, only the first matched installment was marked Reversed. The others were flagged as duplicates.

Solution: To correctly handle reversing installments that have the same mandate Id and are pending recollection, we have implemented the installment aggregation logic used for normal Pending installments (Bacs transaction code 17). If a payment schedule includes more than one installment with status Pending recollection (transaction code 18) that share the same mandate Id, these are aggregated into one installment in the payment instruction file. The Bacs report matching logic is applied to aggregated transaction code 18 installments in the same was as currently with transaction code 17. To enable the aggregation and matching logic based on transaction code, we have introduced a new field on Installment called Bacs Transaction Code.

File names of generated payment instructions

Issue: Refactoring related to the file splitting support introduced in the Sept. 24 release caused an unintended change to how generated files are named. The Standard 18 payment instruction file names started with 0- after the change instead of 1-, which impacted custom file handling solutions built on top of Bacs Manual.

Solution: We have reimplemented the previous numbering logic so that generated single Standard 18 files begin with 1- and multiple generated files form a single schedule are numbered sequentially 1-, 2-, etc.

Buckaroo

iDEAL QRs through Payment Request Generator

Issue: Our internal testing revealed an Apex exception error when using the Payment Request Generator to create Buckaroo iDEAL QRs. The exception prevented the generator run from completing.

Solution: We identified and fixed the cause of the error so that Buckaroo iDEAL QRs can be generated in bulk as expected.

Recurring card payments and transaction codes

Issue: New recurring card payments with certain transaction codes did not create the Payment Profile and Mandate records required to collect the recurring installments.

Solution: A small set of credit card transaction codes were not correctly implemented. This is now resolved so that our full set of supported collection codes functions as expected.

Fundraising

Initial payment for recurring payment

Issue: New recurring payments set up through the Payment API (including Giving Pages and PayLinks) that include an initial payment were not handled correctly. The Gift Transaction record representing the initial payment was not related to the Gift Commitment and Gift Commitment Schedule records that define the recurring payment.

Solution: Handling of initial payments for new recurring payments has now been properly implemented for FinDock for Fundraising. The gift transaction for the initial payment is related to the recurring payment records in Fundraising as expected.

Flows update for FinDock Labs

We’ve updated the FinDock for Fundraising flows to make them compatible with the Salesforce Winter ‘25 release.

Mollie

New integration with Mollie API v2

With this release, the Mollie payment extension is fully compatible with Mollie API v2. Until now, the FinDock integration with Mollie has used version 1 of the Mollie API which is being shut down at the end of 2024. No actions are required from customers, though we recommend a full regression run.

Multi-merchant and multi-currency support

We are happy to announce that the Mollie for FinDock now supports multiple merchant accounts. Multi-merchant support is enabled by default for new installations. Customers with existing installations can enable the multi-merchant feature from the new Multi-Merchant subtab in the Mollie payment extension settings.

In addition, with the new Mollie API v2 integration, Mollie for FinDock payment extension also supports multi-currency payments.

Saferpay

Callout enhancement to prevent timeouts

Issue: Responses to callout from FinDock to Saferpay may in some cases be delayed beyond the default 10-second response window. When this occurs, the payment capture cannot be completed and results in errors with inbound report processing.

Solution: We implemented a much longer response window that should eliminate timeout errors under normal conditions.

Stripe

Delayed processing of inbound reports

Issue: In certain cases, some inbound reports for notifications from Stripe may get stuck in Pending state rather than being processed by Guided Matching as expected. This does not block collection, but delays updates to Salesforce data.

Solution: While retrying Guided Matching on the inbound reports results in successful processing, we have made several adjustments to notification handling and Guided Matching to help mitigate the chances of an inbound report remaining in Pending status. Based on internal testing and testing with customers who have experienced this issue, we believe these changes will prevent most if not all processing delays.

Caching in Notification Gateway

Issues: In some cases, Stripe messages would still come through Notification Gateway after disconnecting Stripe from the org. In other cases, disconnecting and then reconnecting the org to a different Stripe account resulted in no messages coming through Notification Gateway.

Solution: The issues were caused by incomplete clearing of the Notification Gateway cache when a Stripe account is disconnected from FinDock. This has now been resolved, and caching is fully cleared upon disconnect as expected.

Swish

Successful payment redirect

Issue: When a Swish payment is completed in a production org using Giving Pages, the payment is collected, but the payer is not redirected to the success page as expected.

Solution: The issue was caused by how FinDock determined test mode and the corresponding org endpoint. This has now been resolved so redirects are handled correctly between test and production setups.