Release Notes - September '25

Important Dates:

• Release to sandboxes: August 31, 2025

• Release webinar: September 5, 2025

• Release to production: September 28, 2025

Reminder - classic permission sets end-of-life

With the May '25 release, we announced the FinDock classic permission sets reach end-of-life (EOL) with the November '25 release to production. After EOL, the classic permission sets are no longer updated by FinDock, becoming unmanaged permission sets you can keep or unassign. FinDock users should be assigned FinDock permission set groups.

Bank Feed to GA

We are very happy to announce Bank Feed is moving to General Availability (GA) with this release. Many customers already are benefiting from the automated bank transaction importing and matching provided through Bank Feed. Thanks to your feedback, we are bringing several improvements as part of the move to GA.

New balance and summary fields on Transaction Set

With this release we have added Opening Balance and Closing Balance values to each imported transaction set. The Closing Balance comes directly from the fetched account information, while Opening Balance is calculated based on the sum totals of credit and debit transactions included in the imported transaction set.

In addition, we’ve added the following summary fields that are automatically calculated. These can be used for reporting and other business processes.

• Number Of Credit Entries
• Number Of Debit Entries
• Total Amount Credit
• Total Amount Debit

New Guided Matching rule templates

Transaction details tend to be presented differently from bank to bank, and the information can be quite complex and difficult to extract. To help our Bank Feed customers, we are introducing an entirely new rule template solution for Guided Matching. The bank-specific rule templates are hosted on FinDock Labs for easy adoption.

When a bank account is connected using Bank Feed, FinDock automatically checks the repository for templates for that bank using the first four digits of the BIC. If rule templates are found, they are added to the default Guided Matching setup for that account, alongside the managed rules already provided.

For existing bank accounts that have new templates available, the rules can be added manually through the rule selector popup where we have a new Rule Templates section.

Expanded remittance information for matching

Payment reference information essential for matching during reconciliation is handled by banks in many different ways. To provide Bank Feed customers the full range of possible data sources, FinDock now extracts data from two additional incoming fields, Remittance Info Structured Array and Remittance Info Unstructured Array.

If these arrays contain any data, the information is extracted and added to the Transaction record as coma-separated values in Remittance Information or Remittance Information Long. You can use the extracted information to find payment references for matching installments by using Query rules on the fields Remittance Information and/or Remittance Information Long.

New page layout for Transaction

With this release, we have a new page layout for the Transaction object, FinDock Transaction Record Page. This improved layout presents a more complete, structured view of transaction details split into four areas:

• Bank Statement Information
• Matching Information
• Detailed Information
• System Information

In addition, in the right pane includes a new Related Payments that shows any Payment records created from the transaction.

This new layout is the default assignment for new FinDock installations.

New page layout for Transaction Set

With this release, we have a new page layout for the Transaction Set object, FinDock Transaction Set Record Page. This improved layout presents summary information in the right-hand pain, while two new related records lists in the main view show matched and unmatched records.

This new layout is the default assignment for new FinDock installations.

New notifications about account status

To help customers keep their Bank Feed connections authorized, ensuring automatic transaction imports keep running, we are introducing a new notification system.

• If an account authorization is expiring soon (less than two weeks left), a warning callout is displayed on all FinDock Setup pages.
• If an authorization expires, blocking transaction importing, an error callout is displayed on all FinDock Setup pages. Both callouts include a call-to-action to reauthorize the connection as soon as possible.

In addition, we have created a new Flow template available through FinDock Labs that you can use to trigger emails about expiring or expired account authorizations.

Enhanced license management

FinDock Bank Feed is an optional paid feature with a license that sets the number of active bank account connections you can have. To make the licensing model and usage more transparent, we have added several new elements to the Bank Feed setup:

• Updated information and guidance on the main settings page about how to get a license.
• New integration with FinDock license management that enables real-time status checks and immediate provisioning of license changes
• New warning and error messages for various states, like when the allowed connection limit is reached

General Bank Feed performance improvements

As part of the release to GA, we have implemented various improvements that will hep with the long-term performance of Bank Feed importing. This includes a new custom index for the Account Servicer Reference field on Transaction.

Correction for additionalDataStructured field

Issue: Transaction imports fail if the transaction data includes content in the additionalDataStructured field.

