Release Notes - January '26

Important Dates:

• Release to Sandboxes: December 28, 2025
• Release webinar: January 2, 2026
• Release to Production: January 25, 2026

NEW PILOTS

Paya for FinDock

We are happy to announce integration with Paya, a US-based PSP that is now part of Nuvei. The new Paya for FinDock payment extension supports one-time and recurring credit card and ACH direct debit payments through the FinDock virtual terminal (MOTO) component. The payment extension supports payment reconciliation through automatic, customizable matching of CSV files from Paya with Salesforce data.

Paya for FinDock also includes our first steps towards enabling Salesforce users to refund payments directly from Salesforce.

Refunds from Salesforce

We are happy to announce that launching refunds initiated from Salesforce, both full and partial. The new refunds framework starts with the building blocks - These include a new Refund object and related Payment and Inbound Report logic, invocable Apex class, and related permissions.

The building blocks are part of the Core package and will be rolled out to all orgs. However, with this release their use is limited to the new pilot Paya for FinDock payment extension. We expect to add support for other PSPs in the coming releases.

If you would like to be part of the Refunds from Salesforce pilot, please contact FinDock Support.

Salesforce Bulk API 2.0

We are happy to announce that FinDock is fully integrated with Salesforce Bulk API 2.0. Our aim is for all new installations to use the new and improved Bulk API.

With the new API, FinDock also simplifies ProcessingHub configuration by eliminating the need to optimize performance through batch sizes and concurrency modes. Salesforce automatically optimizes API 2.0 usage. We expect customers to see improved performance improvements in most cases. Managing processes through ProcessingHub Manager remains the same.

Existing FinDock installations are not changed with this release. You can continue to use Bulk API. However, we implemented a migration path to Bulk API 2.0 for existing customers. If you would like to be part of the Bulk API 2.0 pilot, please contact FinDock Support.

NEW FEATURES

MobilePay

We are happy to announce support for one-time and recurring MobilePay payments, a new payment method for our Vipps for FinDock payment extension. MobilePay is a popular mobile wallet application used in Denmark and Finland. MobilePay, along with Vipps, were originally separate, but now are combined under the Vipps MobilePay payment service provider.

Moving forward, we use “Vipps” and “MobilePay” as payment method names, while “Vipps MobilePay” is the name of the payment processor. Prior to this release, “Vipps” was also a payment processor name. However, Vipps-for-FinDock remains the value for Payment Processor control picklists.

SEPA Bank Transfer and RF Creditor Reference

We have added support for a new payment method in the SEPA for FinDock package - Bank Transfer. This new payment method is a payment request type that uses RF Creditor Reference as the payment reference format. In addition, FinDock supports the International Finnish Reference, a Finland-specific RF Creditor Reference variant. RF Creditor Reference values can be generated on individual records, as well as in bulk using the Payment Request Generator.

Classic Setup end-of-life cleanup

The classic Setup was deprecated when the enhanced FinDock Setup became generally as announced in the July '25 release. Support for the classic Setup stopped with the end-of-life September '25 release. In this release, to keep our codebase clean and free of potential issues that can arise from technical debt, we are removing components related to the classic Setup that are no longer required for any features.

These changes cover a range of items, from removing references to removing Apex classes and UI elements. In most cases, the changes are not noticeable. Older installations relied on classic Setup pages to enable multi-merchant support for some PSPs. These pages are no longer available.

All FinDock packages were impacted except Fundraising, NPSP, Redsys, SEPA and Swiss Payments. If you are using Axerve (non-pushable package), we strongly recommend updating your installation so that you have the latest, clean baseline.

Core

Payment Schedule stats in multi-currency orgs

Issue: When multi-currency is enabled, the counters on the stats component displayed incorrect totals for the payment schedule.

Solution: The stats component now checks the currency of all installments linked to the given payment schedule. If multiple currencies are detected, the most common currency among the installments is used to calculate the stats. Values in other currencies are converted to that most common currency as part of the calculations.

Schedule validation in LDVs

Issue: Some schedule runs in LDV orgs can get stuck in the Validating phase. If a schedule run for a payment processor-method combination that uses in-line validation included over 75k records, new logging introduced with the Nov. '25 release could result in too many platform events, causing the in-line validation to stall.

Solution: We have modified the logging to handle LDV orgs that run very large schedules with in-line validation. The correction was rolled out to Nov. 25 production orgs as a hotfix, so no further action is required for the Jan. '26 release.

Schedule exception handling fix

Issue: The enhanced logging for our queueable framework in our Nov. 25 release led to unexpected changes in how certain schedule run exceptions are handled. This resulted in some installments potentially being left out of the schedule scope. The schedule would complete successfully with no indication some installments had failed or otherwise were not processed.

Solution: The changes in this release were rolled out as a hotfix to the Nov. '25 production. The corrections for the issues cover the following packages: Gift Aid, Fundraising, NPSP and GoCardless. Impacted customers were contacted to provide instructions on how to recover uncollected installments. If you were impacted and not yet in touch with us, please contact FinDock Support.

