# Release Notes - May '26 Our release communications inform you early of upcoming changes. The scope may change prior to production. We update release notes accordingly during the sandbox period. Important dates * **To sandbox:** April 19, 2026 * **To production:** May 17, 2026 Release Webinar Watch on YouTube. ## Salesforce Bulk API 2.0 to GA With the May '26 release, we are moving the FinDock integration with Salesforce Bulk API 2.0 to General Availability. This is an important [Salesforce enhancement](https://developer.salesforce.com/docs/atlas.en-us.api_asynch.meta/api_asynch/bulk_common_diff_two_versions.htm) that FinDock leverages moving ahead. All sandbox orgs will get Bulk API 2.0 now. For production orgs, we will use a phased rollout over the coming weeks and months. Enabling API 2.0 is not a change to the codebase, so the rollout is not tied to our normal release cycle. Customers will get advance notice by email of the production switchover. We'll send the email using the Contact information in the FinDock Setup. *Please check and confirm the email address* for **Support & product contact**. In our final regression testing before moving to GA, we identified and fixed a minor case where schedules finish while a related job on ProcessingHub appears stuck. This occurred when the job was an empty push task to Salesforce, for example, when no file needs to be attached to the schedule. These types of empty tasks are not needed with Bulk API 2.0 and now skipped. ## Refunds from Salesforce to beta Refunds from Salesforce is now open to all customers for beta testing. Along with the next maturity stage, this exciting feature is expanded to support more PSPs and integration patterns. If you plan to test Refunds from Salesforce, please contact FinDock Support. We are eager to get feedback and work together on your refund use cases. For Stripe customers, note that existing installments cannot be used for testing without additional action. ### New Refund Payments component Package(s): In addition to the invocable action FinDock Initiate Refund that can be used in a custom Flow, FinDock now provides an out-of-the-box Lightning Web Component action for initiating refunds directly from individual records. The new Refund Payments component can be used on page layouts for Installment, Gift Transaction (Fundraising), and NPSP Opportunity. ### Support for Authorize.net and Stripe Package(s): We are happy to announce that you can also initiate full and partial refunds from Salesforce for payments processed through Authorize.net. Refunds from Salesforce is an additional refund option alongside the existing handling of refunds initiated through Authorize.net Quick Refunds. We also now support full and partial refunds from Salesforce for payments processed through Stripe alongside the existing handling of [refunds initiated through Stripe](/docs/payment-processors/stripe#stripe-refunds-and-installment-status-handling). To support processing refunds from Salesforce, please note that we have updated Guided Matching for Authorize.net and Stripe. Also, for Authorize.net, the transaction Id is now added as the Payment Reference on Payment records. ## Paya pilot updates The FinDock integration with Paya (Nuvei) continues with this release. We greatly appreciate the valuable feedback and open cooperation among customers, partners and Nuvei as we steadily improve the integration. ### MOTO recurring payment capture Package(s): **Issue:** When setting up a new ACH recurring payment using MOTO (Payment component), FinDock triggers a payment capture immediately. This results in an untended and unexpected transaction for the payer. **Solution:** The issue was caused by a bug in the Paya recurring payment handling logic for MOTO payments. This has now been fixed so immediate capture is only triggered for one-time payments regardless of payment method. ### Import file type recognition Package(s): **Issue:** The CSV file from Paya used for reconciliation was not always recognized by FinDock when uploaded to Chatter, causing file parsing and extraction to fail on ProcessingHub. **Solution:** The issue was caused by variations in how payer addresses appear in the file. If the address value included a comma, FinDock could not correctly identify the file type as CSV. We have updated the file recognition pattern for CSV to account for this address presentation so that the Paya files are correctly handled. ### Callout enhancement for recurring payments Package(s): To ensure correct validations and checks in Paya/Nuvei systems, we have added an isRecurring flag in the FinDock callout to Paya. This, for example, reduces risk for Card Not Present (CNP) failures since the flag clearly indicates there is already a stored payment method. ### Card brand for MOTO payments Package(s): **Issue:** When setting up recurring card payments through the FinDock Payments component (MOTO), the card brand was not included on the Payment Profile record for the new payment method. **Solution:** We have extended the Payment Profile record creation process through the component to save the card brand on the resulting payment profile. ### Last Collection Date handling update Package(s): **Issue:** The Last Collection Date field on collected installments was getting an invalid date value which could block further actions, like refunds. **Solution:** This issue was caused by FinDock misinterpreting the collection date timestamp from Paya. This is now resolved by a new time format converter that puts the timestamp into the format expected for Last Collection Date. ### Special characters in addresses Package(s): **Issue:** If an address contains a special character, such as Montreal suburb Châteauguay, MOTO payments with Address Verification Services (AVS) enabled fail with an error from Paya: "The field Address must match the regular expression `'^[w'-s.,#/]{0,}$'`." **Solution:** We’ve added unicode escaping to the address fields. This allows special characters to be processed at Paya. ### Payment Schedule status handling update Package(s): **Issue:** If a payment schedule run with Paya as the payment processor fails, the schedule status stays in Processing instead of moving to Failed. Installments attached to the stalled schedule also do not move to Failed, instead staying in an error state. **Solution:** The issue was caused by new logic added to the FinDock Queueable Framework to support payment collection processing through Paya. The new logic set certain jobs to the wrong status when an error occurred which meant FinDock could not move failed jobs to the correct end state. This has now been fixed so that failed payment schedule runs end as expected. ### Card expiration date handling update Package(s): **Issue:** FinDock uses two digits to store the expiration month for a card. However, single month digits in the card expiration date returned by Paya, e.g. 1 instead of 01 for January. **Solution:** We have updated the date handling in FinDock for Paya cards to add a leading zero digit if the month returned by Paya is a single digit. ### New lines in MOTO payment address fields Package(s): **Issue:** If an address with multiple lines is sent to Paya, the payment fails. This can happen when entering an address for MOTO payments, pre-filling the Payment component using Contact or Account address fields, as well as with migrated (or manually entered) multi-line addresses on Payment Profile records. **Solution:** We’ve updated the Paya integration to automatically put multi-line addresses in one line to adhere to the single-line Paya address requirement, replacing new line characters with comma separators. ### Mandate reuse Package(s): **Issue:** When mandate reuse is enabled, FinDock was relying on a token from Paya to identify an existing mandate and payment profile for reuse. This approach could lead to the wrong contact or account being linked to the new payment. **Solution:** In some scenarios, tokens may not be enough to identify an existing Paya payer. To handle this possibility, we have added an additional factor - the Contact/Account record - to determine if the mandate identified for reuse belongs to the payer. ## Core ### New custom base for generated references Package(s): With this release we have added support for custom base references that can be added to values for Bring Your Own generated references. The custom base value is defined by a new field on Installment called Custom Base Payment Reference. If the payment processor-method combination supports Bring Your Own references, this value is pre- or post-fixed to the generated reference depending on the payment method standards. This introduces more flexibility for customers to include custom references yet still get generated, standards-compliant reference value from FinDock. For instance, custom invoice numbers can be added to the new field, and FinDock transforms that into an compliant RF creditor reference. ### New Guided Matching setting for batch processing Package(s): When large transaction sets are processed by Guided Matching, FinDock uses a queueable framework that splits up the transactions into batch jobs. These jobs are processed in parallel to maximize performance. However, the checks and balances FinDock uses to avoid race conditions that may lead to incorrect matching can throttle parallel processing. For certain batch sizes, this makes the performance difference between serial and parallel processing minimal. Very large transaction sets, with over 10,000 transactions in a single set, do benefit significantly from parallel processing. Internal testing shows that these sets can be completed up to 30 times faster with parallel processing. To give customers more flexibility with overall performance versus matching success, we have introduced a new **Processing Mode** setting in Guided Matching setups to allow you to choose serial or parallel processing. For most customers, serial processing delivers similar performance to parallel processing. This is the best mode both for average sized transaction sets and for cases where Guided Matching results must be free of any race condition risk. Customers with very large transaction sets should use parallel processing. However, testing is needed to determine which batch job size works best. **RECOMMENDED ACTION:** Existing installations get the new **Processing Mode** setting, batch handling continues as before with parallel processing. Please evaluate your Guided Matching setups for transaction sets and adjust the setting to use the best processing mode for your use case(s). ### Authorization pattern for recurring payments Package(s): With this release, we have updated several processor integrations to use the authorization pattern based on `InitialPaymentOnRecurring`. This pattern replaces the less flexible, deprecated pattern based on `RecurringRequiresInitialPayment`. Existing installations that use the deprecated pattern are not impacted. ### Guided Matching update for partial refund handling Package(s): **Issue:** Partial refunds for installments with status Collected or Partially Paid could not be processed by Guided Matching. Guided Matching would instead throw the error, “Book all on first is not supported for a debit transaction to receivable installment." **Solution:** We have updated the decision logic used by the Process Installment rule to properly handle partial refunds for the Collected or Partially Paid installment status scenarios. In both, Guided Matching now correctly reverses the refunded amount (debit transaction amount for a receivable installment). Once matched, the installment status is updated to Partially Paid and the Amount Open is adjusted based on the new negative payment amount. ### Null pointer exception in Salesforce Error Console Package(s): **Issue:** The new [Error Console](https://help.salesforce.com/s/articleView?id=release-notes.rn_lc_error_console.htm&release=260&type=5) in the Salesforce Spring '26 release shows null pointer exceptions with certain FinDock components. **Solution:** We identified some unhandled code exceptions which the new console showed as errors. These are now handled properly in our codebase so they do not produce unnecessary errors. ### Setup for MT 940 processing Package(s): **Issue:** The FinDock Setup for (native) MT 940 file processing was missing the **Add account** button if one account (target) was already configured. **Solution:** There were some minor bugs blocking multi-merchant support for MT 940 which caused the UI issue. These have now been resolved so multiple accounts (targets) can be created as expected. ### Permissions for key objects Package(s): **Issue:** When a service agent creates a payment through the FinDock Payment component, exceptions are thrown about missing access to key administration and operations objects including Guided Matching Setup, Inbound Report and Message. This issue appeared only with new installs after the Sept. '25 release. **Solution:** The issue was caused by certain security-related changes and missing permissions specific to the Fundraising (NPC) and Gift Aid source contexts. To resolve the issues, we have updated and expanded the underlying access logic to ensure all FinDock service agent users have the needed object (and field) access regardless of the source context. ### Queueable job calculation Package(s): **Issue:** In a few very specific processing scenarios, mostly related to testing and development, the total number of queueables counted by FinDock’s framework was less than the actual number of executed queueables. This issue does not impact standard customer operations. **Solution:** The issue was caused by a difference between how Salesforce chunks jobs and FinDock’s calculation method. We have now modified how queueable jobs are calculated to ensure the FinDock count stays in line with Salesforce in all possible scenarios. ### Bank Feed transaction bank account and account holder parsing enhancement Package(s): **Issue:** In some scenarios, FinDock’s method for determining the transaction bank account (IBAN) and Account Holder Name leads to incorrect debtor/creditor details in Salesforce. This negatively impacts reconciliation accuracy and financial reporting. **Solution:** This issue was caused by how FinDock selected the counterparty for a transaction, which was based on transaction type. This did not cover scenarios where the transaction direction (debit or credit) does not match the provided counterparty details. To cover all possible scenarios, we have introduced new selection and validation logic which includes a comparison with the given target IBAN. If the new selection logic fails to match a creditor or debit IBAN, FinDock falls back to the transaction type selection. ### Bank Feed reconnect blocked by field permission Package(s): **Issue:** When attempting to reconnect a Bank Feed connection that has expired, FinDock throws an error related to field permissions, "Unable to Connect Account - Field CreatedDate is not editable." This blocks reauthorizing the connection. **Solution:** The issue was caused by how FinDock handles system fields like CreatedDate when creating the new authorization. This has now been resolved by excluding those fields during the creation action for the new authorization. ### MOTO billing address validation update Package(s): **Issue:** When the billing address is required on the Payment component (for Address Verification Services), new payments are blocked if a county is selected that does not have a state or province (Billing State/Province field disabled). This only occurs if the org had [state/country picklists enabled](https://help.salesforce.com/s/articleView?id=xcloud.admin_state_country_picklists_configure.htm&type=5) and a selected country did not have any state/province values for the country. **Solution:** The issue was caused by how the component validates billing address fields. We have updated the validation rules to properly identify Billing State/Province as not required if the selected country does not have a state/province dependency. ### MOTO recurring payments with multiple sources Package(s): **Issue:** If more than one source is active in an org, a new installment for a recurring payment created through the MOTO component (virtual terminal) may use the wrong source. This causes reconciliation of the payment intent for the new installment to fail. **Solution:** The FinDock Payment component relied on the default source in an org for new installments of recurring payments. If the intended source was not the default, reconciliation of the payment intent would fail because only the recurring Id was available. Now the component takes the source from the source-specific recurring payment record and includes it explicitly in the payment intent. ### Payment Profile uniqueness enhancement Package(s): **Issue:** In some payment method-processor combinations, a billing address is included on the payment profile. This is required, for example, when Address Verification Services (AVS) are used. FinDock’s payment profile uniqueness check, however, does not take address fields into account if the bank account number is the same. This could potentially lead to overwriting an existing payment profile rather than creating a new one, resulting in failed payments. **Solution:** We have expanded Payment Profile record uniqueness to include address fields. This is managed through a new field, Billing Address Fingerprint, which is included now on all payment profiles. If the processor-method combination uses a billing address, FinDock automatically generates a normalized hash value as the fingerprint, using address fields as input, and includes that value in the Unique Identifier for the payment profile. The new field is only for the internal uniqueness check and does not change payment processing. It remains empty on payment profiles that do not require a billing address. ### Payment Request Generator list index error Package(s): **Issue:** Due to a bug introduced in the March '26 release with the bulk KID generation update, some Payment Request Generator runs may fail with a “List index out of bounds” error. **Solution:** The bug was related to how reference generation handles campaign members. This has now been resolved so bulk generation runs complete as expected. ## ProcessingHub ### Non-EEA address mapping for pain.001 and pain008 files Package(s): None **Issue:** When generating pain.001 (SEPA Credit Transfer disbursement) and pain.008 (SEPA Direct Debit) files, the structured address information for non-EEA debtors did not comply with the SEPA rulebook. This could result in banks rejecting the files generated by FinDock. **Solution:** This issue was the result of outdated address mapping. If the target setup had **Use latest XML version** enabled, FinDock still used XML entries from the prior standard version to map non-EEA address information. This has now been fixed on ProcessingHub so the information is added to the correct XML elements when the latest XML version is in use. ## WebHub ### Giving Pages and PayLinks accessibility enhancements Package(s): This release includes adjustments to Giving Pages and PayLinks to meet the [Web Content Accessibility Guidelines (WCAG) 2.1](https://www.w3.org/TR/WCAG21/). These changes mainly address making elements such as tabs and labels focusable with accessibility tools. ### State picklist on Giving Pages Package(s): **Issue:** The State picklist is dependent on the Country field and is enabled whenever the given Country value has State values. However, if the Country is set with a default value, the State picklist stays disabled even when it should be enabled. This prevents payers from selecting a state. **Solution:** The issue was caused by a fault in how Giving Pages determines field dependencies when the payment form is loaded. This has now been corrected so the State picklist is enabled also when a default country is used. ## Fundraising ### Bacs DD aggregated installments with Fundraising as source Package(s): **Issue:** When Fundraising (NPC/EDU) is the source, installment aggregation fails and blocks Bacs Direct Debit collection through FinDock or SmartDebit (Access PaySuite). **Solution:** The issue was caused by the unique payment method, Grouped Installment, a temporary payment method used on aggregated installments during processing. This value was not included in payment method fields synced between FinDock and Fundraising objects which blocked updating Fundraising objects. To prevent this block, FinDock now skips syncing the standard Payment Method field when the installment payment method is Grouped Installment and only syncs to the custom field `fdff__Payment_Method__c`. ## Authorize.net ### Updated authorization pattern for recurring payments Package(s): Prior to this release, new recurring payments processed through Authorize.net included a 1 USD transaction for authorizing the payment method details. Because this charge is not required in all cases, we have switched the authorization pattern to make the initial payment optional using the payment method setting `InitialPaymentOnRecurring` [(more info)](/api/initial-payments-for-recurring-payments). When an initial payment is not included for new recurring payments, payers are redirected to a hosted page where they can authorize their payment details without an immediate charge. FinDock processes the authorization and confirmation of the details through Guided Matching using the `payment.authorization.created` event from Authorize.net. Once authorized, the first full installment amount of the recurring payment can be collected as normal through a payment schedule. If an initial payment is included for new recurring payments, for example, by setting the initial payment toggle to true on a FinDock Giving Page, FinDock uses the full amount of the recurring payment for the first installment collection. Please note, however, that new recurring payments set up through PayLinks require an initial payment (also using the full amount). ### Callout URL correction Package(s): **Issue:** While investigating a stuck installment being processed through Authorize.net, we discovered the callout URL structure FinDock uses in the integration to Authorize.net has a portion of the URL duplicated. The incorrect URL worked in test environments, but not in production. **Solution:** We fixed the callout structure to remove the duplicated API endpoint path to Authorize.net. ### Parameter handling in URLs Package(s): **Issue:** If query parameters are included in the Success URL as Javascript, such as appending the URL with ?vFirstName=Mary, the Authorize.net payment form breaks and does not display payment details properly. **Solution:** The issue was caused by how FinDock handled special character escaping in URLs. This has now been corrected so parameters are escaped correctly regardless of whether they are inserted as HTML or as Javascript. ### Multi-line addresses for MOTO payments Package(s): **Issue:** If an address with multiple lines is sent to Authorize.net, the payment fails. This can happen when entering an address for MOTO payments, pre-filling the Payment component using Contact or Account address fields, as well as with migrated (or manually entered) multi-line addresses on Payment Profile records. **Solution:** We’ve updated the Authorize.net integration to automatically put multi-line addresses in one line to adhere to the single-line Authorize.net address requirement, replacing new line characters with comma separators. ## PayPal ### Online redirect handling update Package(s): **Issue:** In some scenarios, the payer is redirected to the Success URL for a new one-time PayPal payment before the payment is actually captured. This can result in the payer seeing a “thank you” page even when the payment capture fails. **Solution:** The asynchronous webhook processing in FinDock’s redirect flow with PayPal did not correctly include PayPal’s charge finalization process for one-time payments. This has now been corrected so the redirect is based on the charge outcome (checkout order event) from PayPal. **ACTION REQUIRED:** Please check and ensure the FinDock webhook configuration in your PayPal app includes the event type **Payment capture declined**. ## Stripe ### Satispay recurring payments Package(s): In the March '26 release, we added support for Satispay to our Stripe integration for one-time payments. In this release, we expand the Satispay support to recurring payments as well. Payment profiles for recurring Satispay payment use the Wallet record type. ## Swish ### Recurring payment error handling Package(s): **Issue:** When a recurring Swish payment transaction fails, the failure notification from Swish is not processed by FinDock. This results in outdated information in FinDock. **Solution:** We have added a new Swish inbound report subtype Payment FAILED and Guided Matching setup. The failure notifications are handled in a similar way to the existing Payment ERROR processing. ### Inbound report handling change Package(s): **Issue:** If the payment intent for a new Swish recurring payment is not completely processed before follow up notifications from Swish, for example, about mandate confirmation, cannot be processed. The Message records are created for the notifications, but inbound report processing gets stuck, resulting in missing mandates (and/and or payment profiles). **Solution:** The inbound reports for payment intents were enriched with information from the Message record as part of notification handling. This enrichment could cause enough of a delay in record creation to cause the issue. To resolve this, we have moved the enrichment to Guided Matching where ordering inbound report processing is properly controlled. ## General maintenance ### Heroku app maintenance Package(s): This release includes version upgrades for software components used in FinDock apps on Heroku. These updates apply to FinDock apps and related access management frameworks. ### Classic Setup end-of-life cleanup continued Package(s): We have removed the remaining code remnants that were exclusively used for the classic Setup, which reached end-of-life with the November '25 release. This includes, for example, VisualForce pages, permissions and Apex classes. The changes in this release impact all packages except Authorize.net , Fundraising, NPSP, Paya, Redsys, SEPA, Swish and Vipps.