Skip to main content

Release Notes - January '22

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

note

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: January 2, 2022
  • Release to Production: January 30, 2022

In this release, we are rolling out a major overhaul of Giving Pages along with many other enhancements and bug fixes.

FinDock Giving Pages update​

This release brings a lot of new features and improvements resulting in an all new Giving Pages experience. We're introducing complete re-designs of both the Page Manager and Page Builder, adding new features and upgrading existing features, as well as fixing known issues.

New Page Manager experience​

We’ve made several updates to the Giving Pages manager to make it easier easier to get an overview of your domain and page configurations. The changes include:

  • Simplified interface
  • Renewed visual overview of configured pages
  • New proactive notifications of potential issues, e.g. with your WebHub connection or general settings errors

FinDock Giving Page templates​

To increase the options you have in creating a Giving page that fits your brand and purpose, a third template, called “Engage,” has been added alongside the existing “Activate” and “Excite” templates.

This new template contains a full-screen background image with a title and form overlay as the first view. Under the main section, there is room for two rich text content blocks and accompanying images.

New Engage template

The “Activate” and “Excite” templates have been given a significant overhaul with numerous improvements including:

  • Improved mobile rendering for a better payment form experience on smaller screens
  • Improved positioning and responsiveness of Title and Subtitle to support different viewports
  • Thank You & Error page of form are now kept in view for the “Activate” template when a payment journey is completed.
  • The “Excite” hero image spans the entire left half of the screen to better support the flexible length of forms (with the new fields and texts that can now be added).
  • A larger footer area, while keeping the copyright footer, is available for expanded content.
info

Existing pages that use the Activate and Excite templates are not impacted by the template updates. The updated templates are for new pages only.

More fonts & custom fonts​

To support more brand-specific customization of Giving Pages, we’ve added over a dozen new fonts so you now have 20+ fonts to choose from.

In addition, you can even use your own custom fonts that are hosted by you or a third party by including them through CSS tags. For more information on how to include fonts through CSS, please visit our Giving Pages documentation.

note

Custom fonts cannot be previewed in the Page Builder due to Salesforce restrictions.

More image space for (industry) logos​

All Giving Page templates now have space for three stacked images in the footer. The footer space is typically used for nonprofit industry logos like ANBI, Fundraising Regulator or payment-related logos for methods (e.g. Bacs Direct Debit) and compliancy (e.g. PCI).

Add any field to your donation form​

You can now add custom or standard Salesforce fields to your donation form. You can add input fields, hidden field values (metadata) and text paragraphs.

FinDock automatically determines the field type based on the Salesforce field mapping. Fields values are automatically added to the selected object, which can be Contact, Account, Installment, Recurring (payment, donation or other depending on Default Source Connector) or Inbound Report.

Text paragraphs can be used to add additional in-line instructions on your donation form and can be edited as rich text fields.

For more information about adding fields to your form, please visit our Giving Pages documentation.

Enhanced address input field​

Because of the specific nature of Address handling in Salesforce and the need to have specific functionality around addresses on the front-end, addresses have been made a specific type of form field. This field can be added separately from other input fields.

This functionality works on the standard Salesforce address compound fields on Contact and Account.

For more information, please visit the Payment Form configuration article.

New minimum "other" open amount option​

You can now set a minimum amount for the open “Other” amount field on your Giving Page donation form. By default, the minimum amount is set to 0.00. You can use this setting, for instance, to prevent donations that are lower than your payment processing fee.

New design for birthday and other date fields​

To make it easy to enter date fields on the Payment Form, a specific user interface interaction was implemented for the Birthday field on Contact. This field already was shown as a date picker with a separate input for day / month / year.

Now with the introduction of the ability to add other dates, a second design is implemented for other date fields. Date fields other than the Birthday field will be shown as a calendar selection pop-out to make it easy to select a certain date.

You can now add a URL to an image. When a user clicks on the image, they are redirected to the URL in the same browser tab. This can be used, for instance, to send users to your main website landing page or the first step of the Giving Page payment form.

Improved support for wide logos​

When using a wide logo (e.g. 300x100) instead of a typical square logo (e.g. 60x60) for the top left image on a Giving Page, the logo was automatically resized to fit a maximum width, resulting distorted and unreadable logos. We have improved the logo rendering to handle both wide and square logos.

With the changes to the Page Builder for Giving Pages, the user experience for the PayLinks Builder has also been updated.

Giving Pages fixes​

Page Builder component error​

Issue: On occasion, the Pages Builder would throw an error related to the Payment Method Configuration component. The Pages Builder works as normal, however, after closing the error message window.

Solution: We identified and fixed the source of this somewhat random error message so it should not appear anymore when accessing the Pages Builder.

Fix for Google Tag Manager​

Issue: The <head> tag in the source HTML code for FinDock Giving Pages was missing a closing double-quotes character for the profile attribute. This prevented the page from triggering Google Tag Manager.

Solution: We fixed the bug causing the error in the rendered HTML code. The profile attribute is now correctly closed with double-quotes: <head profile="http://www.w3.org/2005/10/profile">.

Page metadata rendering​

