# Release Notes - September '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:** August 23, 2026
* **Release webinar:** August 28, 2026
* **To production:** September 20, 2026


Release Webinar
Coming soon...

## Payment Experiences (PILOT)

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.

### More with Flow templates

**Package(s):** 

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

From [FinDock Labs](https://github.com/FinDockLabs/payment-experiences-templates), 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](https://github.com/FinDockLabs/experience-cloud-checkout-template) 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](/docs/payments/payment-form-configuration-options#cover-transaction-fees).

### Custom LWC support for payment method selection

**Package(s):** 

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.

### OOTB currency solution

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

### Improved localization support

**Package(s):** 

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.

### Payment Method Selector Flow variable format

**Package(s):** 

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

### Amount validation

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

### Fundraising package actions

**Package(s):** 

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

### Button styling

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

### Ease-of-use improvements

**Package(s):** 

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.

## NEW PILOT: SEPA Credit Transfer with Amount Open

**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](mailto:support@findock.com).

## Refunds from Salesforce (BETA)

### Support for GoCardless

**Package(s):** 

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.

## Connected apps

### Scheduled token renewal

**Package(s):** 

With the July '26 release, we introduced [new security measures](/release-notes/release-notes-july-26#connected-apps-security-enhancement) 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.

## Core

### Permissions update

**Package(s):** 

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

### Duplicate field name handling

**Package(s):** 

**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](https://docs.findock.com/release-notes/release-notes-july-26#salesforce-api-version-bumping-for-summer-26). 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.

## ProcessingHub

### Bulk API 2.0 batch handling

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

### Bulk API 2.0 record upserting enhancement

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

### Bulk API 2.0 enhancement for LDVs

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

### Bulk API version of delete jobs

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

### Failed processes appear running

**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](https://help.salesforce.com/s/issue?id=a028c00000gAwnvAAC) at Salesforce. With this release, we are introducing a workaround that allows FinDock to parse broken error message content.

## Fundraising

### Support for NextGen Commitment Processing

**Package(s):** 

FinDock now supports NextGen Commitment Processing, a [new batch processing feature](https://help.salesforce.com/s/articleView?id=005387492&type=1) 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.

### Transaction date for yearly Gift Commitment

**Package(s):** 

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

## Gift Aid

### Fiscal year handling update

**Package(s):** 

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

## NPSP

### Opportunity payments for partial refunds

**Package(s):** 

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

### Close Date and Last Collection Date sync

**Package(s):** 

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

### Governor limits on failed records

**Package(s):** 

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

## Adyen

### Support for Gift Card payments

**Package(s):** 

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 using the Museum Card (InterSolve) gift card brand. When enabled, 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.

## Authorize.net

### Transaction Id fallback

**Package(s):** 

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

## Paya

### Installment status for MOTO ACH payments

**Package(s):** 

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

### Recurring ACH payment creation failures

**Package(s):** 

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

## SEPA

### Data Quality component permissions

**Package(s):** 

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

## Swish

### Notification handling enhancement

**Package(s):** 

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

### Recurring payments collection enhancement

**Package(s):** 

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

### Declined event handling update

**Package(s):** 

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

## Vipps

### Vipps MobilePay: Support for Vipps Donations

**Package(s):** 

We are happy to announce support for the [Donations production from Vipps MobilePay](https://vippsmobilepay.com/en-NO/donations), 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.

### Captured event handling update

**Package(s):** 

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

## 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. The Heroku stack itself was also updated.

### PayLinks and Pages

**Package(s):** 

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.

### Data analytics

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