Giving Pages and PayLinks accessibility enhancements

This release includes a further round of adjustments to Giving Pages and PayLinks to meet the Web Content Accessibility Guidelines (WCAG) 2.1. These changes include, for example, improved accessibility tooling support and color contrasts.

Further security enhancements

As a continuation of the security enhancements we have implemented in past few releases, we are introducing further security measures in this release related to protected custom settings. The changes include deprecating the public EnforceUserMode custom setting and replacing it with a protected setting. The deprecated setting is not removed, so this is a non-breaking change.

Notification Gateway

Enhanced connection handling

With this release, we have made Notification Gateway more resilient to errors that may occur in the connection handling with PSPs. This includes issues like idle connections being dropped, network errors that prevent initial encryption handshakes from completing, etc. These types of technical issues can cause internal 500 server errors or result in failed webhook notifications in certain rare cases when the PSP does not automatically retry notifications.

ProcessingHub

CODA files with special characters

Issue: File processing fails on extraction due to special characters in the file.

Solution: We have enhanced CODA extraction to handle special characters by implementing UTF-8 encoding conversion in the extraction process.

ProcessingHub Manager logging cleanup

Issue: ProcessingHub Manager may display logs for a given process that are not actually related to that process. The irrelevant logs can cause confusion and make it appear that the process has an error when there in fact is none.

Solution: The issue was caused by an overly broad log writing method. We have updated the logging framework to use a more refined method so that ProcessingHub Manager only displays logs directly related to the process you are currently viewing.

WebHub

Notification handling after reconnecting

Issue: With GoCardless and Stripe, disconnecting and reconnecting WebHub could result in undelivered notifications from the PSP to your org. To get notifications again, you needed to reconnect your merchant account(s).

Solution: We have implemented additional logic to restore delivery of notifications from GoCardless and Stripe after reconnecting WebHub. Now when WebHub is successfully reconnected, notification handling resumes automatically. Please note that notifications sent to FinDock while WebHub was disconnected do not result in Inbound Report records. Some installments may therefore not have the latest information and status from the PSP.

Custom domain handling for WebHub reconnect

Issue: If a custom domain is defined for Giving Pages, the pages are moved back to the default FinDock givingpages.org domain after WebHub is disconnected and then connected again. When the custom domain is not first deleted, reconnecting leads to a restore-in-progress error when opening the Pages builder, and the custom domain cannot be added back.

Solution: We have modified how custom domains are managed on WebHub to automatically restore pages under customs domains when WebHub is disconnected and then reconnected. Custom domains do not need to be deleted unless the domain is going to be changed as part of the disconnect-reconnect action. However, the custom domain does need to be manually re-added and verified after reconnecting WebHub.

Gift Aid

Data validation enhancement

Issue: If HMRC responds to FinDock with certain, undocumented validation rule errors, the Gift Aid payment schedule run could freeze, requiring FinDock Support to manually unblock the processes.

Solution: As part of this release, we improved our HMRC file validation before claim submission to cover the specific rules that have been identified. In addition, we modified logging to improve error traceability.

GoCardless

Installment update handling

Issue: In some scenarios, FinDock could not update the installment to the right status, due to logic outside of the GoCardless package and FinDock, keeping the installment in the old status. This could lead to one failed installment in a 50 installment batch causing the entire batch to fail.

Solution: We’ve expanded our logic to try to update installments to the right status. We also improved logging so customers can identify if this happens and resolve the logic that triggered this behavior.

NPSP

Deployment in orgs with managed Business Process records

Issue: When configuring FinDock for NPSP, a metadata deployment is automatically triggered to finalize the source connector setup. In orgs that have Opportunity record types associated with a managed Sales Process, this deployment fails, preventing you from saving NPSP source connector configuration changes.

Solution: The issue was caused by how MIDAS handled namespaces for Salesforce Business Process records. This has now been corrected so NPSP source connector deployments complete as expected.

Stripe

Mandate custom reference handling update

Issue: With the introduction of Pre-Authorized Debit (PAD) support in the Nov. 25 release, the Custom Reference (cpm__Custom_Reference__c) field from Mandate was added to all callouts to Stripe. This caused recurring payment collections to fail if Custom Reference was already in use for other purposes and payment methods.

Solution: We have adjusted the callout message to only include Mandate Custom Reference if the payment method is Pre-Authorized Debit.

General Maintenance

Heroku app maintenance

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

Unified token handling

With this release, we have updated ProcessingHub to handle the OAuth tokens used for the ProcessingHub-Salesforce connection with the same approach across the entire codebase. This change eliminates older logic that sorted tokens differently for some old ProcessingHub accounts and was still present in parts of the codebase. Customer ProcessingHub accounts are not impacted by this backend maintenance work.