Issue: Metadata values other than the favicon added to a page configuration did not appear in the source code of the rendered page.

Solution: We identified the bug causing the issue and resolved it so that all metadata for a page works as expected.

Page rendering with special characters in titles​

Issue : FinDock was unable to render the page when a title element text included a percent character (%).

Solution : We fixed the underlying cause of this issue. Pages now render when title texts include a percent or other special characters.

Removing custom success / failure URL error​

Issue: When you remove a custom success URL and set the thank you / error page setting back to default, FinDock would persistently give an error that “You passed an empty string for ‘success_url’.”

Solution : Custom URLs are now properly removed and will not lead to errors.

Core​

Auto-create schedules start and end date handling​

Issue: When creating a recurring payment schedule, you define the start and end dates for generating the individual payment schedules. When auto-create is used, these dates weren’t taken in account, so payment schedules would be generated outside the set date range.

Solution: We identified the underlying bugs causing these issues and fixed them. Start and end dates are now respected as expected when using auto-create to generate payment schedules.

Payment Request Generator unique reference generation​

Issue: OGM is a payment reference used in Belgium which is relatively short compared to other payment references. Our payment reference generator algorithms are designed to never generate the same payment reference twice. However, when performing a large Payment Request Generator run for OGM, the resulting references could have duplicates values. The root cause of this was the short length of the OGM payment reference.

Solution: It is explicitly checked that within the scope of a Payment Reference Generator Run (Batch apex), the same payment reference is never generated twice.

ProcessingHub​

We have added a new capability to ProcessingHub to improve accessibility of generated files. Before, generated files where only uploaded to Chatter. With this release, a new setting, Links Files To, is added to the ProcessingHub general settings. You can use this setting to instruct FinDock to add links to the generated file using the following options:

  1. Chatter Group
  2. Chatter Group and PaymentHub File
  3. Chatter Group, PaymentHub File and Payment/Mandate Schedule

The first option (Chatter only) is the default value for existing FinDock installations. New installations will have the last option (Chatter and and related objects) as the default.

The link will appear in the Files component of the given record. Existing orgs that change the setting to options 2 or 3 should add the Files related list to PaymentHub File, Payment Schedule and Mandate Schedule page layouts to make the Files component visible.

note

Please take into consideration your security protocols and permissions. Adding file links to objects beyond the designated Chatter Group may change who can access the generated files.

CAMT large file parsing improvement​

Issue: Some customers have to process very large CAMT files, in excess of 17,000 entries. These large files were causing memory issues for ProcessingHub.

Solution: We identified the underlying cause of the memory issues and fixed it so that ProcessingHub can now parse large CAMT files without running to performance problems.

CAMT file parsing update​

Issue: If a transaction record has an End2EndId value but no payment reference, FinDock would try match the record against any PaymentHub File record with an empty payment reference. This would cause transactions that should be matched to installments based on the End2EndId to instead get a confusing Manual status.

Solution: FinDock now skips matching on batch level when there is no payment reference extracted from a file. This allows matching installments without a payment reference by using the End2EndId instead.

Parsing updates for Barclays MT940 files​

Issue: MT940 files from Barclays may use a forward slash “/” in subfield 7 of field 61 which ProcessingHub did not expect, leading to incorrect parsing of the field 61 value.

Solution: Parsing of subfield 7 now allows for use of the forward slash character. This change on impacts FinDock customers who have Barclays accounts.

Issue: For Barclays customers, processing transfer transactions (TRF) without field 8 (Reference of the Account Servicing Institution) as defined by SWIFT MT940 guidelines, ProcessingHub set the process to “Failed” with the error message: “Undefined Index: RefAccServicingInstitution.“ The file processing failed because ProcessingHub expected field 8 to be present whenever “Identification Code“ was equal to TRF. This blocked customers from processing MT940 files with transfer transactions that are considered acceptable even without Account Servicing Institution reference.

Solution: We have relaxed the requirements for MT940 processing and made field 8 optional instead of mandatory for TRF entries. MT940 files from Barclays without it will no longer fail.

Bacs for FinDock​

Improved Bacs target configuration​

To make Bacs configuration easier and key information more accessible, we added target details to the Bacs general settings. Instead of having to go to the ProcessingHub settings to configure a target, now you can click Create target in the Bacs extension settings (under FinDock Setup).

The button takes you to a new view of your targets where you can add targets and configure them as normal. Once you have defined a target, it appears under the Target section of the Bacs extension settings.

A similar enhancement was added for Gift Aid in the November '21 release.

Guided Matching for Bacs reconciliation​

FinDock automatically processes incoming Bacs Direct Debit reports for reconciliation. While this hard-coded handling works well, it was difficult to follow and hard to extend the report handling for customer-specific processing needs.

With this release, we are moving Bacs DD report processing to Guided Matching. All inbound reports for Bacs DD go through Guided Matching using the same processing rules as before, i.e. FinDock takes the same actions. However, now that these rules are part of Guided Matching (as a managed ruleset), customers can easily add additional custom rules to extend the matching logic.

