Release Notes - September '26

Important dates

• To sandbox: August 23, 2026
  
• Release webinar: August 28, 2026
  
• To production: September 20, 2026

Release Webinar

Watch on YouTube.

Thanks to all our pilot customers and partners, the FinDock Payment Experiences feature is getting better and better. As the pilot continues, we bring many improvements big and small to building digital payment experiences with FinDock.

Package(s): Core

We are happy to announce new and expanded Flow templates for FinDock Payment Experiences!

From FinDock Labs, you can now deploy donation Flow templates specifically designed for the UK nonprofit market. These new templates, one for Fundraising (NPC/EDU) and one for NPSP, include pre-configured steps for setting up new Gift Aid declarations as part of the donation flow.

We also have a new single-page template for you to jump start your FinDock Payment Experiences development. The template is ideal for simple, single page use cases, like a payment checkout page. Deploy the template directly from FinDock Labs and customize it to fit your needs.

In addition to the two new templates, we updated all donation Flow templates to support covering transaction fees. This allows you to easily offer donors the option to cover your processor’s transaction fees, similar to the out-of-the-box solution we have for Giving Pages.

Package(s): Core

We have further refined the Payment Method Selector component (a managed LWC) with support for custom LWC development. Intended for pro-code developers who need complete control over the user experience, we designed a complete, templated solution available through FinDock Labs. In addition, we provide a script you can use to quick generate the required configuration file based on the FinDock Setup in a given org.

Package(s): N/A

To help you build digital payment experiences in multi-currency contexts, we now provide an unmanaged currencyPicker component out of the box. You can use the component in Flows as well as in pro-code LWC solutions with the existing paymentForm template. The currency component features dedicated settings for defining allowed and default currencies, as well as smart fallbacks. This includes a new Apex class which is called to check the org’s active currencies.

Using this component is not mandatory. You can still create your own solution to pick a currency, including through Flow.

Package(s): Core

As part of our ongoing development of FinDock Payment Experiences during the pilot phase, we have further improved localization support (languages, date formats, etc.). These improvements impact FinDock managed LWCs as well as templates available from FinDock Labs. For details and guidance on how to localize FinDock Payment Experiences, please refer to the Sept. 26 version of the pilot documentation, in particular, the getting started article.

Package(s): Core

Issue: When saving a Flow variable as a value for a payment method parameter, the value becomes a flat text the next time the configuration editor is opened. For example, {!EmailInput} becomes EmailInput, which can block payment collection.

Solution: We identified and fixed the bug causing the issue. Flow variable values now retain the correct format.

Package(s): N/A

Issue: The amount on the unmanaged Amount & Frequency component was not correctly validated, leading to scenarios where an empty amount was allowed though an amount is required.

Solution: Amount validation logic has been added to our Flow templates for Fundraising and NPSP. The screen now blocks navigation until an amount is selected, with an accessible required/range error (focus moves to the field for screen readers). One-screen flows were already covered by isAmountSelected visibility.

Package(s): Core

Issue: When the Fundraising Gift Tribute package action is added to the payment intent, the generated JSON from the Pay Button did not include the package action.

Solution: We identified and fixed a bug in the package action context handling which caused the issue. All package actions are now properly serialized and included as expected.

Package(s): N/A

Issue: Buttons in FinDock managed components used the brand color setting of the Experience Cloud site and ignored custom button color styling.

Solution: Button coloring now follows the expected styling priorities of an Experience Cloud site. If a custom button color is set, that is used. If not, the buttons use the site brand color. If no brand color is set, FinDock falls back to SLDS defaults.

Package(s): Core

Based on internal testing and pilot feedback, we identified and implemented several improvements to the Payment Method Selection component and payment method configuration in the Pay Button component. Alongside adjustments to visual presentation, we made structural modifications that make the configuration of one-time versus recurring payments clearer.

Package(s): N/A

We are introducing a new collection logic to allow customers to disburse SEPA Credit Transfer payments based on the Amount Open field of the given Installment record. This new logic allows payment schedule runs to use the remaining amount of an outbound payment (payable installment) rather than the original full amount. For instance, if a payout has already been completed, that can be subtracted from the installment Amount, and the next schedule run creates a payment instruction for the Amount Open value.

