Release Notes - November '23

We are happy to present the FinDock November '23 Release!

Important Dates:

• Release to sandboxes: October 29, 2023
• Release to production: November 26, 2023

NEW PILOT - FinDock for Fundraising

We are happy to announce the launch our FinDock for Fundraising solution for the new Salesforce Fundraising feature available with Nonprofit Cloud (NPC) and other cloud offerings.

This pilot will be somewhat different given the importance of the Salesforce NPC rollout. All customers can test the new package for Fundraising during the pilot.

NEW PILOT - FinDock for Sweden

As part of our Nordic Payments development, we are introducing a new FinDock for Sweden processor to the Nordic Payments package. This new processor will bring new capabilities for the Swedish market.

We begin in this release with BGMax file processing and Giro (OCR) payment reference generation. This is just the first step, with more features to come.

BGMax file processing

With this release, we have added FinDock for Sweden as a new processing option for our Nordic Payments package. This processor option includes new parsing and matching capabilities for the BGMax file type from Bankgirot. BGMax files report Bankgiro Receivables, which FinDock transforms into Transaction Set and Transaction records for reconciliation. For details, please refer to the new BGMax article in the November '23 version of our Knowledge Base.

OCR generator for Giro payments in Sweden

Giro payments, a type of bank transfer popular in Sweden, relies on a payment reference type called OCR. With the release of our new support for Sweden in the Nordic Payments package, we have add automatic OCR generation on installments.

In addition, you can also now bulk generate OCRs using the Payment Request Generator. For further details, please refer to the November '23 version of What is the Payment Request Generator? the new Giro payments article.

Nordic payments

KID generator for Giro payments in Norway

We have added a new Giro payment method to generate KID references on installments that can be used for Giro payments in Norway. The reference generation is automatic when the payment processor (FinDock-for-Norway), method (Giro) and target are set on the installment. The generated KID format uses the settings for the FinDock for Norway extension.

Core

Lightning app updates for Salesforce Winter '24

Issue: After the Salesforce Winter '24 release, the FinDock app header was visible at the top of Lightning apps, such as those for Giving Pages and PayLinks.

Solution: We’ve updated our visual style sheets to support the Winter '24 release and hide the app header as expected.

Guided Matching status after remainder is zero

Issue: The Leave Remained on Next Transaction / Inbound Report option resulted in an incorrect status and open amount for matched payable installments. With the leave remainder option, an incoming debit transaction equal to the amount of the matched payable installment would result in Partially Matched status for the Transaction record with Open Amount double the original amount.

Solution: The incorrect handling in the Process Installment rule has been fixed so that in the payable installment scenario, the incoming transaction for the full amount results in Matched status with an Open Amount of empty or 0.

Guided Matching support for Producer object

Issue: If use the Salesforce Producer object is used in Guided Matching with the Guided Review setup, the input provided in the review is not saved on a Transaction or Inbound Report record.

Solution: The issue was caused by outdated Salesforce API versions used in certain Apex classes. These classes have now been updated with newer API version declarations.

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.

Notification Gateway

Improvements for high traffic scenarios

Issue : In cases when a PSP sends a very large number of notifications to FinDock in a very short period, the Notification Gateway is unable to handle them all as normal. This can result in a small percentage of notifications (less than 1%) initially failing. The failed notifications are automatically retried and successfully handed, but this represent an overall processing delay.

Solution : We have made a number of improvements to the Notification Gateway infrastructure to better handle sudden bursts of high traffic.

ProcessingHub

New MT 940 support for Bank of Ireland and BNP Paribas Fortis

We’ve added specific support to our MT 940 file parsing for the Bank of Ireland (BOFIIE2D) and BNP Paribas Fortis (GEBABEBB).

WebHub

Finalization of access management improvements

As a final step of our ongoing access management improvements for WebHub (and Notification Gateway), we have completed some general house cleaning tasks, such as database table cleanup, to ensure we move forward from the most optimal baseline.

Gift Aid

Support for Person Accounts

As part of our ongoing development for Salesforce Fundraising, we have added support for Person Accounts to the Gift Aid package. The Gift Aid Declaration component can now be used on Account records with Person Account record type as well as on Contact records. Business Account record types are not supported.

