Skip to main content
Version: may-24-production

Release Notes - January '24

We are happy to present the FinDock January '24 Release!


Our release communication aims to inform you early of upcoming releases. Please keep in mind that the scope of a release is subject to change prior to the release date. Release notes are updated accordingly until the release date.

Important Dates:

  • Release to Sandboxes: December 30, 2023
  • Release to Production: January 28, 2024


Native Autogiro direct debit

Another big step in our Nordic Payments development is now ready for piloting. With this release, we are rolling out a solution for collecting Autogiro direct debit payments natively through FinDock.

Our Autogiro solution is still under development but will include direct integration with Bankgirot to create agreements (mandates) for new payments, collect payments, as well as process and match incoming statements.

If you would like to participate in the pilot, please contact FinDock Support.

FinDock for Fundraising update

Thanks to everyone piloting our FinDock for Fundraising package. Lot’s of great feedback! The piloting continues with the January '24 release, but we are rolling out a lot of improvements along the way. Here are some of the main highlights:

  • New permission set (FinDock Fundraising Integration) that can be used with the free Salesforce integration user license
  • Automatic default value Unknown set for the Salesforce Payment Method field on Gift Transaction and Gift Commitment Schedule to avoid confusion with the FinDock Payment Method field
  • Contact Id (PersonContactId) for Person Account included in webhooks for 3rd party integrations, next to Account Id
  • Gift Commitment name respected if set in SalesforceFields in Payment API calls
  • Fixed bank statement description mapping to Installment
  • Several usability improvements to FinDock for Fundraising setup UI

In addition, we have made a Stripe-specific update around prefilling the Hosted Payment Page. Prefilling of email addresses on the Stripe Hosted Payment Page did not work when using person accounts instead of contacts.

FinDock now checks for the PersonEmail field when a person account is provided. If that field has a value, it is used to prefill the email address on the Stripe Hosted Payment Page.


Integration User Group beta extended

The beta testing of the FinDock Integration User Group continues with the January ‘24 release. Kicked off with the September '23 release, we’ve gotten a lot of good, constructive feedback. Thanks to all our customers and partners for that!

For this release, we have further refined the permissions and sets assigned to the Integration User Group. Specific permissions in certain sets were adjusted to meet identified gaps. In addition, we are making some set-level adjustments for this group, including renaming the Core sets for clarity to:

  • FinDock Core File-based Payments Integration (beta)
  • FinDock Core Mandate Schedule Integration (beta)
  • FinDock Core Online Payments Integration (beta)
  • FinDock Core Payment Schedule Integration (beta)

The updates in this release for integration-related permission sets impact FinDock packages for Core, PayPal and Saferpay.


If you have directly assigned integration-related permission sets to a user, we recommend removing the direct assignments and use the FinDock Integration User Group instead.


FinDock permissions and custom settings

FinDock now supports the Salesforce feature Restrict access to custom settings. This enables customers to fully implement Salesforce security recommendations around custom settings when using FinDock.

Giving Pages permission set name update

With this release we have changed the name of the Giving Pages permission set to make it more transparent. The set formerly named "Pages" is now called "FinDock Core Giving Pages." This change only impacts the permission set label.

FinDock Payment component on Gift Commitment

Issue: When the FinDock Payment component for MOTO payments is added to the layout of Gift Commitment (Salesforce Fundraising object), the component throws a no-such-column error and is not visible after saving the layout changes.

Solution: The issue was caused by an incorrect namespace for the Mandate lookup field. This has now been fixed so the component can be used on Gift Commitment layouts as expected.


Last Collection Date for partially paid installments

Issue: For a matched transaction that results in a partially paid installment, the Last Collection Date on the installment was incorrectly set to today.

Solution: ProcessingHub now uses the payment date (Date or Value Date) from the matched Transaction record for Last Collection Date on a partially paid installment as expected.

WebHub & Notification Gateway

Callout implementation update

Issue: In certain rare scenarios, callouts from a Giving Pages or PayLinks payment form used a deprecated function in the backend tech stack.

Solution: The deprecated function has now been removed from the WebHub and Notification Gateway apps on Heroku.