The new logic is available self-managed SEPA Credit Transfer using FinDock as a native processor. If you would like to participate in piloting the new payment extension, please contact FinDock Support.

Package(s): GoCardless

We are happy to announce our fourth supported Payment Service Provider with Refunds from Salesforce. In addition to Authorize.net, Paya and Stripe, you can now initiate full and partial refunds from Salesforce for payments processed through GoCardless. Refunds from Salesforce is an additional refund option alongside refunds initiated through the GoCardless dashboard.

Package(s): WebHub

With the July '26 release, we introduced new security measures to meet new requirements from Salesforce connected. These changes resulted in some unexpected disconnections with ProcessingHub and WebHub due to expired refresh tokens. In scenarios where an access token does not expire because the app connection is actively used, the refresh token remains unused over its 30-day lifespan. When the refresh token expires after 30 days, Salesforce revokes both the refresh token and the access token, causing the connections to ProcessingHub and/or WebHub to fail.

We have now implemented scheduled access token renewals for FinDock’s connected apps to pro-actively use refresh tokens to renew access token so neither token expires.

Rules with query logic, such as Create Record, Update Record and Query rule types, now support extract JSON values directly from the Raw Message field of an Inbound Report record. If the Raw Message field is selected in the query setup, a new Extract value from key checkbox appears. When checked, an additional text box appears where you specify the key.value pair for the extraction.

Package(s): Core

Issue: When creating installments or sources-specific payment records like Gift Commitments, users who have the FinDock Payment Operator permission set group assigned get an INVALID_CROSS_REFERENCE_KEY error on Installment insert.

Solution: The error was due to missing Receivable record type access in the Payment Operator permission set group. This was a gap in FinDock’s permissions design which only emerged from the enhancements Salesforce introduced with the API v67 upgrade. We have now closed the gap by extending the FinDock Core Payment Schedule Run permission set with the record type access.

Package(s): Core

Issue: If a query includes custom fields with API names that overlap with FinDock’s namespace fields, or otherwise only differ in capitalization, the query, such as those used in Guided Matching, would fail with a duplicate field error.

Solution: The issue was a side effect of the Summer '26 compatibility changes in our July '26 release. After the update, database queries did not have the same level of deduplication logic that previously handled API name collision more gracefully. With this release, we re-introduce deduplication logic with clear error messages to indicate where and why the name collision occurs, as well as properly handle null reference errors in queries.

To give customers more control over FinDock processing performance with Salesforce, we have introduced a new setting that allows you to set which version of the Salesforce Bulk API is used for ProcessingHub. By default, FinDock uses Bulk API 2.0. You can change to Bulk API (version 1) through FinDock Setup > Connect settings. When you select Bulk API, you additional settings for concurrency mode (parallel or serial) and batch size for processing records of a given object, such as Installment.

Package(s): N/A

Issue: In very large payment schedule runs, data loads with Bulk API 2.0 are split into batches and handled sequentially. When this occurs, the related process on ProcessingHub incorrectly moved to the next process step without waiting for all batches to complete. This resulted in incorrect totals for counters related to the process and schedule.

Solution: We have fixed the bug causing the issue so that processes, and related counter calculations, wait for all batches to complete as expected.

Package(s): N/A

Issue: In certain scenarios, record upserts from ProcessingHub can fail with the Bulk API 2.0 integration.

Solution: This issue was caused by a bug in how job completeness was determined, which in turn masked a second bug in transaction field mapping for the ProcessingHub and Salesforce sync for upserts. These bugs have now been resolved so the Bulk API 2.0 integration performs as expected with record upserts.

Package(s): N/A

Issue: When very large numbers of records are deleted in an org, the sync with ProcessingHub consumes a significant amount of processing capacity, slowing down or blocking other jobs running on ProcessingHub.

Solution: We identified a bottleneck in our Bulk API 2.0 integration that resulted in inefficient processing when handling millions of staged deleted records. We’ve optimized the query logic for identifying records to delete so that overall performance of the Bulk API 2.0 remains higher than Bulk API, as expected.

