Release Notes - May '25

Important Dates:

• Release to sandboxes: April 27, 2025

• Release webinar: May 2, 2025

• Release to production: May 25, 2025

Classic permission sets end-of-life

With the May '25 release, we are officially announcing our classic permission sets will reach end-of-life with the November '25 release to production. In the meantime, we will continue to maintain the classic permission sets as needed until the Nov. '25 release.

First launched in September '23 and generally available since September '24 release, FinDock permission set groups will become our exclusive permissions framework moving forward. The permission set groups provide a higher degree of granularity and control, leveraging the latest in Salesforce security best practices and permissions management.

We recommend starting to use FinDock permission set groups as soon as possible alongside the classic permission sets. You can assign the groups to users without needing to make any changes to classic permission set assignments. This ensures current operations remain as is while getting your org ready for future development.

In the May '25 version of the Knowledge Base, we will include recommended actions in the classic permission sets article.

Authorize.net (Pilot)

Our Authorize.net integration piloting and development is progressing as planned with major updates and improvements in this release. The Authorize.net for FinDock payment extension now also supports one-time and recurring payments use the ACH Direct Debit payment method. ACH transactions can be processed as standard ACH payments or as payments through the Authorize.net eCheck service.

In addition to full refunds, the FinDock integration with Authorize.net now also supports partial refunds. Refunds are initiated through Authorize.net and trigger notifications to FinDock. The refund notifications are captured as inbound reports and automatically reconciled using Guided Matching. Installments that are partially refunded get the status Partially paid.

Further, we have extended our Authorize.net integration to support MOTO (mail order, telephone order) payments. Using the FinDock virtual terminal component, agents can:

• Collect new one-time payments with new card details or bank details (ACH)
• Set up recurring card or ACH payments
• Collect and set up new payments reusing an existing card or bank details

As a final touch, we improved the styling of the hosted payments page (HPP) from Authorize.net. The default provides basic information in a simple visual presentation, bu we’ve expanded the scope and updated the styling of the HPP to provide payers more information in a fuller context.

Default HPP

Updated HPP with FinDock styling

Redirect URL handling enhancement

Issue: The Authorize.net online payment flow can include parameters which result in very long URLs. These long URLs could break the redirect to the Authorize.net hosted payment page from FinDock.

Solution: We have implemented a new URL handling framework for Authorize.net which allows FinDock to generate shorter URLs for the redirect to the hosted payment page. This new solution does not require any configuration changes or other actions from customers.

Enhanced FinDock Setup (Beta)

We are happy to announce that the enhanced FinDock Setup now covers the entire functional scope the classic Setup, naturally with much more on top of that. The enhanced setup supports all PSP integrations, with the final two, Checkout.com and Worldpay Business Gateway 350 added in this release.

The following section outline the many other fixes and improvements we've made for May '25.

Improved source package management

Issue: Source packages installed and configured through the enhanced FinDock Setup are not activated and deployed as expected.

Solution: We have extended and improved the handling for source packages to ensure they are properly activated and configuration changes deployed. In addition, we improved error handling and also refactored the activate, deactivate and uninstall source actions from FinDock Setup, so they are similar now to what you can do with payment processors.

Visual and UX improvements

With this release, we’ve made several improvements to visual presentations and interactions in the enhanced FinDock Setup. The changes contribute to improved readability and reduced effort, like less scrolling.

Manual configuration deployment

FinDock automatically deploys new configurations when you save settings changes. In certain situations, like a network error or browser freeze, your changes may not fully deploy. To recover from these scenarios, you can now manually trigger deployment and bring your org back into sync with your latest settings.

Enhanced setup for MT940

Issue: The enhanced setup for FinDock’s native MT940 processor showed general settings that are not applicable to MT940 file processing.

Solution: We fixed the bug causing the user interface to show irrelevant settings for MT940. We also updated some texts to unify the MT940 presentation with other processor configurations.

Improved permission checks

