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: June 21, 2026
- Release webinar: June 26, 2026
- To production: July 19, 2026
Release Webinar
Coming soon...
This release includes important security-related changes for connected apps and Salesforce Summer '26.
Package(s): Core, ProcessingHub
If you joined or viewed the May '26 release webinar, you got an early sneak peak at one of our biggest new features in recent years. FinDock Payment Experiences brings the power of FinDock to Experience Cloud, unlocking a whole new world of digital experiences you can build directly within Salesforce.
The backbone of FinDock Payment Experiences are new managed Lightning Web Components (LWCs) with advanced configuration editors to make designing the payment experience within your digital experience easy. The managed Lightning Web Components of FinDock Experience Payments can be easily used in Flows for building digital payment experiences. They can also be used to extend your own customer Lightning Web Components for even greater control of the payer experience. In addition, we:
- Built templates for ready-made sites, pages and flows help you kickstart your digital experience development
- Ensured our designs are WCAG2.2AA compliant
- Designed new permission sets to make Guest User access easier to set up
Please join us at the July '26 webinar to learn more and be a part of this exciting new development. If you are ready to sign up for the pilot, just fill out our form.
Package(s): Core, SEPA, WebHub
We are happy to announce a new pilot feature, e-mandates for SEPA Direct Debit. The pilot scope covers FinDock native SEPA Direct Debit processing for select banks in the Netherlands that support digital signatures using Incassomachtigen.
Prior to this release, the FinDock e-mandate solution was tailored to the Sweden market and Autogiro direct debit payments. In Sweden, the electronic ID (eID) for online mandate sign-up uses the payer's BankID app for verification.
For SEPA Direct Debit payments in the Netherlands, FinDock has built a new integration to Incassomacthigen to enable digital signature of e-mandates directly in the payer’s bank environment. In addition, we have expanded the scope of pain.009 and pain.012 processing to support the required mandate management provisions according to the SEPA rulebook.
This solution helps reduce revenue loss, reduce fraud, reduce the cost of dispute handling and shortens the legal complaint period from 13 months to 8 weeks.
If you would like to participate in this pilot, please contact FinDock Support.
Package(s): Core, GoCardless
We are happy to announce support for GoCardless Outbound Payments. For the UK market, GoCardless enables credit transfer payments through their Outbound Payments feature. GoCardless Credit Transfer uses the UK Faster Payments System for near instant settlement.
FinDock supports this payment method for bulk outbound payments through payment schedules. Our support for GoCardless Outbound Payments is launched as a pilot feature.
If you are interested in participating, please contact FinDock Support.
Package(s): Core
Issue: When using the Payment API to update an existing recurring payment, the payer may abandon the update process. If this occurs after the payer is redirected to a hosted payment page, the existing mandate and payment profile are unlinked from the recurring payment. This could potentially result in missed payments that are still outstanding and payable under the existing mandate and payment profile.
Solution: We updated the logic for handling mandate and payment profile changes to make sure they are maintained should the update process for an existing recurring payment be abandoned at any point.
Package(s): Core
Issue: If a Bank Feed account (target) contains spaces, like PostFinance CH1234512345, FinDock throws the error “Unable to retrieve GM rules from Labs…”.
Solution: The issue was caused by the automatic check FinDock performs to see if there are applicable Guided Matching rule templates on FinDock Labs. The space in the account name was incorrectly escaped in the corresponding repository URL. This has now been fixed so the Labs check is completed successfully as expected. We have also narrowed the scope of the Labs check so that it is only performed for Bank Feed accounts.
Package(s): Core
Issue: If an Inbound Report record is a partial reversal (debit) for a collected installment that has multiple payments, and the inbound record goes to Guided Review, the Save & Continue button is disabled, preventing reversal processing from being completed.
Solution: The issue was caused by how FinDock calculated amount differences when processing the incoming record and comparing payment amounts for the matched installment. The calculation logic has been updated so that Guided Review works with partial reversals as expected.
Package(s): Core
Every new Salesforce org has Data 360 enabled, and any Data Model Object (DMO) may contain relevant data for improving your Guided Matching performance. This is especially true for Fundraising (NPC/EDU) where source attributions for campaigns are often in Data 360.
To support this Data 360 capability, we are introducing a new Guided Matching rule type, the Data360 Query Rule. With this rule, you can query all available DMOs and their related fields like any standard SOQL query.
The new Data360 Query Rule is only available in orgs where Data 360 is enabled.
Package(s): Core
When the Handle Refund rule was initially designed, it was added to the Installment lookup field on Inbound Report. While the only option at the time, there is a better option now.
As part of the Refunds from Salesforce feature development, we have added a Refund lookup field to Inbound Report. This is the more logical place for the Handle Refund rule execution, so we have moved the rule to the Refund lookup.
In addition, we have extended the Guided Matching setup for refunds to allow customers to add custom rules on the Refund lookup field before or after the Handle Refund rule.
Package(s): Core
For certain business cases, such as invoice matching, multiple installments may be paid by a single transaction. To support this, we have updated the Query rule when used to find installments. Now, if multiple installments are found and the result strategy is Guided Review, users can view and select multiple records in the Guided Review step rather than only one.
Package(s): Core
Issue: For certain Guided Matching use cases, particularly Bank Feed transaction matching, the booking date and time are used in Regular Expression (regex) queries. However, the Regular Expression rule type only supported the date.
Solution: We expanded the Regular Expression rule type logic and corresponding setup to support the full booking date and time scope. Now, as part of the rule setup, the Capturing Group includes everything from Year to Seconds, as well as timezone. Year, Month and Day remain required. Hours, Minutes, Seconds and Timezone are optional. Note that if Timezone is not defined, the default is UTC 0:00.
Package(s): Core
Issue: During internal testing, we identified a scenario where pre-filling the Country for Address Verification Services (AVS) in the MOTO component prevents a payment from being completed.
Solution: The issue arose in cases where Country is pre-filled with a value that does not have any State dependencies (in Salesforce). With this release, we have eliminated the potential issue by introducing an additional dependency check to correctly support the no-States (null picklist value) scenario.
Package(s): Core
Issue: The summary stats for payment schedules, like number of installments, total amount, etc., are recalculated on a daily basis through the FinDock Heart Beat. For customers with large data volume (LDV) orgs, the recalculations can consume a large portion of Salesforce Apex limits.
Solution: We have introduced a new limitation on the automatic recalculations through FinDock Heart Beat. For Payment Schedule records with status Done, the automatic calculation is performed once, and further automatic recalculations are skipped. You can still update the summary statistics by manually triggering the recalculation on the Payment Schedule record. If the status is changed from Done to some other status, automatically recalculations resume as normal through the scheduled heartbeat.
Package(s): Core
Issue: The generation phase of payment schedules fails if custom payment reference is used without a generated payment reference.
Text: The issue was caused by a change in the May ’26 release. This has been resolved so custom payment references are properly handled as before.
Package(s): Core
FinDock allows payers to pay existing installments as a Salesforce Guest User for public Experience Cloud sites. This would fail for environments created after FinDock’s security enhancement for the September '26 release. For the update process to complete, we removed updating by Guest User on all objects except Message.
Package(s): N/A
Issue: Bulk API 2.0 charge processing correction
Solution: An issue in the May ’26 release caused Bulk API v2 payment processing to stall when files contained mixed installment identifier formats. This affected file processing flows with associated charges and could cause push processes to remain stuck. Charge handling logic for Bulk API 2.0 has now been corrected so that processes complete as expected.
Package(s): N/A
Issue: An issue introduced with the May ’26 Bulk API v2 rollout caused Data Load processes to remain stuck in Running state when Salesforce returned validation or locked row errors containing apostrophes (for example: Can't save this record). This prevented processes from transitioning to Data Load Error whenever there was a data load error.
Solution: We identified and fixed a bug in the failure status handling logic for Bulk API 2.0 processing so states are updated correctly when Salesforce returns errors with apostrophes.
Package(s): Authorize.net
Issue: If a payment schedule that had already reached the Process phase was manually set back to an early phase, all installments linked to the schedule were re-sent regardless of their status. As Authorize.net does not support idempotency, this would lead to double collection.
Solution: To reduce the chances of double collection when re-running a payment schedule manually, we have added a status check to only send installments with status New or Pending recollection. Please note that if an installment was not updated yet when the schedule state is manually changed, for instance due to the update getting blocked by a validation rule, it could still be collected again.
Package(s): Authorize.net
Issue: Authorize.net may decline payments set up through the FinDock Payment component (virtual terminal). However, the payment appeared successful in the component interface, yet the status of the Installment record remained in a Pending processing state.
Solution: The issue was caused by a gap in payment processing for Authorize.net. We have now extended error handling so that FinDock not only checks whether the request itself was successful, but also checks the response from Authorize.net and shows in the component if the payment was unsuccessful based on the response code.
Package(s): Core, Fundraising
Issue: FinDock cannot process installment batches if custom logic blocks actions on the linked gift transaction. This issue was noticed with GoCardless where all installments in the batch were rolled back to an uncollected state because a custom validation rule prevented one gift transaction update.
Solution: The issue was caused by a conflict between FinDock’s batch processing logic and an automatic re-trigger mechanism in Salesforce error handling. We have now resolved the conflict to support partial success in batch processing. If a gift transaction update fails, the linked installment is set to Failed. After this, FinDock tries to update the gift transaction status to Failed. If that also fails, both the installment and gift transaction are rolled back to their original state. The rest of the installments in the batch are processed normally.
Package(s): Core, Fundraising
Issue: In some scenarios, existing Gift Commitment records cannot be updated using recurring PayLinks or the Payment API, resulting in inbound reports with errors. This occurs when the gift commitment is related to a gift commitment schedule that started in the past.
Solution: The issue was caused by how FinDock was handling updates to Gift Commit Schedule records. The recurring payment change results in a new Gift Commitment Schedule record (according to Salesforce actions), but the inbound report processing also tried to update the previous (now closed) schedule. This has now been resolved so the schedule updates are handled correctly and the Gift Commitment record is updated as expected.
Package(s): Gift Aid
FinDock’s Gift Aid solution, a unique Salesforce-native, HMRC compliant offering, has helped nonprofits across the UK, transforming Gift Aid from a manual burden into an automated revenue source.
With this release, we are excited to add a new feature that gives Gift Aid managers even more flexibility working with Gift Aid declarations. Now, in addition to the existing management features and logic, you can pause declarations. Whether pausing individual declarations or using Salesforce tooling to pause many, the pause lasts as long as you need. Use pausing to confirm declaration details with the donor, complete custom checks and balances on your Gift Aid process… whatever best suits your organization.
When a Gift Aid declaration is paused, FinDock does not use it for new Gift Aid claims. Already processed claims linked to the paused declaration are unaffected. All aspects of the declaration remain fully under your control with no impact on the record’s validity according to HMRC rules.
Package(s): Core, Gift Aid, WebHub
You can now add Title when setting up Gift Aid declarations for your donors and include the title in the claim to HMRC. A new Custom Title field on Gift Aid Declaration is automatically populated by the Salutation field on Contact if available and can be overridden, similar to how First Name and Last Name are handled. The final title for the claim is stored in the existing Title field on the declaration.
The new Custom Title field is available through the Payment API in Gift Aid package actions. We have also implemented it for the Gift Aid form on Giving Pages.
To be able to use Title with Gift Aid, you need to enable it on your Gift Aid source connector settings. There is a new Include Title In Claim File option you can enable from the FinDock Setup. Please note that full stops in titles are automatically removed from the HMRC claim file because it is an unsupported character.
Package(s): Gift Aid
With this release, we introduce a managed layout (Lightning Record Page) for the Gift Aid Declaration object. The managed layout, called Gift Aid Declaration Record Page, helps us better present changes and improvements to Gift Aid that impact declaration management.
The new managed layout is the default for new installations after this release. If you would like to use the layout, please manually assign the new Lightning Record Page through Salesforce Setup.
Package(s): ProcessingHub
To help Gift Aid managers handle audits of claim files, FinDock now orders claims within the file according to the Gift Aid Declaration record linked to the claim. For example, if an auditor from HMRC selects a random entry from the top 100 claims in the file, the ordering makes it easier to find details about the related declaration.
Claims are ordered according to two data points. First, they are ordered (descending) according to Date Made, so the claims with the newest declarations are at the top of the file. Second, because Date Made does not include time, we use Salesforce Id to further order declarations (descending) that have the same date.
To ensure claim generation performance with the additional ordering process, we made a few small adjustments to backend Gift Aid data structuring.
Package(s): NPSP
Issue: FinDock cannot process installment batches if custom logic blocks actions on the linked NPSP opportunity. All installments in the batch are rolled back to an uncollected state if, for example, a custom validation rule prevents one NPSP opportunity update.
Solution: The issue was caused by a conflict between FinDock’s batch processing logic and an automatic re-trigger mechanism in Salesforce error handling. We have now resolved the conflict to support partial success in batch processing. If an NPSP opportunity update fails, the linked installment is set to Failed. After this, FinDock tries to update the NPSP opportunity status to the status mapped with Failed. If that also fails, both the installment and opportunity are rolled back to their original state. The rest of the installments in the batch are processed normally.
We are happy to announce that the Paya for FinDock payment extension is moving to beta and open to all customers. The beta version includes important enhancements and fixes outlined in the following sections.
Package(s): Core, Paya
Prior to this release, installments and refunds for Paya were always first set to Pending Processing. They were then updated to Collected and Refunded, respectively, as part of the reconciliation process using a settlement file form Paya.
Both installment collection and refunds, however, can be closed when they are successful based on the immediate responses FinDock gets from Paya. To support this immediately closing option, we have introduced a new setting for Paya merchant accounts in the FinDock Setup. With the new Close with settlement file toggle, you can tell FinDock to use the Pending Processing handling path or to close records immediately when successful.
Package(s): Core
Issue: The Payment Reference field value on Payment records is used for refunds initiated from Salesforce. This field was incorrectly populated for payments initiated through online payment channels like Giving Pages. If a refund was later initiated, the processing at Paya would fail because the transaction could not be identified.
Solution: The Payment Reference field is now correctly populated with the Payment Transaction Id from Paya in all channels.
Payment records prior to this release need to be updated with the correct Payment Reference if you plan on using them with Refunds from Salesforce.
Package(s): Paya
Issue: When a new recurring ACH Direct Debit payment is set up, the routing number is not captured on the Payment Profile record, which prevents collection.
Solution: The routing number (stored in the Branch Code field on Payment Profile) is not returned with the hosted payment page capture. To get the routing number, FinDock now makes an additional callout to Paya as part of Guided Matching, while processing the Enrich Payment Profile rule.
Package(s): Paya
Issue: When setting up new recurring donations with Paya as the payment processor, the Next Donation Date on the Recurring Donation record and the Close Date of the next scheduled NPSP Opportunity record are different. These two dates should be the same, but because they are not, this may potentially result in a skipped collection. This was noticed through internal testing of NPSP setups without Enhanced Recurring Donations enabled.
Solution: The issue was caused by how FinDock processed installments synchronously through Guided Matching versus how NPSP handles standard (non-enhanced) Recurring Donation changes. With this release, we have added an additional step to the processing logic for Paya to support standard Recurring Donation behavior in NPSP.
Package(s): Core
Issue: Payment schedules use inline validation during the Processing phase to check data quality. If a linked record fails validation, the schedule run cannot complete.
Solution: Although in some scenarios inline validation is preferred, with Paya as the payment processor, there is no need to block all installments linked to the schedule from being collected. We have therefore disabled inline validation in this release. The Data Quality component can (and should) still be used to validate records after the Generate step so issues can be resolved before the schedule starts the Processing phase.
Package(s): PayPal
Issue: A change in PayPal webhook event handling in the May '26 release could lead to a scenario where certain events are not processed in the correct order due to when they arrive. The incorrect ordering results in failed inbound reports for those events.
Solution: We’ve enhanced the ordering logic for incoming events from PayPal to ensure events are processed in the required order regardless of when they arrived.
Package(s): Core, Vipps
In addition to merchant-initiated agreement cancellation, FinDock now also automatically processes agreements cancelled by Vipps users. To support payer-initiated cancellations, we expanded our Vipps MobilePay integration and added a new Inbound Report subtype MANDATE_STOPPED.
The new Inbound Report subtype and associated Guided Matching rules processes the cancellation event from Vipps MobilePay. The related Mandate record is deactivated and the status is updated to Cancelled.
Package(s): Vipps
Issue: When a payer sets up a new recurring Vipps payment, FinDock automatically creates a new mandate (and payment profile). However, if the related inbound report process fails due to some customization, retry Guided Matching for that inbound report would continually fail with the error: Insert failed. First exception on row 0; first error: DUPLICATE_VALUE, duplicate value found: cpm__Unique_Mandate_Id__c duplicates value on record with id...
Solution: When retrying the inbound report, FinDock did not first check if the Mandate record already exists with the given reference. Instead, FinDock tried to create another new mandate with that reference, leading to the error. With this release, FinDock first checks existing mandates as part of Guided Matching. If the mandate reference is found, that mandate is linked to the inbound report. If the reference is not found, FinDock continues with creating a new mandate as normal.
Package(s): MIDAS, Installer, ProcessingHub, WebHub
As noted earlier this year in our FAQ about connected apps, FinDock has been evaluating how our connected apps fit into the External Connected Apps switchover at Salesforce. Since then, the technical requirements became clearer so that we could begin implementing them in the framework for FinDock connected apps.
With this release, we are rolling out new Proof Key for Code Exchange (PKCE) and Refresh Token Rotation (RTR) mechanisms. These work in the background to maintain the tight security of OAuth flows required by the Summer '26 Salesforce release.
The existing procedures for installing FinDock connected apps do not change. The new security policies should not impact existing connections.
We are pushing these changes to production orgs ahead of the July '26 production release to meet Salesforce-imposed deadlines for PKCE and RTR usage. The planned hotfix for production will got out during week 26 (June 22-26).
Package(s): Core, Fundraising
This release includes Salesforce platform API version bumping for Apex classes and triggers, Lightning Web Components, etc. to version 67. This update ensures compatibility with new features and changes in the Salesforce Summer '26 release.
Salesforce API version 67 introduces new sharing and access behavior. Specifically, if sharing is not declared in an Apex class, the default is now with sharing. Similarly, if access level is not declared, the default is now USER_MODE rather than SYSTEM_MODE. To ensure full transparency in our security model, we have implemented declarations now in all impacted code.
No action is required unless you have non-standard or restrictive permission configurations. These may break with the Summer ‘26 changes. Please validate your permission by running your typical regression tests.
Package(s): Installer, MIDAS, Notification Gateway, 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.