Package(s): N/A

Issue: Delete jobs in ProcessingHub Manager were incorrectly tagged as Bulk API rather than Bulk API 2.0 data load jobs.

Solution: FinDock uses Bulk API 2.0 for data load jobs, but the delete logic used the incorrect version flag. This has now been fixed to avoid confusion on the frontend.

Package(s): N/A

Issue: If an error message from Salesforce includes a line break, the impacted process remains indefinitely in Running state instead of transitioning to Data Load Error. This can lead to stalled processing queues on ProcessingHub.

Solution: The issue has appeared with the new Bulk API 2.0 integration and is the result of a known issue at Salesforce. With this release, we are introducing a workaround that allows FinDock to parse broken error message content.

Package(s): Fundraising

FinDock now supports NextGen Commitment Processing, a new batch processing feature in the Summer '26 release of Salesforce. The batch processing logic required a change in how FinDock populates the Salesforce standard Payment Method field when creating new gift commitment schedules.

Package(s): Fundraising

Issue: When the payment method on a monthly or yearly Gift Commitment record is updated through FinDock channels like MOTO or PayLinks, the new Gift Commitment Schedule record used the wrong date for the next Gift Transaction record. This would occur if the updated commitment had an active schedule, and at least one gift transaction had already been collected.

Solution: By default, FinDock used today’s date to set the Effect From Date on the new gift commitment schedule. This triggered incorrect recalculations by Salesforce for already active commitment collections. To properly handle the built-in logic of Salesforce, we have extended the logic used by FinDock to determine the Effective From Date for monthly and yearly gift commitments with already active collections so that the next gift transactions are have the expected due dates.

Issue: In some scenarios, updating existing Gift Commitment records using recurring PayLinks or the Payment API results in inbound reports with an error about dates, “Error "Enter an {0} value that's on or before the {1} date."

Solution: This error, exposed by a fix in the July '26 release, is due to a specific issue with how FinDock identifies which Gift Commitment Schedule record was closed and which is the newly created record that should be updated by future inbound reports. To resolve the issue, we updated the Gift Commitment Schedule query to first check if the Id of the passed record has already been modified (and thus has a new successor). If there is a successor, that record is now updated by future inbound reports instead of the current Gift Commitment Schedule record.

Package(s): Gift Aid

Issue: The formulate FinDock uses to determine Gift Aid eligibility of an installment may be wrong in scenarios where the org’s fiscal year does not start in January.

Solution: The issue was caused by an incorrect Current Fiscal Year custom setting value after an update for the Gift Aid package has been installed. We adjusted the calculations by extending the user access in the installation context, so the date is now preserved.

Package(s): Core, NPSP

Issue: With the new FinDock Refunds from Salesforce feature, both full and partial refunds can be initiated from Salesforce. However, when NPSP is used as the source, only full refunds automatically triggered creation of (negative) Opportunity Payment (npe01__OppPayment__c) records.

Solution: We have extended the trigger context to include installment status changes to Partially paid so new negative opportunity payments are created for partial refunds. FinDock uses the Collection Date from the negative Payment record (of the refund) to fill in the Payment Date (npe01__Payment_Date__c) on the newly created negative Opportunity Payment record based on certain processing assumptions. If these are not met, FinDock falls back to Date.today() for Payment Date. Please keep in mind that refunds initiated from Salesforce are only reflected in NPSP after FinDock receives confirmation from the Payment Service Provider.

Package(s): NPSP

Issue: The FinDock for NPSP source connector has a setting to automatically sync Opportunity Close Date with Installment Last Collection Date. However, if this setting is disabled, FinDock would still update the opportunity date when the linked installment date changed.

Solution: This issue was caused by a missing settings check in the bi-directional sync between the two date fields. The Close Date equal to Last Collection Date setting was checked for Opportunity → Installment, but not for Installment → Opportunity. We have now fixed this so the check is performed for both syncing directions as expected.

Package(s): Core, NPSP

Issue: If there are a large number of failing records, FinDock wrote an error log for each failing record. This could cause the org can hit governor limits which prevented FinDock logging from surfacing the underlying functional issue.

