Release Notes - September '22

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

Important Dates:

• Release to Sandboxes: August 28, 2022
• Release to Production: September 25, 2022

Giving Pages Custom Domains to BETA

Announced as a pilot feature in our last release, we are ready to move the custom domains support to beta testing, so with this release, all customers can start testing a custom domain with Giving pages.

As part of our beta release for FinDock Giving Pages custom domain support, we have fully automated SSL certification management. FinDock automatically monitors and renews certifications for custom domains as needed.

We have also improved our support of custom domains for FinDock Giving Pages with the ability to delete a custom domain. Deleting the custom domain removes the domain from FinDock and cancels the domain certification. Your Pages will still be available on the Givingpage.org domain.

If you encounter any issues or have feedback, please contact us at support@findock.com

Custom domains will be available to all customers free of additional charge.

Additional Giving Pages enhancements

Better field labels for Gift Aid

For the Gift Aid option on FinDock Giving Pages, we’ve updated the labels for certain fields to make them more presentable. Where before the exact field name, e.g. Lastname, was shown, now page visitors see "Last Name" in the conventional form. We’ve implemented this improvement for Firstname and Postalcode, as well. The label change will be automatically applied to existing pages.

Improved visual accessibility

With this release, we are changing the default colors used on Giving Pages payment forms to increase contrast for better accessibility. The new default text font color is a deep, dark grey (HEX #202124). In addition, we have changed default transparent backgrounds (e.g. checkboxes and radio buttons) to white to ensure strong contrast.

These changes are rolled out automatically to existing Giving Pages pages. No actions are needed. Where custom font colors are supported, the custom color settings remain unchanged and the new color is only used as default on new pages.

Pre-filled fields for one-time and recurring payments

Issue: When pre-filled values are used for both custom one-time and recurring fields, only the pre-fills for one of the frequencies (the default frequency) are used. The other pre-fills appear blank.

Solution: We identified the corrected the cause of the issue (a front-end problem) so that pre-fills for both frequencies are displayed as expected.

Page images on sandbox orgs

Issue: With Salesforce Enhanced Domains, URLs are updated to include .sandbox. With this change, FinDock Giving Pages could not find images for pages created prior to the Enhanced Domain rollout.

Solution: We have added additional checks for the Enhanced Domains context to see if the images reside at the updated URL and, if so, render with that new URL.

Payment Schedule performance improvements to BETA

Over the last couple of releases, we have been steadily working on improving payment schedule performance for large data volume (LDV) orgs. We’d like to thank all customers who have participated in piloting these enhancements! The testing has gone well, and the results are very good indeed. Hour-long processes now take minutes.

We are ready now to open up these performance enhancements to all customers. However, since the improvements impact LDV orgs in particular, we have made these enhancements optional for existing orgs. All new sandbox installations will get the enhancements automatically. If you would like to use the BETA enhancements in your existing org (sandbox or production), you can enable it from the FinDock general settings, pictured below.

If the behaviour is not to your liking, you can disable the performance improvements with the same setting. If you encounter any issues, please contact us at support@findock.com.

Core

New summary fields on Payment Schedule

To help get a quick overview of the scope of a generated payment scheduled, we’ve added two new summary fields to the Payment Schedule object:

• Total Number of Installments: number of installment records attached to the schedule
• Total Value of Installments: sum of the amounts from the attached installments

The fields are automatically updated as part of the FinDock Heartbeat job that runs nightly. Alternatively, you can click the Recalculate Payment Schedule Counters button on the Payment Schedule to force an update.

Run date calculation for daily recurring payment schedule

Issue: The calculation of the Collection Date and Run Date for recurring schedules with the Daily recordtype did not take in account the org Business Hours record that is linked to the recurring payment schedule. The Collection Date was calculated without regards to business hours, and the Run Date was determined based on the calculated Collection Date. This could lead to Collection Dates on bank holidays and run dates in the past.

Solution: The issue was caused by missing checks on Business Hours for the Daily recordtype of Recurring Payment Schedule. We’ve added the checks so that the Collection Date and Run Date calculations take into account Business Hours as expected.

Payment schedules with related Mandate History records

Issue: The Mandate History object is used to track mandate changes in the SEPA payment scheme. Payment schedule processing could not complete if a C72 - a format exclusively used in Spain to update bank account details - was uploaded prior of running the payment schedule due to a bug introduced in the July '22 FinDock release.

Solution: We identified and fixed the underling bug so that the close stage finishes as expected in the SEPA mandate history context. This issue was also corrected in the July '22 release with a hotfix.

ProcessingHub and WebHub

Database upgrades for ProcessingHub and WebHub

For better security, performance and extended support, we have upgraded database components that are part of our Heroku implementation that runs ProcessingHub and WebHub. The impacted components perform tasks related to file processing and notification handling.

The upgrades were complete and fully tested in preparation for the September '22 release to sandbox. No additional customer testing in needed beyond normal regression testing of new releases.

Improvement in retry of deleted records

Issue: Due to a bug in the ProcessingHub retry handling, the retry process included retrying deletion of staging records. This would result in the error message: The 'delete' batch must contain only ids, this error can't be resolved.

Solution: We corrected the handling so that ProcessingHub only includes Ids when retrying the delete operation.

New BIC support for MT 940 parsing

With this release, we have added support for the following BICs to MT 940 processing on ProcessingHub.

• Barclays BARCGB22
• Lloyds LOYDGB21682
• Lloyds LOYDGB21XXX

Expanded error logging for Stripe and Mollie

Some Payment Service Providers, such as Stripe and Mollie, use the 500 error code which can be encountered on the PSP redirect from a paymentIntent call. FinDock now includes this internal server error type in Log records to assist debugging such errors.

File processing between production org and sandbox copy

Issue: In rare instances, a full copy sandbox of a production org (including ProcessingHub connection details) could lead to unwanted file processing. A file uploaded to the sandbox copy would under certain circumstances also be processed for the production org, leading to a processing error for the production org.

Solution: We have added a new Salesforce org Id check to ProcessingHub requests to prevent files processed for one org being re-processed for a different org. If the org Id is not known, the request is rejected by Processinghub.

Guided Matching

Permission for Guided Review Progress component

Issue: In some cases, the Guided Review Progress component would get stuck in a continuous loading cycle due to missing permissions on certain FinDock permission sets.

Solution: We’ve identified the missing permissions that could cause this issue and added them to the following permission sets: PaymentHub All FLS, PaymentHub Operations, and PaymentHub Integration Base.

PayLinks

Modified payment method parameter handling for Saferpay

Issue: When a default payment method that uses certain parameters, such as Description with PayPal is changed by the payer to a payment method that does not support any parameters such as TWINT, the paylink would lead to an error. This was caused by FinDock passing all the parameters of the default payment method to the new payment method. In practice this could only happen for payments with Saferpay.

Solution: We have corrected the parameter handling behavior in PayLinks so that payer-selected payment methods work as expected. This issue was also corrected in the July '22 release with a hotfix.

Adyen

iDEAL payments with Revolut as issuer

Issue: When Revolut is selected as the issuer for an iDEAL payment with Adyen, Adyen raised an error and the payment intent failed.

Solution: The error was caused by a missing mapping value in FinDock that is now fixed. This issue was also corrected in the July '22 release with a hotfix.

Description parameter support for all payment methods

We have added an optional Description to the payment method parameters for all supported Adyen payment methods.

The value is used for the Description field on payment forms (Giving Pages and PayLinks), as well as bank statements (´shopperStatement´ in Adyen and Bank Statement Description on installments in Salesforce). The description also appears on Adyen Hosted Payment Pages.

The Description parameter is also available through the FinDock Payment API for custom integrations.

Adyen, Buckaroo and Mollie iDeal issuer update

As of October 1, 2022, Handelsbanken is no longer an iDEAL issuer. We have therefore removed Handelsbanken as a supported issuer for Adyen, Buckaroo and Mollie.

For existing FinDock Giving Pages and PayLinks pages, Handelsbanken is automatically removed. If you have a custom integration with the FinDock Payment API, you should also remove Handelsbanken from your list of issuers.

PayPal

Improvement in extension configuration

Issue: When configuring the PayPal extension, FinDock automatically generates a Notification URL that is used for PayPal webhooks. However, the unique URL was only determined after the extension settings are saved at least once. If the value in the Notification URL field was copy-pasted to the PayPal webhook URL setting prior to saving, the PayPal integration would not work because the correct target could not be determined as that information was missing from the URL.

Solution: The extension settings are now dynamically refreshed so that the Notification URL value is updated even before you save your changes.

Stripe

Revised handling for Next action scenarios

Issue: If 3DS has not been completed by the payer for a recurring credit card payment, the next installment generated by a payment schedule fails. The installment status in FinDock incorrectly remains New even though the payment cannot be collected. This occurs because Stripe notifies FinDock that the Payment Intent was successful, but Stripe requires a next_action to complete a 3DS challenge.

Solution: Since performing a next action that requires payer input is not possible (because the payer is not part of the payment schedule flow), FinDock now sets the installment to Failed. In the Last Status Reason field, a new error message is provided that includes the Payment Intent Id. The Id can be used to search for the relevant payment in the Stripe Dashboard to determine next action caused the payment to fail. With this information follow-up actions can be determined.

Worldpay

Update for Description parameter handling

Issue: Though not required according to the FinDock Payment API /PaymentMethod response, if a recurring payment message with Worldpay as processor does not include a Description value, the API call returns a 200 error.

Solution: To avoid impacting existing integrations, we have removed runtime validation for the Description parameter when the call is for a recurring payment. If no Description value is provided, FinDock falls back to the payment intent Id and uses that for the Description value. This effectively makes the parameter optional, though recommended, in your API call.