Release Notes - March '25

Important Dates:

• Release to sandboxes: February 23, 2025

• Release webinar: February 28, 2025

• Release to production: March 23, 2025

NEW PILOT: Authorize.net

We are happy to announce support for Authorize.net, a well-known Payment Service Provider (PSP) used widely in the US. The integration with Authorize.net currently supports one-time and recurring card payments.

If you would like to participate in piloting the new payment extension, please contact FinDock Support.

Recurring PayLinks and recurring Payment API to GA

The enhancements to PayLinks and the Payment API for updating recurring payments introduced in the January '25 release are now generally available to all customers.

Sweden to GA

We’d like to thank our Swedish customers for all the testing and feedback of our Sweden-related features and integrations. These are now Generally Available:

• Autogiro native processing with direct integration to Bankgirot
• Bankgirot integration for BGMax file import and reconciliation
• FinDock e-mandates for digitally signed Autogiro mandates
• Giro (OCR) payment reference generation for payment quests
• Swish mobile payments integration
• Total IN file import and reconciliation

Bank Feed to beta

We are happy to announce that FinDock Bank feed is moving out of pilot into beta testing with this release. Along with small adjustments, we have made a few fixes and improvements worth noting as outlined in the sections below.

Batch transaction matching

In addition to single (one transaction to one installment) and multiple (one transaction to many installments) matching, FinDock can now also perform batch matching through Guided Matching.

Batch matching matches payments from multiple payers reported in a single transaction to multiple installments. For file-based reconciliation, batch matching is handled by ProcessingHub. However, Bank Feed transactions do not use ProcessingHub, so we have implemented similar logic in Guided Matching.

If an incoming transaction is identified as a batch transaction, Guided Matching automatically shows the batch-level matching progress. Please refer to the March '25 version of the Bank Feed article for further details.

Guided Matching managed rules update

For the pilot release, some managed rules for Bank Feed used the out-of-the-box “custom” fields on Transaction like Custom 1 (cpm__custom_1__c) to store queried data. However, many customers already use these fields for their own Guided Matching rules. With the beta release of Bank Feed, our managed rules no longer need to use these ready-made fields.

Currency handling update

During pilot testing, the org default currency was used for incoming transactions that did not include an explicit currency code. However, since the org default currency may not be correct for the given transaction, we updated the currency handling to instead fall back to the default currency of the payer’s bank account.

Giving Pages

Updated Content Security Policy blocks content

Issue: The January '25 release included an update to the Content Security Policy (CSP) FinDock uses on Heroku for Giving Pages content. This update introduced stricter content rules which blocked certain page content from rendering.

Solution: The security update blocked content hosted on the Salesforce *.documentforce.com domain. We’ve now added this domain to the policy whitelist to allow the content on Giving Pages.

Thank You page not rendering correctly

Issue: Changes made to the Thank You page in the Giving Pages builder were not reflected in the published page.

Solution: This issue was caused by an internal bug between the Giving Pages builder and the PayLinks builder, causing the PayLinks builder Thank You configuration to show for Giving Pages. This has now been resolved.

PayLinks

Frequency labels translatable

Labels for frequency options of recurring PayLinks can now be translated. Please note that the PayLink builder shows all frequencies supported by FinDock, however, some options may not work in a given org because they are dependent on a source, like Fundraising (NPC) and NPSP.

Mandatory initial payment for recurring payments

With this release, we have introduced a new setting for Recurring PayLinks to support making initial payments for new recurring payments. This is required by several PSPs as a way to authorize the recurring payment.

The initial payment amount is a new advanced setting in the PayLinks Builder under the Payment Details settings. FinDock provides a default amount of 0.50 that is applied regardless of currency configurations. If you adjust the amount, please check with your PSP to make sure you do not go below the required minimum amount.

The payer will see the amount of the initial payment for a new recurring payment on the hosted payment page of the PSP.

Error handling for recurring PayLink

Issue: If FinDock is unable to retrieve information for a recurring PayLink, there was no error indicating a problem had occurred with the GET /Recurring action.

Solution: If a PayLink cannot retrieve the recurring payment information due, for example, to an incorrect URL or record Id, FinDock will now show the Error page content defined for the given PayLinks page.

Core

Default method for recurring payments

