# Release Notes - March '26

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


# March ‘26 Release Notes

## Paya pilot updates

### Online payments

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.

### New validation and enhancements for AVS

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.

### LDV performance

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.

### Token field removed

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.

## Refunds from Salesforce pilot updates

### Support for idempotency keys

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.

### Support for Fundraising (NPC, EDU)

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 |


## Bulk APIv2 pilot update

### Batch size refinement

**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.

## Core

### iDEAL to Wero first steps

The European Payments Initiative (EPI) is launching a type payment method called [Wero](https://wero-wallet.eu/nl). 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.


### Bank Feed Guiding Matching setup for new accounts

**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.

### Payment component update for AVS

**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.

### Log output formatting update

**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.

### Guided Matching Process Installment component update

**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.

### FinDock Core Base permission set update

**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.

### State picklist on Giving Pages and PayLinks

**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.

## ProcessingHub

### CODA parsing enhancement for information records

**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.

### CODA movement records with special characters

**Issue:** The special character support introduced in the [Jan. 26 release](/release-notes/release-notes-january-26#coda-files-with-special-characters) 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.

### Enhanced resilience to maintenance breaks

**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.

## NPSP

### Rejected payment handling update

**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

## Authorize.net

### Address Verification Services (AVS)

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.

### Hosted payment page pay button

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.

## Buckaroo

### Support for non-EEA SEPA Direct Debit payments

With this release, you can now accept SEPA Direct Debit payments from non-EEA counties. The [SEPA Direct Debit specification](https://www.europeanpaymentscouncil.eu/document-library/other/epc-list-sepa-scheme-countries) extends the scheme to allow payments outside the European Economic Area (EEA) to include [over 40 countries and territories](https://www.europeanpaymentscouncil.eu/document-library/other/map-sepa-scheme-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


### Transaction code C801 and C806 incorrectly handled

**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.

## Norway

### Online Giro payments

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.

### Data quality rule filtering

**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.

### Bulk KID generation

**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.

## SEPA

### Validation for non-EEA countries

**Issue:** FinDock’s native SEPA Direct Debit processing supports [payments from non-EEA countries](/docs/payment-processors/configuring-sepa-dd#sepa-and-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](https://www.europeanpaymentscouncil.eu/document-library/other/epc-list-sepa-scheme-countries).

## Stripe

### Support for Satispay

The FinDock integration with Stripe now supports one-time payments with [Satispay](https://stripe.com/en-fi/payment-method/satispay), an online payment method popular in Italy.

## General maintenance

### Heroku app maintenance

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.

### ProcessingHub internal tools

With this release, we have updated software components used for our internal ProcessingHub tool interfaces. These updates do not impact customer-facing user interfaces.