Solution: To stay below governor limits in such a scenario, we have bulkified error message handling which reduces the number of log events.

Package(s): Adyen, Core

We are happy to announce support for Gift Cards, a new payment method for the FinDock integration with Adyen. Support for Gift Card payments is currently limited to one-time payments. When Gift Card is enabled for your account at Adyen, payers can choose to redeem their gift card value for a full or partial payment. When the card value does not cover the full payment amount, payers are automatically offered iDEAL | Wero as an alternative method to pay the remaining amount.

Package(s): Authorize.net

Issue: The response payload from Authorize.net can have the transaction Id in different locations, but FinDock processed the response based on only one of the possible locations.

Solution: If no value is included in the merchantReferenceId or merchantCustomerId fields of the response, FinDock falls back to extracting the transaction Id from the invoice number field included in the Raw XML content on the inbound report.

Issue: In certain scenarios, Guided Matching can get into a loop that consumes the queueable limits of an org. This occurs when the Is It My Turn rule cannot determine handling order based on the notification event date.

Solution: The issue can occurs when the values in Event Date and Event Date ISO8601 fields of the notification cannot be interpreted, such as when a value is null. To avoid this, we have added new fallback logic for those fields to safeguard against comparing null values when determining inbound report handling order.

To improve overall performance of the FinDock integration with Paya (Nuvei), we have implemented new logic for handling temporary service outages with the Nuvei credential endpoint. Prior to these changes, temporary 502, 503, or 504 responses were treated as successful, resulting in a misleading exception and failed installments. Now FinDock classifies the responses before parsing exceptions, with installments that hit temporary issues treated as retry candidates.

Issue: FinDock implemented a debounce mechanism to retry callouts to Paya when an error occurs. However, the debouncing could lead to overly complex, performance heavy processing when the encountered error simply means the installation collection failed.

Solution: We have narrowed the debounce mechanism to exclude errors that should be investigated rather than retried. The impacted installment is now set to Failed in these instances with further details stored in the Last Failure Reason field as expected.

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 experience a callout timeout with the previous capture.

Issue: The automatic update for expired Paya access tokens can lead to locked row exceptions in payment schedule runs. When this occurs, the affected installment is not updated as expected and may also be picked up by the next payment schedule run, creating the potential for double collection.

Solution: After additional investigation, we determined FinDock does not need to use persistent tokens, but rather can re-request tokens for each individual job. By making new requests with each job, the integration with Paya is more stable and less complex, eliminating issues with concurrent saving of access tokens on Salesforce.

Package(s): Paya

Issue: One-time ACH Direct Debit payments created through the FinDock Payment component (MOTO) did not appear in the Paya dashboard. However, the installments in Salesforce have status Collected.

Solution: We found and fixed the bug caused this issue. One-time MOTO payments for ACH direct debit are now handled the same as one-time credit card payments and immediately processed through Paya.

Package(s): Core, Paya

Issue: Creating a recurring ACH payment back to back leads to a failed inbound report with an error message about duplicate values. This issue was observed during testing when the same or similar payer data is used to create payment intents.

Solution: The timing of the payment intents did not cause the issue, but rather whitespace handling. Masked account values returned by Paya have a leading whitespace, which is automatically trimmed by Salesforce when the value is stored. This caused the inbound report error during Guided Matching. We have now updated the Paya processing logic to properly handle the whitespace trimming step so that account values can be matched as expected during Guided Matching.

Package(s): SEPA

Issue: Users with correctly assigned permissions could not use the Data Quality component on payment schedules. The component would instead show an error related to insufficient permissions.

Solution: The issue was caused by an incorrect user mode for a query introduced in the July '26 release for SEPA e-mandates. This has now been resolved.

Package(s): Swish

Issue: Mandates may remain in Pending Registration state even after a Consent DECLINED notification arrives indicating the payer declined to approve the mandate.

Solution: The issue was caused by the timing of Swish notification arrivals. If the Consent DECLINED event arrived before the related payment intent inbound report processing is completed, there was no payment intent reference available to match the inbound report for Consent Declined. To handle this scenario, we have added a new FindPaymentIntentId Guided Matching rule for Consent inbound reports that executes before the GuaranteedOrdering rule. The new rule finds the original Message record of the Consent notification using its cpm__External_Id__c, extracts the payment intent reference, and inserts it into cpm__Payment_Intent_Id__c. This ensures the guaranteed ordering logic works as expected by setting the Consent inbound report status to Pending if no payment intent reference is found.