Solution: The additionalDataStructured field is added to the Raw XML Entry field of the inbound report where all data included in the transaction is captured. However, there was an issue with the way data is parsed into the Raw XML Entry. We have now improved the mechanism used for the Raw XML Entry field so that all data is available for reconciliation, regardless of its originating location or structure in the transaction.

Status for connected but expired accounts

Issue: If an account is connected but the authentication has expired, the account may not appear in the list of accounts. This can happen if auto import is not enabled when the authentication expires, causing the FinDock Heart Beat to miss the status change.

Solution: We have implemented an additional status check for connected accounts when opening the Bank Feed setup to catch expiration dates and correctly update the account status to Expired when the date has passed.

Enhanced Recurring Payments with FinDock Standalone

FinDock Standalone, where FinDock objects are the source of payment data for business logic, gets a major upgrade with this release, both in terms of new features and much improved capabilities particularly around recurring payments.

New installment generation method for Recurring Payment

When FinDock is used as the source of payment data (FinDock Standalone), the Recurring Payment object defines the duration, frequency, amount, etc. of recurring collections. Until now, Installment records for each recurring collection have been generated during payment schedule runs.

This approach works from some recurring payment use cases. However, there are many more advantages from having Installment records in the org before they need to be collected, providing much needed flexibility for a wide range of business processes.

Moving ahead, when FinDock is used as the source, installments are generated through the FinDock Heart Beat. A new generate installment heartbeat checks Recurring Payments records on a daily basis to determine if an Installment record should be generated. If the Last Collection Date is equal to or before today, the heartbeat generates an installment with a Due Date equal to the current Next Collection Date, which in turn is recalculated for the next collection.

For existing FinDock Standalone installations, installment generation remains part of the payment schedule process as before. Customers who want to switch to the heartbeat-based generation can do so by updating the new custom setting Generate Installments From Heartbeat under PaymentHub Settings (cpm__PaymentHub_Settings__c) from false (unchecked) to true (checked). For additional mode switchover guidance, please refer to the Sept. 25 version of the FinDock Standalone article.

Payment schedule additional SOQL for installments

With the new heartbeat-based installment generation mode for FinDock Standalone, the additional SOQL on payment schedules can now be used to filter and refine a schedule’s scope based on installment data. With the previous schedule-based installment generation mode for FinDock Standalone, the additional SOQL queries Recurring Payment records (since the relevant installments are not yet generated).

New daily and weekly frequencies for recurring payments

Recurring payments with FinDock Standalone (Recurring Payment records) now support daily and weekly collection frequencies. When Daily is used, the first collection is made on the Start Date (Collection Day of Month is ignored). When Weekly is used, the day of the week is determined by the Start Date, and Collection Day of Month is ignored.

The new Daily and Weekly frequencies available through the Payment API and PayLinks.

New Recurring Payment layout and components

We are making our native Recurring Payment object even better for managing recurring payment collections. With this release, we have three major enhancements:

• New Upcoming Installments Preview Lightning Web Component (LWC)
  This can be added to any Recurring Payment layout and is included by default in our new layouts. The component calculates and shows future installments that have not yet been created. Up to 10 future installments are displayed with their expected Due Date, Amount and Payment Method.
• New FinDock Recurring Payment Record Page
  This Lightning Record Page has a clean header and two equal regions. The left side has fields (with dynamic layout) and a related list. The right side contains the new Upcoming Installments Preview component along with a dynamic related list Uncollected Installments which shows already created installments that are not in a final state (not Collected, Refunded, Paid or Cancelled).
• New Recurring Payment Compact Layout
  The compact layout includes he following fields: Name, Start Date, End Date, Active, Frequency, Amount, and Payment Method.

These enhancements are assigned by default in new FinDock installations after the Sept. '25 release. Existing layouts can assign the new Lighting Record Page.

Update for first collection of new recurring payment

Issue: In some scenarios, the first collection for a new Recurring Payment record is later than what the payer or payee would expect. This was due to the way FinDock calculated Next Collection Date, Collection Day of Month, and Frequency.

Solution: We have updated the collection logic around Start Date for Recurring Payment records to correct the following scenarios:

• Start Date is before Today and Collection Day of Month is 31
  If the Start Date is June 1st, the Collection Day of Month is 31, and today’s date is June 26, then FinDock would set Next Collection Date to July 31. Now the Next Collection Date will be June 31st.