In addition, we updated the logic for Gift Aid Package Actions through the Payment API (and Giving Pages) which now enable a Gift Aid Declaration to be associated with a Person Account (and the Contact fields on Person Account).

Post code validation

Issue: If the Postal Code field on a Gift Aid Declaration record has the incorrect format, Gift Aid payment schedules that use the declaration fail.

Solution: To help prevent incorrect postal codes from getting into the Gift Aid data, we have added automatic normalization to the FinDock Payment API. The normalization adds capitalization and spacing to the postal code to conform to HMRC requirements and is applied if:

• The overseas indicator is false, and
• The provided string results in a valid UK post code after normalization.

If neither is true, then the provided postal code is left as is. Keep in mind that you can always find the original postal code string in the RAW message field on the Inbound Report record.

Nonprofit Success Pack

Automatic mandate creation for Opportunity

Issue: With a certain configuration for FinDock and NPSP, mandates were not auto-created as expected. If the FinDock Core mandate settings Auto create Mandate for DD and Re-use existing Mandate are enabled, but Treat Single Opportunity as one-off is not, updating a newly created Opportunity record with a payment profile did not result in a new recurring mandate as it should have.

Solution: We have updated the mandate creation trigger for Opportunity to automatically generate a recurring mandate when an existing record (without a linked payment profile or installment) is updated.

Adyen, Buckaroo and Mollie

Additional iDEAL issuers

With this release, we have added support for three additional iDEAL issuers. These are available in Giving Pages and PayLinks configuration (payment form settings), as well as in the Payment API as values for the optional issuer parameter.

• N26 (API value n26)
• Nationale-Nederlanden (API value nationale-nederlanden)
• Yoursafe (API value yoursafe)

In this release, we have also updated the logo for bunq to match their current branding.

GoCardless

Guided Matching rules updated for Person Account support

Issue: Payment Intent calls require a Contact record to complete processing of the resulting Inbound Report record through Guided Matching. This prevents FinDock from processing payment intent calls made with Person Account Account records.

Solution: We’ve updated the Guided Matching rules for GoCardless to be able to extract a contact Id from Person Account Account records.

PayPal

Incomplete payment capture handling

Issue: If the capture notification from PayPal is received before the send capture message processing is completed, the capture notification handling fails. This results in an installment that is successfully collected with PayPal, but not set to Collected status in Salesforce.

Solution: We have changed which notification FinDock uses to get the payment intent Id. The notification, an order confirmation, includes the data required to process the capture notification when it arrives.

Redsys

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.

Saferpay

Redirect on payment failure

Issue: When a payment fails, the redirect to the failure page did not work for SIX Saferpay, leading to a 500 error.

Solution: The redirect to the failure page did not work due to a backend configuration error in WebHub, which has now been fixed.

Stripe

Bacs Direct Debit payment submission update

Issue: If a completed payment schedule run results in a new mandate, and another schedule is run before that new mandate is activated, the related installment fails with an Index out of bounds error.

Solution: The error was caused by missing payload in the Stripe response which FinDock expected to always be present. The charges payload is only present after mandates are activated. We have now adjusted the FinDock response handling to accept response messages with or without the charges data.

Optional initial amount handling for recurring payments

Issue: When using the optional initial amount with Stripe, under certain conditions the expected Payment Profile and Mandate records are not created due to a duplication error.

Solution: The issue is caused by near simultaneous arrival times of Stripe notifications and FinDock synchronous processing of the resulting inbound reports. Both reports can trigger record creation, leading to a duplication error on Payment Profile. To mitigate this issue, rather than failing on the first duplicate error, FinDock now tries to process the failed report again. This gives a chance for the first report processing to complete so that the retry results an update. If after two retries a duplication error is still encored, FinDock reverts to the original duplicate error state.

Vipps

Mandate creation improvements

Issue: In certain rare cases, FinDock does not create an active Mandate record when a new agreement is activated in Vipps.

Solution: To help reduce the chances of this issue occurring, FinDock now creates a new Mandate record earlier in Salesforce data handling as part of the initial payment intent processing. The record is given the status Pending registration acceptance and then updated with status Success and activated based on notifications from Vipps. The FinDock Heart Beat job also regularly checks through Vipps mandates that are pending registration and Vipps notifications, updating status changes on mandates accordingly. We have also improved traceability by adding the payment intent Id to the Vipps callout message as an additional reference point.