Our release communication aims to inform you early of upcoming releases. The scope of a release is subject to change prior to the release date. Release notes are updated accordingly until the release date.
Important Dates:
- Release to Sandboxes: February 22, 2026
- Release webinar: February 27, 2026
- Release to Production: March 2, 2026
In addition to making payments through the FinDock virtual terminal (MOTO) component, the Paya for FinDock payment extension now supports one-time and recurring credit card and ACH direct debit payments through online channels, including Giving Pages, PayLinks, custom Payment API integrations.
ACTION NEEDED: For pilot customers who have already installed Paya for FinDock, please assign the new FinDock Paya Base permission set to Paya users by adding the permission set to all FinDock permission set groups. This new permission set is required for online payments. For new installs, this permission set is automatically added to FinDock permission set groups.
We’ve expanded FinDock Data Quality rules to cover the billing information requirements for Address Verification Services (AVS). The validation rules are used in-line (e.g. with payment schedules) and can be triggered through the Data Quality component.
For the beta release of Paya, we have also changed how AVS is configured. We added a new merchant account (Target) setting to enable you to set the AVS requirement for that account across all payment acceptance channels. The existing setting on the FinDock Payment component continues to define the AVS requirement specifically for MOTO payments. However, it now functions as an override of the account-level setting. If a conflicting configuration is selected, the component shows an error.
We improved and thoroughly tested LDV performance with Paya, making large payment schedule runs significantly faster. Based on our testing, we expect payment schedules with 150,000 records, for example, to be completed over a single night.
During our development of the Paya integration, the Token field (cpm_Token__c) on Payment Profile was planned for storing a profileID from Paya. However, the implemented integration does not need or use this field, so we have removed Token in this release.
We have added idempotency to the Refunds feature to help protect against duplicate refund requests. The new Idempotency Key parameter is available through the invocable action FinDock Initiate Refund.
The Refunds from Salesforce feature now supports Fundraising (NPC, EDU) as a source alongside FinDock Standalone.
When Fundraising is the source, the FinDock Refund record, through Inbound Report record processing, creates and updates a corresponding Gift Refund record. Please note that creating a Gift Refund record does not result in a corresponding Refund record.
Refunds triggered using the invocable action FinDock Initiate Refund automatically create a corresponding Gift Refund record with the following mapping.
| Gift Refund | FinDock Refund | Sync | Comment |
|---|---|---|---|
| Amount | Amount | One way | Can only be changed from the Refund record |
| Date | Created Date / Refund Date | One way | Create Date is used when the refund is initiated, and then this is updated to Refund Date when the refund is completed |
| Reason | Refund Reason | Two way | Only synced if values are identical between Refund and Gift Refund |
| Status | Status | One way | Can only be changed from the Refund record. Status mapping is fixed: Pending Processing => Initiated, Failed => Failed, Completed => Completed |
Issue: Query jobs efficiency can be much lower than expected. In addition, Data Load counters for processed and total records also may not display correct values.
Solution: There was an issue with how batch sizes are handled in parallel processing that led to unexpected performance loss. After further testing and refining the ProcessingHub integration, the queries are now running as fast as expected with accurate counters.
The European Payments Initiative (EPI) is launching a type payment method called Wero. The plan is to gradually replace several local payment methods: iDEAL in the Netherlands, Payconic in Belgium and Luxembourg, Giropay in Germany, and Paylib in France.
Backend changes at banks for iDEAL in the Netherlands are now in progress. No technical changes are required yet for FinDock, but we are updating labels and icons to reflect to the co-branding, iDeal | Wero. The API name and Salesforce picklist value Ideal remains as is for now to maintain data consistency.
Required actions If you have a custom integration to the Payment API that offers iDEAL as a payment method, check whether your integration hardcodes the method icon and label or takes them dynamically from the GET /PaymentMethod response.
If dynamic:
- You do not need to update the icon.
- You do need to update the payment method label to iDEAL | Wero.
If hardcoded:
- You do need to update the icon.
- You do need to update the payment method label to iDEAL | Wero.
Issue: In certain cases, FinDock did not automatically insert the default Guided Matching Setup record for new Bank Feed accounts when the accounts are authorized. This makes migrating existing Guided Matching rules for the target (account) difficult and slows down reconciliation for the newly added account.
Solution: The issue was caused by how FinDock assesses whether the IBAN connection being set up is a new Bank Feed account. The Guided Matching Setup record insertion for new Bank Feed accounts was not triggered when the IBAN is already defined as a target (merchant account) for payment processing. This has now been resolved so all new authorizations get a default Guided Matching Setup record as expected.
Issue: When you add the FinDock Payment component to a layout and select a PSP other than Paya, the component shows an irrelevant error about the PSP not supporting Address Verification Services (AVS).
Solution: The issue was caused by how the component validates AVS-related settings which include defaults that are applicable to all PSPs. We’ve modified the default handling to ensure non-AVS enabled PSPs can be configured and used in the Payment component as expected.
Issue: Updates to the FinDock Data Quality framework and logging have resulted in log records that are difficult to read and parse.
Solution: The issue was caused by some log information getting stored as plain strings. With this release, all logging has been updated to properly store JSON-formatted data again.
Issue: When working with multiple installments in the Process Installment component, deleting just one installment from the list of matched installments removed all installments from the list.
Solution: This issue was caused by a minor bug in the component which cleared the entire list rather than just removing the selected installment. This has now been fixed so the delete action works as expected and just removes the selected installment.
Issue: The Sort Code (cpm__Sort_Code__c) and Bank Code (cpm__Bank_Code__c) fields on Payment Profile were not included in any FinDock permission sets, so they could not be used out-of-the-box without customizing permissions.
Solution: Field level access for Sort Code and Bank Code is now part of the FinDock Core Base permission set. This permission set is part of all FinDock permission set groups.
Issue: The dropdown picklist for State does not render on Giving Pages and PayLinks when it is used as an address field (marked visible) in the payment form configuration.
Solution: The State field picklist, which is dependent on the Country field picklist, was not included in previous accessibility-related refactoring, leading to the rendering issue. This has now been corrected so that the dependent State field renders as expected when it is used as an address field.
Issue: If there are multiple sets of information records (lines 31 thru 33) for a given transaction, FinDock only extracts the last set. This results in potentially valuable information not being available for matching and reconciliation.
Solution: We have enhanced the CODA parsing logic to extract all sets of information records so that all the data is available for matching and reconciliation.
Issue: The special character support introduced in the Jan. 26 release did not cover movement records, causing CODA file extraction to fail if movement records include special characters.
Solution: We have expanded special character handling through UTF-8 encoding conversion in the extraction process of all supported record types within a CODA file.
Issue: When Heroku conducts scheduled maintenance work, active processes on ProcessingHub can freeze or fail. Recovery requires intervention from FinDock after the maintenance break.
Solution: We have introduced several new measures to help identify abd catch processes that are impacted by temporary maintenance breaks.
Issue: When a payment comes back with the status Rejected, a status used by, for example, AvtaleGiro and Swish, FinDock created a negative Opportunity Payment record, although there was no positive payment in the first place (no money changed hands). This created an unclear picture of NPSP opportunities and their actual collected amounts due to the extra, negative payment records.
Solution: The Rejected status was incorrectly handled the same as Reversed with NPSP. This has now been fixed so that Rejected is handled the same way as Failed. No Opportunity Payments are created, leaving the amount unchanged and Paid unchecked (false), as expected
We have added support Address Verification Services (AVS), which can be used to help with fraud detection, to the FinDock integration with Authorize.net. AVS needs to be enabled for your account at Authorize.net before you can use it with FinDock.
In FinDock, you control AVS through the merchant account (target) setup for online payments (Giving Pages, PayLinks, Payment API). For virtual terminal (MOTO) payments, you can override target-level the target-level setup with the FinDock Payment component settings.
With this release we have changed the pay-action button text on the hosted payment page (HPP) from Authorize.net from “Donate” to “Pay” to make the pay context more general. This change does not require any action and is automatically applied to all installations.
With this release, you can now accept SEPA Direct Debit payments from non-EEA counties. The SEPA Direct Debit specification extends the scheme to allow payments outside the European Economic Area (EEA) to include over 40 countries and territories.
After this release, mandates for Buckaroo are linked to payment profiles with additional required fields that are required if the payer’s account is in a non-EEA country. The additional fields are:
- Street
- Housename Or Number
- Zipcode
- City
- Country
Issue: Buckaroo Transaction Codes C801 and C806 are credit card transactions that FinDock did not correctly categorize as card payments. This resulted in no payment profile being created for new payments with code C801 or C806.
Solution: We fixed the underlying issue causing the mis-categorization of C801 and C806 are now correctly handled as card transactions.
With this release, we have added support for Giro (KID) payments through online changes (Giving Pages, PayLinks and Payment API). You can accept both one-time and recurring payments for new or existing payers. For new payers, FinDock automatically generates the KID value, used as the Customer Id and included the Final Payment Reference on installments for reconciliation.
Issue: When validating data quality for Norway (AvtaleGiro), irrelevant Sweden-specific rules were included, creating confusing validation results.
Solution: We have resolved the issue so that the Data Quality rules are correctly filtered and validation checks for Norway only include the relevant rules.
Issue: When using the Payment Request Generator to create KID references for campaign members, if more than 150 members don’t already have a KID, the bulk generation run fails.
Solution: There was a bug in the KID bulk generation flow causing it to attempt to generate KID values for campaign members one by one rather than in bulk. This has now been resolved so bulk generation runs as expected.
Issue: FinDock’s native SEPA Direct Debit processing supports payments from non-EEA countries. However, the list of countries in the validation rules for SEPA (Data Quality component and payment intents via API) did not cover all possible entities, which could potentially lead to failed payments.
Solution: The Country field validation for Payment Profile now covers all countries and territories according to the SEPA Direct Debit specification.
The FinDock integration with Stripe now supports one-time payments with Satispay, an online payment method popular in Italy.
This release includes version upgrades for software components used in FinDock apps on Heroku. These updates apply to FinDock Installer, FinDock MIDAS, Notification Gateway, Processing hub, WebHub and FinDock access management frameworks.
With this release, we have updated software components used for our internal ProcessingHub tool interfaces. These updates do not impact customer-facing user interfaces.