Issue: If you try to deploy configuration changes through the enhanced setup, but your user account doesn’t have all the required admin permissions, errors occur during deployment.

Solution: We have introduced new pre-deployment permission checks to prevent errors during deployment. If the user account does not have required permissions, FinDock blocks deployment and instead displays an admonition about which required permissions are missing.

Vipps installation from enhanced setup tab

Issue: After our September '24 release, Vipps was not visible in the list of available processor packages in the FinDock Setup.

Solution: We fixed the bug causing the issue so Vipps is visible and can be installed from the enhanced setup UI as expected.

Processor page refresh during activation

Issue: If the setting page for a payment processor is refreshed before FinDock has completed activating the processor, the setup freezes.

Solution: Activation runs automatically when a processor settings page is first opened after installation. During activation, FinDock inserts certain records that get duplicated when the page is refreshed. To help limit the chance of the page being refreshed, we removed the ability to click open the processor settings page while the package is installing. We have also added additional logic to check for existing records before inserting.

Deployment of configuration values with special characters

Issue: If a configuration value included the ampersand symbol (&), deployment through FinDock Setup would result in an error.

Solution: The new deployment framework used by FinDock Setup treated ampersand as a regular character, causing the configuration to be misread. This has now been resolved by escaping the special character as expected.

Guided Matching setups

Issue: In the enhanced setup, Guided Matching setups that are part of payment extensions were inserted when the processor is activated. However, in some cases, the insertion may not complete during activation.

Solution: To ensure the setups are inserted, we have now replicated the insert logic of the classic setup. Guided Matching rule sets and associated settings are inserted (if needed) when a FinDock Setup page is opened to ensure all Transaction and Inbound Report record types have the managed and suggested rules from FinDock.

Sources overview

Issue: In orgs with the Converse-PayLink source connector, the Sources settings overview page would not load, showing only the loading spinner.

Solution: The issue arises when the Converse package license has expired. This enhanced setup page did not catch this error correctly, resulting in the loading problem. This has now been resolved so the setup page properly loads and shows the license error.

Tikkie notifications

Issue: When the Tikkie payment extension is configured through the enhanced FinDock Setup, notifications about payments from Tikkie are not received.

Solution: The Tikkie integration requires FinDock to subscribe to notifications, but this backend step was missing in the enhanced setup implementation. This has now be corrected so notifications come through as expected.

Configuration deployments for Converse PayLink

Issue: Converse PayLink customers who use the enhanced FinDock Setup could not deploy configuration changes, hitting a deployment error instead.

Solution: The deployment framework for the enhanced FinDock Setup was missing a query of a managed field in the Converse-as-source context. This caused the deployment process to try to update that managed field even though it is not editable. This missing query is now resolved so that configuration deployments are executed as expected.

Bank Feed (Beta)

We continue to see very high interest in FinDock Bank Feed as we refine key capabilities on the way to general availability. In this release we introduce to improvements to better handle certain fallback and edge cases.

Fallback validity periods for authorization requests

Issue: When a Bank Feed authorization request is made with a bank, FinDock used a default 180-day validity period for account access in the request. If the bank supported anything less that 180 days, the authorization request would fail and result in a frozen Bank Feed setup page.

Solution: We have introduced two new mechanisms to handle different authorization validity periods. If the org is a sandbox, FinDock automatically requests access for 30 days only. In production orgs, the first authorization request uses 180 days (technically 179 to account for edge cases). If that fails, FinDock falls back to a 90-day access request.

Transaction Id handling update

Issue: Bank Feed relies on the Transaction Id for deduplication and matching incoming records. However, in some cases this value is not available, leading to stuck processes.

Solution: We have changed Bank Feed processing logic to use the internal transaction Id value from the Account Service Information Provider (AISP) that is always included in incoming transactions.

MOTO

Support for ACH Direct Debit payments

With this release, you can accept one-time and set up recurring ACH Direct Debit payments through FinDock MOTO (virtual terminal) using Authorize.net as the payment processor.

PayLinks

Enhanced accessibility