Package(s): Core, Swish

Issue: Recurring Swish payments are collected via payment schedules, and successful collection is confirmed via notifications from Swish. Under certain conditions, the notification may arrive before FinDock has added the payment reference value to the Generated Payment Reference field on the Installment record being collected. That reference value is needed for Guided Matching, so the inbound report for the Swish notification fails on the "Find Installment by Transaction Code" rule. Retrying the rule later, once FinDock has added the generated value, resolves the issue.

Solution: To avoid this timing issue, we have changed how FinDock works with payment references for Swish. Instead of generating a value as part of the collection process, FinDock now uses the Installment GUID field, normalized to meet Swish requirements. This field is always present for Installment records, removing the chance of Guided Matching failures due to missing FinDock-generated values. The normalized GUID is used as the payment reference sent to Swish and is also added to the Generated Payment Reference field on installments.

Package(s): Swish

Issue: In some scenarios, an installment remains in Pending Processing even though a related Payment Failed inbound report has been created, which, once processed, should update the installment status to Failed.

Solution: The issue was caused by a missing Payment Intent Id in the Swish event payload. As a result, the related installment could not be found and updated. To handle this payload scenario, we updated the Guided Matching rules to use cpm__Inbound_Report__c.cpm__Transaction_Code__c to find and match the installment by its cpm__GUID__c (or by cpm__Generated_Payment_Reference__c for backward compatibility) instead of cpm__Payment_Intent_Id__c. This approach removes the dependency on Payment Intent Id when updating installments.

Package(s): Core, Fundraising, Vipps

We are happy to announce support for the Donations production from Vipps MobilePay, a new integration through the Vipps payment extension. Donations payments are recorded as installments with a new Vipps Donations payment method, separate from the existing standard Vipps and MobilePay payment methods. Vipps Donations payments are set up via the Vipps MobilePay app and collected by the Vipps MobilePay service.

The FinDock integration enables you to get Donations payments automatically into Salesforce through webhooks from Vipps MobilePay. FinDock processes events through Guided Matching for starting and stopping donation agreements, as well as for changes (amount or withdrawal day) for active agreements.

This integration requires dedicated merchant accounts, so this update introduces a new merchant account subtype split for Vipps MobilePay. The existing standard payment methods use subtype Payments, and subtype Donations is used for reconciling Donations payments.

A new FinDock heartbeat job checks for new Vipps Donations transactions which are captured as inbound reports with subtype DONATIONS_PAYMENT_CAPTURED. These reports are processed through Guided Matching with a specific set of rules separate from standard Vipps payments.

Package(s): Vipps

Issue: After the July '26 release, processing inbound reports for Captured events appeared to fail for installments with the Vipps payment method.

Solution: A modification to the FinDock integration with Vipps changed how FinDock handles recurring.charge-captured.v1 events. This event should be ignored, but instead resulted in inbound reports with type VIPPS.Captured that would fail in Guided Matching. With this release, the recurring.charge-captured.v1 event is again ignored since it is not needed for payment reconciliation. This issue did not impact installments with the MobilePay payment method.

Package(s): Installer, MIDAS, Notification Gateway, 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.

Package(s): WebHub

This release includes a major version upgrade of VueJS, from version 2 to 3, used with PayLinks and Pages. The prior version was longer under active support, so this upgrade ensures security patches and other enhancements can be applied.

Package(s): N/A

With this release, we are rolling out new backend infrastructure for FinDock data analytics, which are used for billing, performance monitoring, and so forth.

The rollout will be gradual, first to sandboxes and then to production orgs. For a short period of time, two data exports may appear for the same day in orgs. This has minimal impact on org limits as the scope of FinDock queries is relatively small.

Once we confirm data is flowing to the new infrastructure correctly, the old infrastructure will be disabled for all orgs, and the data exports from FinDock go back to single daily queries.