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: October 25, 2026
- Release webinar: October 30, 2026
- To production: November 22, 2026
Release Webinar
Coming soon...
Package(s): Core, Stripe, WebHub
We are happy to announce a major new capability for accepting payments with FinDock: inline payments. What are inline payments? This is a new payment experience that greatly reduces friction and simplifies the payer experience. Rather than redirecting the payer to a hosted payment page (HPP) served by a PSP, often with limited customization options, to enter payment method details. payers stay “inline” with your own fully branded digital experience.
The first iteration of inline payments comes with support for card payments through Stripe. You can accept both one-time and recurring card payments without redirects using FinDock Payment Experiences or custom front-end integrations to the Payment API. Payer authentication challenges, like 3D Secure (3DS) are automatically handled based on merchant accounts settings at the PSP.
If you would like to test inline card payments, please contact FinDock Support.
Package(s): Agentforce, Core, MIDAS
Guided Matching provides a number of rule types to help you improve matching success and enrich Salesforce data. With Agentforce, you can take your reconciliation process even further, both to maximize matching success and solve complex use cases.
For instance, incoming payment data may not be structured as you would need to meet your reconciliation requirements. Key data could be split across multiple incoming records, requiring customization, such as Flow logic, to prepare that data for reconciliation.
That’s where Salesforce AI and the new Prompt Template rule type for Guided Matching comes into play. The new rule type runs the Salesforce Flex prompt template you define and returns the text of the prompt answer. The Prompt Template rule type executes Flex prompt templates from Apex directly within the Guided Matching context, allowing you to do things like normalize data using AI, summarize results, and much more.
Due to the dependency on Agentforce licensing, the Prompt Template rule type is not included in the standard FinDock (Core) package. It is visible from the rule type selector in the Guided Matching setup. When you open the rule type, you are prompted to install the Agentforce for FinDock package. Just click the install link and follow the normal package installation process.
Once the package is installed, you can create new Prompt Template rules, selecting from a dropdown list of templates available in your org. FinDock includes two Flex templates to get you started:
- FinDock: Get Payment Reference from unstructured data: reads the free-text remittance and description fields from the inbound record and returns the single most likely payment, invoice, mandate or installment reference, verbatim as it appears, stripped of surrounding words.
- FinDock: Find and clean account holder name: returns the payer's name in a clean, searchable form, removing, for example, legal-form suffixes and bank-specific markers.
Both templates come with recommended entry criteria. They should only be executed after the standard, deterministic Guided Matching rules have not succeeded on the given field.
Thanks to everyone involved in the piloting of FinDock Payments Experiences, we are now ready to move to beta, meaning the feature is open to all customers and partners. For those of you involved in the pilot phase, please make note of the changes included in the November '26 release notes and documentation.
Package(s): N/A
FinDock Payments Experience templates are now even easier to deploy from FinDock Labs. We consolidated the previously separate template repositories for specific use cases and contexts into a single monorepo, The previous deployment through a third party tool is replaced with an installation process: the template variant is built and installed as an unlocked package.
Package(s): Core
We are pleased to announce that FinDock Payment Experiences can be embedded in external websites using Lightning Out 2.0 right out of the box. Part of Salesforce Lightning Web Runtime (LWR), Lightning Out 2.0 enables you to use LWCs outside Salesforce.
Why is this important? With the right integration partner and/or internal developer expertise, you can dramatically extend your digital payment experiences beyond what you host directly on Salesforce. Lightning Out 2.0 means you can use your Salesforce-native digital experiences anywhere. Embed in Salesforce multi-framework sites (based on React), external apps, host sites on your own server or through a hosting service, etc.
We’ve put together a step-by-step configuration guide for Payment Experiences with Lighting Out 2.0 to help you get going building your next-level digital experiences.
Package(s): Core, SEPA
FinDock Payment Experiences now supports e-mandates for SEPA Direct Debit payments processed through FinDock.
With SEPA e-mandates configured, FinDock’s Payment Experiences components include additional configuration options for e-mandates. Complete these new settings, and your digital payment experience automatically presents the e-mandate authorization flow to the payer when the SEPA Direct Debit payment method is selected.
Please note that the SEPA e-mandates is a paid add-on feature currently in pilot and limited to the Netherlands with e-mandates signed through Incassomachtigen.
Package(s): Core
Issue: When using the PayButton component to pay an existing installment, the resulting payment intent may use the wrong currency in multi-currency orgs. This would lead to failed installment collection.
Solution: The issue was caused by how Payment Experiences identifies the default currency if a payment intent does not specify currency. For paying existing installments, the generated request now uses the currency from the Installment record instead of the default currency of the Guest User.
Package(s): Core
Issue: The payment intent callout built by Payment Experiences did not include the configured target (merchant account) in the payment method block, causing issues with payment collection tests if there was no default target available for fallback.
Solution: We identified and fixed the bug causing the target to not be included in the payment intent callout so that multi-merchant configurations and default fallbacks now behave as expected. We also unified naming conventions across components to make the use of “target” and “merchant account” more transparent.
We are happy to announce the FinDock integration with Paya (Nuvei) is now generally available for all FinDock customers. This change includes the enhancements and fixes outlined in the following sections.
Package(s): Paya
Issue: FinDock currently uses Order Id to ensure idempotency when making capture callouts to Paya. However, this is not a reliable indicator of uniqueness if connection timeouts or other delays extend the capture process beyond a certain period.
**Solution:**As we work towards a proper idempotency key definition with Nuvei, we have implemented an additional Order Id check in the payment capture process. This additional check is used before retrying an installment collection that experiences a callout timeout with the previous capture.
Package(s): Paya
To make troubleshooting easier, we have added more details to logs generated by callouts to Paya. We can improve logging in Paya to have proper error messages. Installment updates from callout events now have details Transaction Id, Order Id and status-related information.
Package(s): Paya
With this release, we improved how FinDock handles commas in the JSON payload of Paya settlements to correctly interpret amounts above 999 USD. Larger amounts use commas to indicate, for instance, thousands. These commas are now excluded from the value separation logic when FinDock parses the settlement.
Package(s): Paya
Prior to this release, if a transaction is immediately refunded, FinDock attempted to reverse the payment before it is settled at Paya. The service agent’s action results in the error ProcessingError: An error occurred on our system while processing this request. Please contact our developer support team., causing a delay in returning money to the payer.
FinDock now supports voiding (unsettled) payments. This is a separate process at Paya that is automatically triggered by the refund action. FinDock handles Salesforce data for voided payments the same as for refunds.
Package(s): Core, Paya
Extended Logging (x-Verbose Header for Nuvei API) is no longer available with the new Nuvei Middleware API. FinDock was using the logging details to enrich payment profiles for ACH with the payer’s bank routing number.
With this release, we have removed use of Extended Logging in the FinDock integration with Salesforce and are exploring alternatives for getting the routing number required for ACH payments.
Package(s): Core, SEPA
With FinDock as native processor, you can use the Amount field or the Amount Open field in payment schedules for SEPA Direct Debit and SEPA Credit Transfer. This option has been in closed pilot and is now available for all customers for beta testing. Please note, enabling the open amount logic is a one-way migration and cannot be reverted once enabled.
Package(s): N/A
We are happy to announce the Refunds from Salesforce feature is now generally available for all FinDock customers.
Package(s): Core, MIDAS, ProcessingHub, WebHub
With the November '26 release, we are happy to announce that we have completed our development work for migrating FinDock connected apps (CAs), including ProcessingHub, WebHub and MIDAS, to the new External Client App (ECA) framework.
While we have completed internal testing of FinDock’s new ECA packages, the overall timeline for migration remains open at Salesforce. Nonetheless, we are preparing for multiple rollout scenarios and have implemented fallback mechanisms to ensure both CA and ECA approaches continue to work.
If the ECA migration falls outside FinDock’s normal release cycle, we will communicate the changes through our standard FinDock Status and FinDock Knowledge Base channels.
Package(s): WebHub
With ongoing development at Salesforce around app security hardening, app connection stability has been a challenge. This is the case for existing Connected Apps (CAs), and a question moving forward with External Client Apps (ECAs).
As part of our preparation for migrating to ECAs, as well as to further improve our response times to connection issues, we are rolling out enhanced, pro-active connection monitoring for ProcessingHub and WebHub. The improved and streamlined alert system does not impact customer orgs. These are backend changes to FinDock’s internal tooling for our customer support and product development teams.
Package(s): Core, WebHub
Issue: If there is an error during the initial setup of the connection to ProcessingHub or WebHub, the failure is not clear. The user can end up on an unrelated Salesforce page or back to the FinDock Setup with an incorrect connection status.
**Solution:**The issue can arise when, for example, app permissions block the OAuth flow. We have updated the connection handling for both ProcessingHub and WebHub, to properly capture connection failures. A failed attempt takes the user back back to the right setup page where the error reason is presented.
Package(s): Core, WebHub
We’ve added a new option to hide the frequency and amount for a recurring payment PayLink. The Hide amount and frequency for recurring is off by default and does not appear in the Payment Form setup for one-time PayLinks.
When using this new option, please keep in mind that some payment methods require you to communicate the amount and frequency when collecting recurring payments. Ensure these details are clearly communicated via other channels if they are not present on your PayLink page.
Package(s): WebHub
Issue: After the September '26 release, the Due Date on PayLinks payment forms appeared blank, confusing payers.
Solution: The issue was caused by a new coding capitalization requirement in the updated version of Vue rolled out with the September ‘26 release, where the bug failed silently. We’ve now updated backend Due Date configuration setting to comply with the new requirement.
Package(s): Core
Issue: On the Transaction Set layout (Lightning record page), the Unmatched Transactions related list doesn't show Transactions with a Failed status.
Solution: We’ve updated the filter for the Unmatched Transactions related list to include Failed status since these are also relevant to users who need to investigate unsuccessful reconciliation.
Package(s): Core
With this release, we are enhancing the search capabilities within the Guided Review component of the Process Installment rule. The default search behavior prior to this release could leave reconciliation users uncertain if the queried installment was in fact correct and/or eligible.
To make the search function more transparent, we introduce new filters in the Guided Review portion of the Process Installment rule configuration. You can now adjust the searchbox behavior and search results with new filters that address relevance (does the installment belong to the same payer as the inbound record) and eligibility (can the queried installment be processed).
With these new filters, users can be certain they are searching and selecting the right installments for allocation during the review process.
Package(s): N/A
Issue: If Guided Matching finds multiple installments that go to Guided Review, the review interface does not show the Ids of all matched installments, but rather repeats the first installment Id. This creates addition manual work during review and may lead to incorrect payment remainder handling.
Solution: There was a bug in the way FinDock determines when to read the Multiple Installment Ids field in the Transaction or Inbound Report. We resolved the logic issue so that Guided Review displays all Ids of the matched installments as expected.
Package(s): Core
Issue: A custom Query rule can return incorrect results when used on the Installment field of Inbound Report or Transaction. With the Take All strategy, the queried object record Ids are returned instead of the configured Return Field id. The incorrect Ids are written to the Multiple Installments Ids field, causing the Process Installment rule to fall.
Solution: We identified and fixed the bug causing the issue. The Take All strategy now behaves as expected, similar to the the single-result and Take First strategies. Installment Ids are written to the Multiple Installments Ids field, with empty or repeated values removed.
Package(s): Core
Issue: In certain conditions, when editing a Guided Matching rule setup, the Where-clause does not appear in the setup UI. Closing and re-opening the setup model would usually fix the issue.
**Solution:**The issue was caused by how the setup data is fetched and displayed in relation to how the setup page is refreshed. This has now been resolved so the setup page always shows the latest available data.
Package(s): Core
Issue: When an object doesn’t have a Name field, such as the Case object, FinDock writes a log about the issue each time the rule setup is viewed, leading to excessive and unneeded log data. The rule execution plan would also display an incomplete or unusual name for the rule on the missing field.
Solution: We identified and fixed the issue leading to fields appearing in a rule setup that are not available for the selected object. Additional filtering was added to support the object-specific alternatives to Name, like Case Number on Case.
Package(s): N/A
Issue: Running processes fail the "Update Config data if outdated" step if Salesforce returns a 403 error when FinDock checks the Salesforce Identity URL.
Solution: The issue was caused by a conflict between the scheduled token renewal logic introduced in the September ‘26 release and existing auto-retry logic on ProcessingHub. ProcessingHub did not merely log the temporary 403 error and retry the job again. Instead, the error was handled strictly as a failure, causing the impacted process to fail. We’ve now updated the auto-retry logic to treat 403 errors the same as temporary 401 errors, allowing ProcessingHub to retry a job after a new access token is acquired.
Package(s): N/A
Issue: In some cases, ProcessingHub may reject or return an invalid XML error when a file is first uploaded. Retrying the job, however, results in successful extraction.
Solution: The issue was caused by inefficiencies in error buffering on ProcessingHub. We have improved several areas of XML file handling to eliminate the buffer issue. In addition, we have extended error responses to provide more specific information when XML file handling issues arise.
Package(s): N/A
Issue: Heroku automatically restarts dynos every 24 hours. If this occurs while a ProcessingHub worker is processing a job, the job may be interrupted or left in a state that needs manual intervention to recover.
Solution: We have implemented a new, proactive worker reset cycle to help avoid jobs being impacted by dyno restarts. If the worker is handling a job that runs beyond the FinDock reset cycle, the job is allowed to run as long as needed. Please note, however, that if the job needs more than 24 hours, the job may still be impacted by the Heroku dyno restart schedule.
Package(s): Core, Fundraising
Issue: When a Gift Transaction record is created (not linked to Gift Commitment and Gift Commitment Schedule) for a SEPA Direct Debit donation, FinDock for Fundraising creates a Mandate record with Type Recurring instead of One-Off. This can lead to a risk of double-collection for one-time gifts.
Solution: The issue was caused by a missing Type declaration in the mandate creation call to FinDock Core from the source package. Core defaults to Recurring if Type is not specified for the mandate. This has now been fixed so the mandate Type correctly reflects whether the gift transaction is a one-time payment or part of a new recurring gift commitment.
Package(s): N/A
We’ve updated the FinDock for Fundraising flows on FinDock Labs so they are fully compatible with the Salesforce Winter ‘27 release. We also made a few adjustments to further improve the Flows. The changes include:
- Upgraded Salesforce API version to 68.0 for Manage Gift Commitment Schedules and Update Recurring Gift Commitment Schedule flows
- Updated validation to allow non-negative transaction amounts below 1
- Fixed a bug in the Campaign lookup where updating schedule dates would lead to an object-type mismatch error
- Added Campaign and Source Code lookup pre-fills during upgrade/downgrade (Campaign was only shown in the summary before)
- Applied custom schedule screen styling
Please also note that we have changed how Fundraising Flows are deployed. They are now included in an org-dependent unlocked package to simplify installation and future updates (now through package versions). For existing customers: installing over a source deployment updates matching components and brings them under package ownership. Local customizations can be overwritten, and uninstalling can remove those components, so we recommend testing this update in a sandbox first.
Package(s): Gift Aid
Issue: HMRC rejects Gift Aid Declarations that have an incorrectly formatted postal code, and certain cases were not caught by the existing validation rules used by FinDock.
Solution: We have expanded Data Quality rules to validate the format of postal codes end-to-end on Gift Aid Declaration records (gaid__Postalcode__c). Rather than checking for a specific pattern in the field, the entire postal code value is checked to ensure it conforms to HMRC expectations.
Package(s): NPSP
Issue: If a collected installment is later rejected, FinDock does not create a corresponding negative Opportunity Payment record to offset the existing positive Opportunity Payment record. This leads to incorrect data for the linked opportunity.
**Solution:**The issue arose from changes made in the March '26 release. While those changes correctly handled the target context (payment rejected before installment is collected), the update was overly broad and eliminated logic to check collected installments for existing opportunity payments. We have now implemented logic so that FinDock correctly checks for existing positive payments and creates negative opportunity payments when a collected installment is rejected, as was the case prior to the March '26 release.
Package(s): Authorize.net
Issue: Installments in large payment schedule runs may fail with the error Exceeded maximum time allotted for callout (120000 ms). Failed installments required manual corrective action from FinDock Support.
Solution: The timeout is a cumulative callout limit from Salesforce, and sufficiently large payment schedules may hit this limit. To reduce the risk of this issue occurring, we have improved the queueable framework for Authorize.net payment schedules with optimized job sizes, better debouncing, and more transparent logging to better support reconciliation of installments that fail due technical errors.
Package(s): Authorize.net
Prior to this release, if a transaction is immediately refunded, FinDock attempted to reverse the payment before it is settled at Authorize.net. This could lead to a processing error and cause a delay in returning money to the payer.
FinDock now supports voiding unsettled payments. This is a separate technical process that is automatically triggered by the refund action. However, FinDock handles Salesforce data for voided payments the same as for refunds.
Package(s): Authorize.net, Core
Issue: With some payment schedule runs, processed installments continue to have status New. The status of these installments may later be correctly updated by notifications from Authorize.net, but some remain unchanged without manual intervention.
Solution: The issue is caused by race conditions between payment schedule processing jobs and the timing of notifications from Authorize.net. To counter these race conditions, we have added new processing checks and additional logic around status locking and updating. In addition, we have added new, more transparent error handling to better surface errors that may arise from race conditions.
Package(s): Core, Stripe
FinDock now supports one-time payments with Pay by Bank in the FinDock integration to Stripe. An online banking payment method that uses Open Banking standards, Pay by Bank delivers secure account-to-account transactions. This payment method needs by enabled at Stripe (merchant dashboard) before it can be used by FinDock.
There is no additional FinDock configuration required to take this payment method into use other than activating the method in the Stripe payment extension setup. Once activated, the method is available through the Payment API, Giving Pages and PayLinks. FinDock currently only supports one-time payments when Pay by Bank is the selected payment method.
Package(s): Stripe
We have added a new option, Skip verification, to the PAD Verification Method setting for Stripe merchant accounts. When enabled, FinDock explicitly sends Stipe a skip request as part of the payment intent callout. However, please note that this skip option only works if the merchant account has passed Stripe's compliance process. Using the skip option without prior approval from Stripe will cause every new PAD payment intent to fail.
Package(s): Notification Gateway, Swish
Issue: In some payment schedule run scenarios, installments that are in fact collected appear to be stuck with Pending processing status.
Solution: The issue can arise when the paid notification (inbound report subtype Payment PAID) arrives and is processed before the payment schedule has finished. This creates a race condition, causing the installment status to change from New to Collected, then back to Pending processing. To avoid this, we have reduced the number of sequential payment requests to Swish per batch job. In addition, we added a mechanism to prevent closed states like Collected from getting changed back to Pending processing.
Package(s): Vipps
Vipps Donations payment reports can include details about the donor, classified as “GDPR sensitive data” as explained this FAQ. The message and payer elements provide information that can be used, for example, to personalize follow-up actions.
To support this information source, the FinDock integration with Vipps Donations now supports collection the information in those elements of the payment report. The data is added to the RAW XML Entry field of the Inbound Report record (sub-type DONATIONS_PAYMENT_CAPTURED), so you can create custom Guided Matching rules to enrich Salesforce records with that data.
Package(s): Worldpay
Issue: If a card payment is completed with a card that has a single-digit expiration month, the inbound report for the payment intent fails in Guided Matching with duplicate value error.
Solution: This issue was caused by how FinDock builds the Unique Identifier for the payment event. The identifier uses the expiration month returned by Worldpay, which is a single digit for January through September. This breaks the Payment Profile lookup during Guided Matching. To resolve the issue, FinDock now applies a two-digit format during the Payment Profile matching process, adding zero-padding, e.g. returned 1 for January becomes 01.
We completed a major round of updates to a wide range of FinDock object and field-level descriptions. This work closes gaps and improves many existing texts to help users better understand FinDock.
Package(s): Core
To ensure compatibility with the latest features in the Salesforce Winter '27 release, we have updated the FinDock Core package Apex classes and other components to use Salesforce API version 68.
Package(s): ProcessingHub, WebHub
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. The Heroku stack itself was also updated.