We conducted a 3rd party audit of FinDock PayLinks to assess our compliance with the Web Content Accessibility Guidelines (WCAG) 2.1 level AA requirements. Based on the findings, we have made several adjustments to improve PayLinks accessibility. The enhancements are wide-ranging, from default colors and better visual indicators, to improving error prevention. Together, the changes bring PayLinks into full compliance with the WCAG 2.1 level AA requirements.

Core

Guided Matching update for refunds of multiple installments

Before this release, multiple installment handling with Guided Matching was limited to credit transactions. A single incoming payment could be matched to one or more installments through matching logic and Guided Review.

With this release, we have expanded that capability to also handle debit transactions, outgoing transactions that represent e.g. payment refunds. The Process Installment rule now uses the multiple installment settings to handle both credit and debt transactions. The debit transaction can be matched to one or more collected installments to modify the status and the amounts across those installments according to the debit details.

When the incoming transaction is a debit, the Guided Review component shows the Amount from matched installments instead of the Amount Open as with credit transactions.

Batch matching for inbound reports

In our March '25 release, we introduced batch transaction matching for Guided Matching, which replicated in FinDock Core the batch matching carried out on ProcessingHub for certain file-based reconciliation. In this release, batch matching through Guided Matching is now expanded to support Inbound Report records in addition to Transaction records.

To support batch matching, the Inbound Report object gets two new fields: File Reference and Group Job Id. These are used to compile and process the batch scope for inbound reports and match installments (based on the installment PaymentHub File field value).

Permissions for batch matching

Issue: Required permissions to execute batch matching through Guided Matching were missing from FinDock classic permission sets, causing matching to fail.

Solution: We have added the necessary permissions (for File Reference and Job Group Identifier fields) to classic permission sets. These changes impact PaymentHub All FLS, PaymentHub Integration Base, and PaymentHub Operations.

Payment API and PayLinks: Recurring payments with Person Accounts

Issue: When using the Payment API or PayLinks to set up a new recurring payment with FinDock Standalone (Recurring Payment object), the payment intent would fail if only a Person Account or Account is provided.

Solution: We have updated how Account and Contact objects are handled in payment intents for recurring payments in FinDock Standalone. Both an account and a contact can be provided. Or, if only a Person Account is provided, FinDock automatically adds the corresponding contact Id to the payment intent.

ProcessingHub

Invalid cipher error

Issue: In certain scenarios, when a file is uploaded to ProcessingHub via Chatter, the upload results in a invalid cipher error preventing further processing.

Solution: We have updated certain steps in our data handling process to resolve the issue.

Fundraising

Giving Pages and recurring gift collection dates

Issue: With the default Giving Pages behavior, new monthly or yearly recurring gifts created on certain days of the month that include an initial payment lead to the next collection month or year being missed. For example, a recurring gift created on the 22nd of October would result in the related gift commitment schedule setting the first gift transaction collection to the 1st of December.

Solution: If the Start Date and Transaction Day on Gift Commitment Schedule are not explicitly set for the Giving Page (or the custom payment intent message to the Payment API), then FinDock automatically set the Start Date to be the initial payment date plus one full month or year. Transaction Day was in turn set to the first of the recurring period (FinDock Core default collection day). When the gift commitment schedule calculates the gift transaction due date, is uses the first Transaction Day after the Start Date. For example:

• Recurring gift is created with an initial payment = 22 October
• Default Start Date = 22 November
• Default Transaction Date = 1st of the month
• First Transaction Due Date = 1 December

This means the expected collection on the 1st of November is skipped. To avoid this scenario, we have changed the default Start Date behavior for Fundraising. Instead of adding a full recurring period to calculate the State Date when an initial payment is included, FinDock now by uses Today (the date the recurring gift is set up) as the Start Date. If the Start Date is explicitly set on the Giving Page, that is still used and sets up the recurring gift correctly as before.

Mapping update for Bank Statement Description