Gift Aid

Permission handling enhancements

With this release, permission handling in the Gift Aid package is stricter. The changes are potentially breaking for Payment API integrations if permissions have not been configured correctly.

We do not expect integration errors for customers who have assigned all required general FinDock permissions and Gift Aid permissions. However, we strongly recommend all customers test the updated package in sandbox to ensure your permissions are configured correctly.

We have reached out to customers who may be impacted to further emphasize the need for testing during the sandbox period.

Eligibility query for payment schedules

Issue: As part of the July '22 release, FinDock changed how the donation date is determined for Gift Aid eligibility, using Last Collection Date instead of Due Date on the receivable installment. This related installment query for Gift Aid payment schedules, however, was not updated, which could lead to delayed claims for certain installments.

Solution: We have updated the payment schedule query to use Last Collection Date so that it is in line with the Gift Aid eligibility formula as expected. If there is no Last Collection Date, the Due Date is used to determine eligibility.


Failed or rejected payment handling

Issue: With certain payment methods, a failed or rejected payment is not handled by FinDock. The related installment instead remains in status Pending.

Solution: We determined that the Buckaroo payment handling in FinDock was not processing all possible status codes that indicate a payment has been rejected or otherwise failed. We’ve now updated the Buckaroo package to include these status codes in the standard notification handling and Guided Matching rules.

GoCardless & Stripe

Production connection on sandbox refresh

Issue : When you make a full-copy sandbox refresh of a production org that has a configured connection to the PSP production environment, the new sandbox org uses the PSP production endpoint, leading to duplicate collection in the production environment. This occurs when payment schedules are run in the sandbox because the full-copy refresh brings in recurring payment data, automated schedule settings, as well as production target configurations for the PSP.

Solution : We have added a new check on the payment extension to disallow a sandbox org from having the Is Test setting disabled. FinDock performs this check with every callout to the PSP, resulting from schedule runs or calls to the Payment API, to make sure the org configuration is allowed. If the disallowed configuration is encountered, FinDock does not make a callout, but rather throws an error, “The connection from WebHub Test to … is not supported.” The error will appear, for example, in the Last Status Reason on schedules.


Fix for recurring credit card payment collection

Issue: In certain scenarios with some Redsys customers, collection of recurring credit card payments was not working. Recurring credit card payments set up through the FinDock Payment API could not be collected with payment schedules. The payment schedule run would result in an error.

Solution: The issue was caused by how ProcessingHub handled a specific Redsys API parameter value. This has now been fixed so payment schedules result in collected installments for all customers as expected.

Credit card notification handling update

Issue: When setting up a recurring credit card payment through Redsys, FinDock could not create Payment Profile and Mandate records when no card number was included in the notification from Redsys. This prevented collection of installments.

Solution: The issue was caused by the FinDock notification handling for Redsys which required a card number. We have now updated the handler to be able to set up unique payment profiles and mandates for new recurring payments without a card number.


The Redsys for FinDock package is not automatically updated. Please manually install the latest package version using the FinDock Installer.


Support for multi-merchant accounts

We are happy to announce that the FinDock payment extension for Saferpay now supports multi-merchant accounts.


Reporting API migration

Issue: The Vipps report API version 1 is being deprecated. This is the API version the Vipps for FinDock payment extension uses.

Solution: With this release, we have migrated the Vipps for FinDock package to version 2 of the Vipps reporting API.

Target name validation update

Issue: As part of internal testing, we found that a Vipps target can be configured with a name that includes whitespaces. Target names with whitespaces, however, lead to broken notification URLs, such as the callback URL FinDock sends to Vipps.

Solution: We have added validation to the Target field in the Vipps setup to prevent names with whitespaces. If a whitespace is used, FinDock displays an error indicating that the name can only contain alphanumeric characters.

Vipps target on mandate

Issue: When setting up a new Vipps recurring payment, FinDock did not save the target (defined in the Vipps extension configuration) to the newly created Mandate record. This prevented cancelling or updating the Mandate record from Salesforce.

Solution: We identified and fixed the bug causing the issue so that now the target is saved to Vipps mandates as expected.