All new FinDock installations will use Guided Matching for Bacs inbound reports by default. Customers with existing FinDock installations can choose to keep their current setup or switch to the new Guided Matching solution. For those switching to the new setup, the inbound report status changes are:

  • Successful inbound report status: Processed → Matched
  • Failed inbound report status: Error → Failed
  • Unmatched inbound report status: Manual → Guided review
  • Unknown inbound report type: Manual → Manual

In addition to being able to add your own custom rules for Bacs reconciliation, the new Guided Matching solution makes the existing report handling more transparent. You can now see the exact processing steps per report, as pictured below.

Example Guided Matching for Bacs reports

Processing Date with auto-collection​

Issue: When using the auto-create option for the Bacs Direct Debit payment method with FinDock or SmartDebit as processor, the recurring payment schedule did not save a processing date to the generated payment schedules as expected.

Solution: We identified and fixed the bug causing this issue so that the processing date value is now correctly saved to generated payment schedules when using auto-create. The processing date on the generated payment schedules is calculated as 1 business day before the calculated collection day.

SmartDebit API integration​

Issue : Retrieving Bacs reports from SmartDebit fails due to new, enhanced requirements for using the SmartDebit API. This affected the FinDock integration to the SmartDebit Sandbox environment where the new requirements were first introduced.

Solution: We’ve updated how FinDock uses POST and GET operations to comply with the new SmartDebit API requirements. Bacs reports are now automatically fetched from SmartDebit (production and sandbox) as expected.

SmartDebit ARRUD report handling update​

Issue: In our November '21 release, we made SmartDebit ARRUD matching stricter. We did this to resolve certain rare cases in which the final payment reference is not unique.

  • Before Nov. '21: Related installment is installment for which the message reference equals the installment final payment reference.
  • After Nov. '21: Related installment is installment for which the message reference equals the installment final payment reference and the message original processing date equals the payment schedule collection date.

We had various incidents in which this new approach turned out too be strict and lead to no matches where matches were otherwise expected.

Solution: We use the same matching logic as introduced in our previous release, but implement it in to separate steps as follows:

  1. Try to match just on final payment reference. (Same as the before-state described above.)
  2. If that leads to multiple installments, select the installment for which the message original processing date equals the payment schedule collection date. (Same as the after-state above).

SmartDebit authorization error handling​

Issue: If the SmartDebit API authorization fails for a process, that process is set to Failed and the process queue on ProcessingHub is blocked.

Solution: The issue is typically caused by incorrect authorization credentials in the SmartDebit target configuration. With this release, FinDock now sets the affected process to Rejected and adds a descriptive error message about checking credentials in the Last Status Reason field for the rejected process. With this change, the process queue is no longer blocked by the authorization error.

GoCardless​

Description field handling correction​

Issue: If the Description field was not included in the Payment API call to GoCardless, FinDock defaulted to sending the paymentIntent Id to the GoCardless Hosted Payment Page which did not provide any useful information to the payer.

Solution: FinDock will now show the payment amount, and, if available, the payment description.

  • If no description is passed: amount only
  • If description is passed: amount | description

GoCardless description placement

SEPA Credit Transfer goes to beta​

With this release, we are moving FinDock SEPA Credit Transfer (SCT) to beta testing. The SCT features are open to all customers for general testing with limited support.

Support for automated payment schedules​

With this release, we have added support for automatic processing of SCT payment schedules. With the use of recurring payment schedules and a few configuration steps, you can now set up FinDock to initiate SCT remittance payments over a limited or unlimited time frame.

Support for non-EEA remittance​

We’ve expanded our SEPA Credit Transfer (SCT) feature to include support for remittance to accounts outside the EU eurozone. This includes non-EU countries such as Norway and EU countries with a currency other than the euro, such as Poland and Hungary. With this update, FinDock SCT can be used throughout the SEPA zone. For beneficiaries with an account outside the European Economic Area (EEA), both BIC and address must be provided to complete the remittance.

Reversed installment handling correction​

Issue: Reversed payable installments were not handled correctly by Guided Matching. The status of a reversed installment was set to Outstanding instead of Reversed.

Solution: We fixed the Guided Matching rules to correctly set the status of reversed payable installments to Reversed instead of Outstanding.

SEPA Direct Debit​

Payment schedule run date and collection date handling update​

Issue: When creating a recurring payment schedule, the setting Run # of Business Days before Coll. Date required a value of 1 or higher. This prevented generated payment schedules from ever running on the same day as the collection date, which is desired in certain cases. This was also the case for individual payment schedules. The Collection Date had to be a date in the future and could not be set to today.

Solution: For SEPA payments, the setting Run # of Business Days before Coll. Date on recurring payment schedules now accepts 0 (zero) as a valid value. Using this value means payment schedules can have a run date that is the same day as the collection date. On individual payment schedules, the Collection Date setting can be set to today.

Worldpay​

Notification response correction​

Issue: Worldpay expects status 200 and an “[OK]” value in notification confirmation response messages, but FinDock did not include a message body with “OK.” This meant the responses from FinDock were not acknowledged, leading to multiple notifications from Worldpay.

Solution: Response messages from FinDock now include “[OK]” in the message body as expected, so only one notification is received from Worldpay.