Issue: The mapping between Bank Statement Description on Gift Transaction and Installment used a one-way sync from Gift Transaction to Installment. This resulted in the Bank Statement Description on Installment getting overwritten by empty or outdated values in certain scenarios.

Solution: We have updated the managed mapping of this field in the Fundraising source connect to make the syncing bi-direction. This ensures the new values on the Installment record are correctly updated to the related Gift Transaction record.

Gift Aid

Permissions update

Issue: With the Salesforce API version update in our March '25 release,  default access to Custom Metadata Types changed. This could result in the Gift Aid payment schedules failing with the error: gaid.Application.GiftAidException: Can't determine proper tax rate; cause: null; line number: 34; stack trace: (gaid). The error occurs if the user running the schedule does not have read access to a specific meta data type from FinDock.

Solution: We have updated Gift Aid permission sets, FinDock Gift Aid Base and (classic) GiftFid FLS, to include the necessary access to the "GiftAid Tax Rates" Custom Metadata Type. All customers, including those who have manually assigned read access to this metadata type for users running Gift Aid payment schedules can proceed without further actions. If you have failed Gift Aid schedules, you can set failed schedules back to Scheduled and run them as normal.

Invalid data handling in payment schedules

Issue: If a Gift Aid declaration has a postal code that is not valid for the UK, but also does not have the Overseas checkbox marked true, then a Gift Aid payment schedule with that declaration in scope would fail with a stuck process. The process could not continue without intervention from FinDock Support.

Solution: By using the Data Quality component, this sort of data problem can be caught and corrected before running the payment schedule. However, to avoid stuck processes, we have also updated the error handling to reject the payment schedule process when a validation error is encountered.

Nonprofit Success Pack

NPSP first opportunity for recurring donations not created

Issue: In orgs where there is a Flow on Contact, the first opportunity (and related payment profile and mandate) for a new recurring donation is not created when the payment intent is processed by Guided Matching. The opportunity is created later that night by NPSP batch jobs.

Solution: For reasons that are not yet understood, code related to feature management exposes the issue, so we have for now removed this code until we can complete the root cause analysis with Salesforce. The code controlled PayLinks URL generation, so with this change, records will automatically get a (non-functioning) PayLink URL. If you have already implemented our suggested workaround, you can continue as is or remove it. This change does not impact the workaround

Adyen

iDEAL issue parameter deprecated

In April 2025, Adyen discontinued support for select a specific iDEAL issuer as part of a new payment. This was controlled in the FinDock integration with the issuer parameter. With this release, we have fully deprecated the issuer parameter.

No changes are required you are using Giving Pages or PayLinks with this parameter. If you have a custom integration with the Payment API that incorporates the the issuer parameter, we recommend removing it from your payment intent coding.

New parameter for Google Pay

Issue: A known issue at Adyen is causing the wrong card options to show for Google Pay on their hosted payment page (HPP).

Solution: As per guidance from Adyen, we have introduced a new parameter, paymentCountry, that should help ensure Google Pay works as expected. Use this parameter with Google Pay to submit the ISO 3166 two-character code of the country from where the payment intent originates. Adyen determines which payment methods should be excluded on the HPP based on location.

In addition, you can now also use the locale parameter to pre-set a language for the Adyen HPP so payers don’t need to select a language. Both paymentCountry and locale parameters are available for all payment methods supported by FinDock's integration with Adyen.

Bacs Manual and SmartDebit

Bacs reports to Manual instead of Matched

Issue: Guided Matching for Bacs reports could result in Manual status rather than Matched because no Guided Matching setup was inserted for the inbound report.

Solution: The issue was caused by a trigger change for batch report handling in the March '25 release. This change could lead to the inbound report being processed by Guided Matching before a Guided Matching setup is inserted. We have now resolved this by reordering the logic for setting a record to Manual.

Latest SmartDebit report dates flushed after ProcessingHub sync

Issue: If ProcessingHub detects a change in an org’s configuration, a sync is triggered to update the configuration details on ProcessingHub. This could result in ProcessingHub losing the latest dates for SmartDebit reports, causing FinDock to fetch old reports and running unnecessary processes.