• Start Date is before Today and Collection Day of Month is 2
  If the Start Date is June 1st, today’s date is June 26, and Collection Day of Month is 2, then FinDock would set Next Collection Date to August 2nd. Now the Next Collection Date will be July 2nd.
• Start Date is equal to Today and Collection Day of Month is 3
  If the Start Date is June 26th, today’s date is June 26, and Collection Day of Month is 3, then FinDock would set Next Collection Date to August 3rd. Now the Next Collection Date will be July 3rd.
• Start Date is equal to Today and to Collection Day of Month
  If the Start Date is June 26th, today’s date is June 26, and Collection Day of Month is 26, then FinDock would set Next Collection Date to July 26th. Now the Next Collection Date will be June 26th.

Next Collection Date calculation update

Issue: If the Collection Day of Month for a Recurring Payment record is not available, i.e. the date is 29, 30 or 31 and the given month does not have that many days, FinDock did not fall back to the last day of the given month when calculating Next Collection Date.

Solution: We have updated the Next Collection Date calculation logic to always fall back to the last day of the month if the date does not exist for a given month. FinDock returns the original Collection Day of Month for the following months. This update address the following scenarios:

• Collection Day of Month changed
  If the Collection Day of Month is 31 and the Last Collection Date is e.g. November 30, the Next Collection Date was set to December 30 instead December 31. Now FinDock returns to the Collection Day of Month when calculating Next Collection Date after a month where the collection day was not available.
• Next Collection Date wrong
  If the Collection Day of Month is 31, FinDock set the collection date for February to March 3rd, or for Sept. 3rd, it would be set to Oct. 1st. Now FinDock uses the last day of the month when the Collection Day of Month is not available for the given month.
• Next Collection Date passed
  If a new recurring payment has a Start Date in the future, but Collection Day of Month is not set (-None-), then FinDock would calculate a passed date for Next Collection Date. Now in this scenario Start Date is used for the first Next Collection Date calculation.

Mandate creation for new payment profile

Issue: If you update the payment profile for an existing Recurring Payment record and save the change, the linked mandate was not changed. The linked mandate needed to be manually removed to trigger creating a new mandate. This could lead to failed collections.

Solution: When the payment profile linked to a recurring payment is updated, the existing mandate is automatically removed and replaced with a new mandate when the change is saved if auto-create mandates is enabled. Additionally, if mandate reuse is enabled, FinDock first checks if the new payment profile has an existing child mandate, and if so, links that to the recurring payment.

Guided Matching

Guided Matching support for reversing partially paid installments

With this release we have expanded the Process Installment rule decision matrix to automatically process reversals of partially paid installments in both single and multiple installment matching scenarios.

If Guided Matching matches a partially paid installment and the inbound record debit amount equals the already paid amount, the installment is set to Reversed. A negative Payment record is created for the debit amount, and the Amount Open on the installment is reset to Amount. If the debit amount does not equal the already paid amount, the inbound record is set to Guided Review.

For matching examples, please refer to the September '25 version of the Process Installment rule decision matrix.

Enhanced logging for Guided Matching

To make automated matching changes more transparent, we have expanded the information included in the Guided Matching Log field on Inbound Report and Transaction objects. The following items are now part of log entries for the Process Installment rule type:

• transactionType: indicates if the incoming record is a credit or debit transaction
• installmentType: indicates if the matched installment is Receivable or Payable
• decisionInfo: for variable outcomes, such as over payments, describes the calculation results, e.g. “Overpaid. Remainder credited to next matched installment.”
• overpaidStrategyUsed: indicates which Overpaid Strategy was used, if applicable

New page layout for PaymentHub File

With this release, we introduce a new page layout for the PaymentHub File object. The updated layout includes related lists for Installment and Payment records linked to the PaymentHub File record. These enhancements help payment operations users track and monitor reconciliation through Bank Feed and batch processes. The new layout is called FinDock PaymentHub File Record Page and is the assignment for new installations.

Enhanced Guided Review for batch matching

When we introduced batch matching through Guided Matching, the Guided Review component of the Process Installment rule remained as is, with the focus on reviewing single installments. With this release, the Process Installment rule has been enhanced to clearly separate settings for single versus batch matching.

Enhanced logic for batch matching