With the addition of support for updating recurring payments via the Payment API and PayLinks in the January '25 release, you could set a default payment processor and method in the PayLinks setup. This default is pre-selected if the existing recurring payment does not yet have a defined processor and method.

In this release, we added the capability to pre-select the default processor and method based on the values already on the recurring payment. This is enabled through the new PaymentMethod and PaymentProcessor values returned in a GET call to the Recurring endpoint of the Payment API.

Guided Matching Query rule enhancement

Prior to this release, the Query rule required you to use the hard-to-use record type Id in the rule setup. Now, instead of needing to provide a record type Id, you can use the (developer) name of the record type name. In addition to being easier to work with, the name enables FinDock to directly query the name rather than having to first query an Id to get the name for further query logic.

Contact settings update

Issue: An email address with more characters than 28 characters could not be saved as a Contact in the enhanced FinDock Setup.

Solution: The issue was caused by how FinDock appends the provided contact details to indicate the intended purpose, e.g. for billing queries. This has now been changed to support longer email addresses.

Payment schedule stats component report filtering

Issue: The default reports used for the stats component showed results for all payment schedules instead of just the current payment schedule.

Solution: We have added a new filter to the three default reports managed by FinDock that first selects results based on the Record Id of the payment schedule to correctly display statistics for a given schedule.

If you have a FinDock installation predating March ‘25, you need to manually add the Record Id filter as the first filter on the default reports. For the two default installment reports, you should end up with a report configuration like this:

For the Last Failure Reason default report, you need to first remove Last Failure Reason filter, add the Payment Schedule Record Id filter, then re-add the Last Failure Reason filter, because you cannot change the order of existing filters.

Please also note that if you are using custom reports on the component, you need to add this filter in your report configuration if you haven’t already.

Permissions update for Payment Schedule report component

Issue: An Apex class permission required for the new report component on Payment Schedule was missing from FinDock’s classic permission sets, resulting in a permission error when opening a Payment Schedule record.

Solution: We have added the missing permissions PaymentScheduleReportController to the PaymentHub Operations and PaymentHub ALL FLS permission sets.

ProcessingHub

Invalid XML error on valid file

Issue: ProcessingHub would throw an error about invalid XML when processing a file that is in fact valid. Retrying the failed process would clear the error.

Solution: This issue was caused by changes to the ProcessingHub backend that are intended for a future release. These changes have now been rolled back, resolving the incorrect XML validation error.

Support for XCG currency

Issue: FinDock did not recognize XCG (Caribbean guilder) as a valid currency when processing incoming bank files such as MT 940 and camt.053.

Solution: We’ve updated all the necessary components to support for XCG. The currency is now correctly handled when processing bank files for reconciliation.

Incorrect encryption status

Issue: Certain performance-related enhancements resulted in FinDock incorrectly identifying the encryption status of certain orgs. This caused an empty encryption key error for these orgs that prevented processes from being run.

Solution: We identified and resolved the issue causing the error. Processes affected by the issue were automatically retried by FinDock.

WebHub

Enhanced restore logic

Issue: When WebHub is disconnected and then reconnected through the new FinDock Setup, in some cases Giving Pages and PayLinks cannot be fully restored, leading to errors when opening the Page Builder. These errors could only be resolved through manual intervention by FinDock Support.

Solution: We have taken a number of actions to make the restore logic more robust. With these enhancements, the need for manual intervention to recover Giving Pages or PayLinks should be significantly reduced.

Content security policy update

Issue: The content security policy FinDock uses for WebHub was overly strict, blocking certain image sources and implementations of Google Tag Manager.

Solution: The policy was updated as part of routine Heroku maintenance in the Nov. '24 release. We have now reevaluated and adjusted the policy settings to allow image and script content for more domains.

AvtaleGiro

MPS integration update

Issue: Under certain rare conditions, the file sending job for the SFTP service integration with MPS could have the wrong parameters, resulting in rejected payment collection files.

Solution: The issue was caused by a bug in ProcessingHub queue handling which could result in a persistent job causing the file sending job for Mastercard Payment Services (MPS) to use invalid configuration parameters. The uploaded files would then be rejected by MPS due to incorrect identification details. The bug has now been fixed so files are uploaded to MPS with the correct parameters.

Bacs Manual and SmartDebit

Batch Bacs report processing