Solution: The issue was caused by how FinDock executed the sync. This has now been fixed so that the latest report date on ProcessingHub is not overwritten by the Initial Report Date on SmartDebit targets.

Buckaroo

Guided Matching for iDEAL QR payments

Issue: After the March ’25 release to production, Guided Matching would fail on iDEAL QR payments that were generated using the Payment Request Generator. The error occurred because the Target field on inbound reports was accessed without being queried, resulting in following error: SObject row was retrieved via SOQL without querying the requested field: cpm__Inbound_Report__c.cpm__Target__c. The error does not prevent payments from being collected. However, the inbound reports matching fails, and the related installments are not set to Collected in Salesforce.

Solution: We believe the issue is related to the Salesforce API updates we rolled out with the March '25 release. The cause of the error is clear, however - the Buckaroo inbound reports for iDEAL QR payments were missing a Target value. In the the Payment Request Generator scenario, the iDEAL QR payment request does not have a related installment. When that payment request is fulfilled (collected), the inbound report starts off without a Target value (because there is no installment yet). To eliminate this scenario, we have introduced an additional step in the Buckaroo notification handling to ensure the inbound reports have a Target value before match starts.

RECOMMENDED ACTION: When the issue arose, we instructed affected customers to add a Constant rule for the Target field to insert a Target name and apply this rule in the Guided Matching setup for Inbound Report type Buckaroo, subtype C021. Our fix for the issue does not break this workaround. However, the workaround introduces a hard-coded Target value, a value that could change at some point in the FinDock configuration. The enrichment solution we introduced is dynamic, using the latest configured Target value, so we recommend removing the Constant rule workaround to avoid potential matching issues over the long-term.

Expiration date for iDEAL payment requests

Issue: For Payment Request Generator runs with iDEAL (Buckaroo), the Expiration Date setting is not required. However, the run would fail with an error if a date is not provided.

Solution: We corrected the settings check for iDEAL to properly allow empty Expiration Date values.

QR image size for iDEAL payment requests

Issue: The QR image size setting is not required when setting up a Payment Request Generator run for iDEAL QR with Buckaroo. However, the parameter is required in the callout to Buckaroo. If the setting was left empty, FinDock excluded the parameter from the callout, leading to errors.

Solution: If the QR image size is not specified, FinDock now passes the parameter with a null value to meet the Buckaroo API requirements.

Payment Request Generator empty fields for iDEAL

Issue: If you create a Payment Request Generator run for Buckaroo with iDEAL as the payment method and you leave certain setup fields empty, like minimum and maximum amount, FinDock automatically added a value to empty fields when the run setup is saved.

Solution: We identified and fixed the bug causing the issue. If required fields are left empty, FinDock now throws an error, and empty fields that are not required are left empty, as expected.

GoCardless

Ordering of GoCardless inbound report processing with Guided Matching

Issue: In certain scenarios, FinDock would try to process inbound reports from GoCardless notifications in an order that leads to a continuous loop of Apex jobs during Guided Matching.

Solution: The issue is caused the order in which FinDock receives notifications from GoCardless. Guided Matching would process notifications based on the order in which they arrived, leading to potential processing loop if the order is not as expected, in particularly when the payment intent notification arrives after further status update notifications. To handle this scenario, we have introduced specific ordering dependencies to make sure inbound reports are processed by Guided Matching in a logical sequence.

Batch processing enhancement

Issue: When FinDock process installments in a GoCardless payment schedule, the processing is handled in batches. If a single installment fails, the all-or-none logic of the batch halts processing. This could lead to an unnecessarily high number of failed installments. In some cases, installments could also remain in a status that might lead to double-collection.

Solution: We have enhanced the batch processing logic to allow different results for installments in a given batch, ensuring as many installments are successfully processed as possible.

Mollie

Batch processing enhancement