We’ve further improved the Core logic around batch matching through Guided Matching. In this release:

• We improved handling of updates of installment to allow partial matching success instead of all or nothing at batch level.
• For batch validation, we improved how matching is restarted, taking into consideration payments created for the batch file already in earlier tries.
• Batch matching related errors are now stored in the Last Failure Reason field on the installment and the installment status is set to Failed. Error messages include references to related Job records for troubleshooting.

Guided Matching Transaction record matching

Issue: In certain scenarios, multiple Transaction records may be incorrectly matched to the same installment. This can lead to incorrect installment data.

Solution: This issue can arise if two Transaction records are being matched to the same payer IBAN at nearly the same time, where one is New while the other has status Pending. This can lead to both getting matched to the same installment instead of separate installments for that IBAN. To prevent this, we have expanded an existing status check as part of Transaction record processing. When a new transaction is picked up for matching, FinDock now first checks for transactions with the same IBAN that have status Pending, as well as Processing. If one or more records are found, the new transaction is set to Pending, which prevents records from being processed at the same time.

Core

New search layouts for Inbound Report and Messages

To further enhance ease of use and improve payment data findability, particularly for payment operations, we have created two new search layouts that are available in new FinDock installations.

Inbound Report search layout

Search view: CreatedDate, Report Type, Report Subtype, Installment, Payment Intent Id, and Status

Messages search layout

Search view: CreatedDate, Type, related Inbound Report, Handler, Status, and Payment Intent Id

Support ending for Workflow Rules

Salesforce is ending support for Workflow Rules, so we have deactivated the one Workflow Rule remaining in FinDock and replaced it with a new Apex trigger in the Core Mandate service.

Further security enhancements

As a continuation of the July '25 security enhancements, in this release we introduce further enforcement measures related to Salesforce FLS and CRUD permissions.

Payment Schedule counter calculation enhancement

Issue: Recalculating Payment schedule statistics through the daily FinDock Heart Beat could consume a large portion of an org’s Async Apex limit. Hitting the limit prevents further Async Apex executions.

Solution: We have refactored and refined the calculation logic to significantly reduce the number of Async Apex jobs executed by the CalculatePaymentScheduleCountersBeat heartbeat. Now it first assesses if there has been a modification since the last calculation and only recalculates if there was a change. FinDock then employs varying calculation strategies to further minimize Async Apex executions. In addition, we updated the FinDock Core Base permission set, as well as legacy PaymentHub All FLS and PaymentHub Operations permission sets to make sure all relevant users have access to the payment schedule stats fields.

Double collections from automated payment schedules

Issue: After the July '25 release, in some cases payment schedules with auto-run enabled would lead to double collection. The schedule would reach a state where payment instructions are created, but then get set back to an earlier state, leading to payment instructions being created a second time.

Solution: Security-related refactoring deep in the FinDock codebase removed a locking mechanism that allowed race conditions in payment schedule automation. Related processes running at nearly the same time result in different data depending on which process finished last. In some cases, this would mean the Status on the payment schedule could be set back to an earlier value. The locking mechanism has now been restored to the pre-July '25 queueable framework.

In this release we have introduced new validation and process locking mechanisms to prevent automated schedules from causing double collection. The validation blocks attempts to set a schedule Status to an earlier value that could cause double collection. If an attempt is made, that process fails and a new error is logged indicating what happened. The locking, in turn, prevents related processes from trying to modify the same data at the same time.

FinDock is in direct content with customers who experienced double collections to identify and resolve the impact.

WebHub

Giving Pages & PayLinks field selection reset

Issue: Fields on Giving Pages and PayLinks may reset to their default values after a payer has made a selection and moved to another field or the next step on the payment form. This could lead to incorrect data in the payment intent message.

Solution: There was an issue in the page rendering logic that could lead to default values being used instead of the most recent, user-selected value. This has now been fixed so that the rendering always takes the set value if one is available.

Authorize.net

Support for IP shipping address filtering

FinDock now supports the IP-Shipping Address Mismatch Filter option for Authorize.net. This filter is one of the mechanisms used by Authorize.net for fraud detection. There is a new Mandate field, Customer IP Address, to store the payer’s IP address when setting up new payments. Alongside the IP address, the Country set on the related Payment Profile record (and available as a Payment API parameter) is used for the Authorize.net Shipping Country value.