Issue: If a Bacs report batch is uploaded with over 200 entries, only some of the reports are processed while others remain pending. Completing all report processing required manual adjustment of the ProcessingHub Bulk API usage settings.

Solution: This issue was caused by how FinDock was using data handling triggers in the Salesforce Bulk API jobs. We have reworked the batch processing logic to support larger batches of Bacs reports as expected.

Reversal matching

Issue: In certain scenarios involving multiple reversals for a recurring direct debit, FinDock could match the incoming reports (ARUDD or DDICA) to the wrong installments.

Solution: When other data points, like mandate reference and amount, are equal for the installments of a recurring payment, FinDock used the payment schedule date to find the reversed installment. This was a single query, checking for the Bacs Processing Date or Collection Date on the payment schedule, and could lead to incorrect matches if either matched the date in the Bacs report. We have now changed the payment schedule date query so that FinDock first looks for the Bacs Processing Date. If no value is returned, a second query is used to get the fallback Collection Date.

Buckaroo

Default card brands

Issue: When the Buckaroo payment extension is installed, the Amex card brand is selected as an available brand by default, alongside Visa, Mastercard and Maestro. However, the Amex brand is exceptional and typically not part of Buckaroo contracts. Removing the Amex brand from the setup also could not be completed due null reference error.

Solution: We have changed the package installation defaults to include only the most typical brands (Visa, Mastercard and Maestro) and fixed the null reference error bug.

Mandate creation for Recurring Donation

Issue: If a recurring payment (donation) is set up via PayLinks, the mandate creation with Buckaroo would fail.

Solution: We removed a limitation in orgs with NPSP that do not have Enhanced Recurring Donations in use. Orgs using classic Recurring Donations can now use PayLinks to set up recurring payments with Buckaroo as processor.

GoCardless

Enhanced performance for LDVs

We’ve made significant improvement to schedule performance for GoCardless in Large Data Volume orgs (LDVs). Based on internal testing, the new framework enables schedule runs up to 4 times faster than before. No configuration changes are needed to use the enhanced performance.

Charge back notification handling update

Issue: While charge back notification handling was fixed in the Jan. '25 release, if a charge back arrives for a payment collected prior to that release, processing the inbound report for the charge back notification could fail.

Solution: The issue was caused by a missing Payment Intent Id for older payments that the new charge back handling uses. This has been resolved by introducing a fallback data point, the non-indexed Payment Reference field on Inbound Report, for charge back handling when no Payment Intent Id is available.

Mollie

Enhanced payment schedule performance

We have further improved the performance of the FinDock integration with Mollie to support very large payment schedule runs. The enhancements significantly speed up processing and make FinDock more resilient to Mollie API limits, allowing schedule processes to overcome temporary rate limits, for example.

Recurring PayLinks for NPSP recurring donations

We removed a limitation on Recurring PayLinks in orgs with NPSP that do not have Enhanced Recurring Donations in use. Orgs using classic Recurring Donations can now use recurring PayLinks with Mollie as processor.

PayPal

Incorrect target in API callout

Issue: In certain rare multi-merchant scenarios, a PayPal access token can expire while FinDock is processing payments through Guided Matching. When this occurs, FinDock uses the incorrect target in the next callout to PayPal, which causes Guided Matching to fail on subsequent payments.

Solution: We have updated the Guided Matching logic for PayPay to use the target from the payment intent inbound report. Prior to this change, FinDock used the target from the inbound report that triggered the callout to PayPal. This should prevent target mismatches. In the highly unlikely event of a mismatch, FinDock now also throws an error when there is an access token issue to stop further processing.

Remote site setting dependency removed

Issue: With the enhanced FinDock Setup, FinDock changed PSP integrations to use named credentials for the PSP connection instead of remote site settings. However, with PayPal, refund notifications could not be processed without a remote site setting.

Solution: There was a remote site setting dependency in the inbound reports handling for PayPal refund notifications. This has now been replaced with named credentials so that the PayPal extension works as expected without any need for remote site settings.

Saferpay

New error handling

Issue: Inbound report processing would get stuck in Pending if Saferpay returns the error UPDATE_CARD_INFORMATION which FinDock didn’t support, leading to the failure message, “Processing error isn't implemented.“

Solution: This error was introduced in a newer version of the Saferpay API which FinDock wasn’t using yet. We have now updated our integration to the newer version and added handling for the UPDATE_CARD_INFORMATION error. Inbound reports with this error now finish as expected with the related installment set to Failed.