Issue: When FinDock process installments in a Mollie payment schedule, the processing is handled in batches. If a single installment fails, the all-or-none logic of the batch halts processing. This could lead to an unnecessarily high number of failed installments. In some cases, installments could also remain in a status that might lead to double-collection.

Solution: We have enhanced the batch processing logic to allow different results for installments in a given batch, ensuring as many installments are successfully processed as possible.

Norway

Enhanced setup for KID modulo setting

Issue: In the enhanced FinDock Setup, the KID modulo setting was a text field instead of a picklist with fixed options (10 or 11), which could lead to incorrect values.

Solution: We updated the modulo setting to be a picklist as it was in the classic setup. In addition, we have added descriptions to the FinDock-for-Norway package general settings, as well as fixed a bug that could cause a null pointer error when saving settings changes.

Payment Request Generator with Giro (KID) method

Issue: The Giro (KID) payment method, used in Norway, combined with a large campaign (over 25K members) would cause the Payment Request Generator run to fail with an Apex CPU time limit exceeded error.

Solution: The issue was caused by how FinDock determined KID uniqueness. During KID generation, FinDock enforced uniqueness of the Invoice Id component itself instead of just the full KID, leading to a loop that cause the time limit error. We have now resolved this by only enforcing uniqueness of the full KID in the Payment Request Generator run.

Saferpay

TWINT payments not updated

Issue: Payments using the TWINT method could result in installments remaining in Pending even if the payment is completed at Saferpay.

Solution: This issue was caused by how FinDock captured follow-up notifications from Saferpay. With the introduction of PostFinance Pay support, FinDock relied on the payer redirect event. However, for methods like TWINT, the redirect can be missed, e.g. by the payer closing a browser tab too quickly, yet the payment is still completed. To handle these methods, we have re-introduced payment processing through callback notifications. So, FinDock now updates installments based on redirects as well as callback notifications from Saferpay.

Locked row exceptions during payment handling

Issue: When running a payment schedule, FinDock may encounter locked row exceptions while updating Salesforce data. If the locked row occurs while FinDock handles the capture process with Saferpay, updating the installment to Collected fails. The money is collected at Saferpay, but the installment status in Salesforce remains unchanged, which could potentially lead to double collections.

Solution: We have implemented a new retry mechanism to better handle locked row exceptions. Now if a locked row is encountered during the installment update, FinDock retries the update action a fixed number of times. If after all retries the update still fails, an error is thrown indicating the installment could not be updated as expected.

Optional batch Apex scheduling

The Saferpay payment extension includes an Apex class that can be used to check for pending installments and make callouts to Saferpay to get the latest status. This sweeper batch is generally not needed anymore. However, it can still be used as an extra measure to ensure installments are always up to date. So, we have added instructions to our Saferpay setup article for manually scheduling the Apex class, called AssertUnprocessedTransactionsSchedule.

SEPA

CODA support for BBAN accounts

Issue: If a customer account (the SEPA target in FinDock) is reported as a BBAN, FinDock could not parse the CODA file correctly, leading to “does not conform to CODA standards” error and an empty account number on payment profiles.

Solution: We have updated the CODA file handling logic to be able to extract customer accounts in BBAN as well as IBAN formats.

Sweden

Autogiro reconciliation of additional Bankgirot file types

With this release we have added support for reconciling the “Cancellation/amendment of payments” file types from Bankgirot. The files are parsed into inbound reports with type Autogiro Cancel-Amend and one of several subtypes based on the cancellation or amendment code of the incoming file record.

Expanded Swish bank file processing

With this release, we have added support for Swish reports from Handelsbanken and Swedbank. These reports can be uploaded to Chatter using comma-separate values (CSV) format. FinDock automatically parses the files and created Inbound Report records for each payment in the report. The payment details are captured in JSON format and added to the Raw Message field on the inbound report.

We also provide Guided Matching setups for the new Inbound Report subtypes Handelsbanken report and Swedbank report. These include unmanaged rules that can be modified to meet your specific reconciliation scenarios.