In addition, we have introduced Inbound Report processing for the following Authorize.net notifications:

• payment.fraud.held
• payment.fraud.declined
• payment.fraud.approved

For payment.fraud.held:

• Installment Status = Pending
• Last Status Reason = 252 - The transaction was accepted, but is being held for merchant review.

For payment.fraud.declined:

• Installment Status = Failed
• Last Status Reason = 251 - The transaction was declined as a result of triggering a Fraud Detection Suite Filter.

The payment.fraud.approved notification is processed as a normal successful payment intent (same as payment.authcapture.created).

GoCardless

Bulk registration for ACH recurring direct debits

We have added support for using mandate schedules to register new ACH direct debit mandates with GoCardless. Similar to other direct debit methods through GoCardless, you can now add new recurring ACH direct debits directly to Salesforce with linked Mandate and Payment Profile records, the mandates using the status Pending registration.

Running a mandate schedule picks up these records and sends them to GoCardless for registration. GoCardless notifies FinDock when the mandates are authorized, at which point the records are set to Active with status Success. During the registration process, these mandates are inactive and have the status Pending registration acceptance.

To enable single or bulk mandate registration from FinDock, we have introduced the following fields to deliver required information for ACH direct debit mandate registration:

• Mandate
  • Authorization Method: the SEC code indicating how the authorization was communicated (paper, telephone, online)
• Payment Profile
  • Account Type: the payer’s bank account type (checking or savings)
  • Address Line: the payer’s full street address

New max. length for resource ID

Issue: Starting 25th August 2025, all newly created GoCardless resource IDs can have up to 32 characters. The resource ID is used in fields with shorter length limits, leading to errors when trying to save the value.

Solution: We have increased the max. length of the fields where the resource ID is used to support the longer values. This change impacts the Payment Intent Id field on Message and Inbound Report records, as well as the GoCardless Id field on Payment Profile records.

Guaranteed ordering update

Issue: In some cases, our guaranteed ordering mechanism for GoCardless notification processing does not correctly select the next pending inbound report to handle. This can lead to incorrect states for inbound reports.

Solution: The ordering mechanism used a date value for selecting the next pending inbound report to process. This value may not always reflect the intended order from GoCardless. We have updated the ordering mechanism to use the more precise Event Created Date and Time value from the GoCardless notification to determine which pending inbound report should be processed next.

Norway

Bulk KID generation through Payment Request Generator

Issue: After the introduction of customer ID generation for Giro (KID) in the July '25 release, Payment Request Generator runs would hit exceptions like: NPFF:Too many DML statements: 151. This prevented KID reference generation for larger data volumes.

Solution: The issue was caused by a bug in the provisioning logic for customer IDs in the context of the Payment Request Generator which created repeated attempts to store the last provisioned Id during the run. The logic has now been corrected to avoid unnecessary DML statements and support large volume KID generation.

KID generation for individual payments

Issue: When a new payment is created via the Payment API (Giving Pages, PayLinks, or custom frontend), FinDock did not generate a new customer ID for the (new) payer, leading to duplicate or overwritten customer IDs and payment collection errors.

Solution: The issue was caused by changes made in the May ‘25 release for bulk KID generation and how the last used customer ID was stored. This value was not updated correctly for the API-based payment intent flow. We’ve now fixed the underlying bug so new customer IDs are properly generated and stored for individual payments as well as bulk payment requests.

Swish

Notifications for recurring payments

Issue: Notifications for recurring Swish payments get stuck on the “Is it my turn” step and are not processed for reconciliation, blocking recurring collections. The issue was introduced in the March '25 release, but as recurring payments is a new feature still in the process of being rolled out by Swish, there was no real impact.

Solution: The issue was caused by a source dependency in notification handling where FinDock assumed a Recurring Payment record stored initial payment intent Id. We have changed the query to be source-independent, searching instead for the payment intent from Mandate records.

General maintenance

Heroku app and database maintenance

This release includes our regular version upgrades for software components used in FinDock apps on Heroku. These updates apply to ProcessingHub, WebHub, Notification Gateway, as well as FinDock installation and access management frameworks. In addition, we have upgraded database software used by ProcessingHub, WebHub, Notification Gateway, as well as the FinDock setup and management frameworks.