Initial payment collection for recurring payment

Issue: When a new recurring payment with an initial payment requirement is set up for Saferpay, the initial payment is collected, but the related installment in Salesforce is not updated.

Solution: The issue was caused by a problem in the notification handling framework for Saferpay. This has now been corrected so the installment for the initial payment is updated as expected.

Hosted Payment Page for recurring payments

Issue: Refactoring of the Saferpay integration in our Jan. '25 release resulted in an old version of the Saferpay Hosted Payment Page (HPP) being used for recurring payments. While still fully functional, the look and feel of this older version is not ideal.

Solution: We have corrected a bug in the refactoring that caused FinDock to use an outdated Saferpay API which led to the incorrect HPP version. With this change, the latest HPP from Saferpay is used as expected.

SEDA

Payment collection and multi-currency accounts

Issue: The addition of non-Euro account support for SEPA introduced a new multi-currency setting for SEPA targets. However, FinDock checked for this setting on SEDA targets as well, causing payment schedules to fail with the error, “Target config for key MULTI_CURRENCY does not exist.”

Solution: We have narrowed the multi-currency check on SEPA targets to exclude SEDA targets.

SEPA Credit Transfer

Support for version 9 of pain.001

With this release, FinDock supports ISO 20022 2019 version 9 of pain.001 (pain.001.001.09). To use version 9, please enable the Use latest XML version toggle on your SEPA Credit Transfer target(s). When not enabled, FinDock continues to use version 3 (pain.001.001.03). New installs of the SEPA payment extension have the toggle enabled by default.

SEPA Direct Debit

Support for pain.002 version 10

With this release, FinDock supports ISO 20022 2019 version 10 of the pain.002 file standard (pain.002.001.10). No changes are needed in FinDock configurations to start using the new version. Version 3 (pain.002.001.03) continues to be supported as before.

Support for version 8 of pain.008

With this release, FinDock supports ISO 20022 2019 version 8 of pain.008 (pain.008.001.08). This version of the ISO 20022 file format, which introduces some changes to the file content, will be required for many banks by the end of 2025.

To use the pain.008.001.08 version, please enable the Use latest XML version toggle on your SEPA Direct Debit target(s). When not enabled, FinDock continues to use version 2 (pain.008.001.02). New installs of the SEPA payment extension have the toggle enabled by default.

Please note this change only impacts standard SEPA Direct Debit. The pain.008 versions for CBI and Swiss payments (CH-DD, LSV+) remain as is.

Swish

Incorrect redirect URL for production

Issue: The redirect URL FinDock uses for Swish payments was wrong for production environments, causing the payer redirect to fail.

Solution: The issue was caused by how the URL is built for test vs. production environments. This has now been resolved so both scenarios are properly supported.

Vipps

Ledger entries missed for certain dates

Issue: If a year has 53 weeks, FinDock did not fetch Vipps ledgers entries from certain dates because the next pull date was set to next year. This resulted in some installments not getting updated as expected.

Solution: The issue was caused by an incorrect format for ledgerDate. This has now been fixed.

Worldpay

Remote site setting dependency removed

Issue: The Worldpay Corporate Gateway extension still uses a remote site setting for connecting to Worldpay production environments even in new setups where named credentials have replaced remote site settings. The connection uses the production endpoint if it is added to the classic setup for Worldpay.

Solution: We have removed the dependency so that connections configured through the enhanced FinDock Setup only rely on named credentials as expected.

General maintenance

Salesforce API version bumping

Salesforce platform API versions in all FinDock packages for Apex classes and triggers, Visualforce components, Lightning Web Components, etc. have been updated to version 62.0 (Winter '25). This work is part of a new maintenance regime to ensure FinDock supports all Salesforce features with API version dependencies, like ICU locale formats, even if the feature is not directly related to FinDock functionality. As part of the regime, FinDock Core and FinDock for Fundraising packages are always updated to the very latest Salesforce API version, so for our March '25 release they have been updated to version 63.0 (Spring '25).

FinDock for Fundraising flows updated

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

Heroku app maintenance

This release includes version upgrades for software components used in FinDock apps on Heroku. These updates apply to ProcessingHub, WebHub, Notification Gateway, as well asFinDock installation and access management frameworks.