Release Notes - September '23

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

Important Dates:

• Release to sandboxes: August 27, 2023
• Release to production: September 24, 2023

NEW PILOT - Renewed FinDock setup experience

With this release, we are starting to pilot a completely new setup experience, with the goal of making FinDock easier to install and configure. This includes a significant re-design of FinDock settings, bringing everything together in one place. Package installation and deployment processes are being re-engineered for speed and ease of access through the new setup interface.

Part of the new setup experience is a revamped approach to managing FinDock permissions. To improve control and simplify permission assignments, we are introducing new Permission Set Group definitions. These groups use refined, modular permission sets that are assigned to groups on the fly through the new FinDock Setup. Custom permission sets can also be assigned to these groups.

There's a lot happening with the new setup experience. Too much to get into here. Join us at the release webinar to find out more! If you would like be part of the pilot and help us shape the setup experience, please contact FinDock Support.

Support for Salesforce integration user license (BETA)

Part of the FinDock Setup enhancements includes new permission sets for integration use cases. All the new integration permission sets have been tested to comply with the new Salesforce integration user license. Existing FinDock installations do not need to start using the new permission sets. However, they are available to all customers for testing.

Please refer to the Sept. '23 version of the Permissions article for further details.

Nordic Payments and Vipps to GA

After a successful beta testing phase, FinDock is now ready to move the Nordic Payments (AvtaleGiro) and Vipps packages to General Availability! All customers are welcome use our native AvtaleGiro direct debit solution and our Vipps mobile payments integration.

Core

Collected installments counter on Recurring Payment

Issue: The Recurring Payment field “# of collected installments” (cpm__n_of_collected_installments__c), is not re-calculated after a payment schedule run is completed.

Solution: We have introduced a new Apex job that counts the number of related installments for a given recurring payment that have status Collected. The job is part of the FinDock Heart Beat and can also be triggered via a new button on the Recurring Payment page. This counter currently only supports FinDock as source.

Daily recurring payment schedule skips days

Issue: Business hours were not correctly factored into the calculation for Collection Date on Recurring Payment Schedule. The Collection Date was calculated using calendar days and then adjusting to the nearest business day based on configured conflict strategy. Run Date was calculated based on business days. This could result in future dates not getting assigned as a Run Date, leading to missing payment schedule runs and potentially delayed payment collections.

Solution: We have corrected the Collection Date calculation to only count business days as expected. This eliminates future dates not getting a calculated Run Date since both dates now rely on business days only. The issue also impacted the preview component for future payment schedules, so that has been fixed as well.

Recalculate counters button on payment schedule

Issue: Clicking the recalculate button on a payment schedule did not update the counters.

Solution: This issue was caused by a missing permission for the button which has now been added.

Remaining Revenue field on Recurring Payment

The Expected Remaining Revenue field (cpm_ _Expected_Remaining_Revenue_ _c) on Recurring Payment is an implemented concept that today does not have an active role in FinDock payment management.

Some customers may want to use this field for their own formula calculations, but others may find the field unnecessary. For this reason, with this release customers who do not want the field can now remove it from the Recurring Payment object.

Payment API too many queueables error

Issue: In certain rare cases, a PaymentIntent message results in the error: Too Many queueables added to queue: 2. When this happens, follow-up notifications from the PSP cannot be processed, leading to potentially outdated information in Salesforce.

Solution: The issue was caused by the processing times of inbound reports in synchronous versus asynchronous actions. We have introduced a new queue check to prevent too many records from being added to the queue when something takes longer than expected.

Guided Matching leave remainder update

Issue: With the Leave Remainder on Transaction / Inbound Report option in Guided Matching (introduced in the July '23 release), records were put to Partially Matched when no further installments are found. This would prevented creating new installments for the remaining amount as part of Guided Review.

Solution: When the leave remainder option is used and no installments are found, the record status is put to Guided Review to allow further handling as intended.

ProcessingHub

CODA processing for type 5 entries

Some CODA files may use the optional transaction (sub)type 5 entries for transaction details. However, FinDock did not support extracting information from these entries, which could result in missing Transaction records for matching.

To ensure these optional details are captured, we updated the parsing rules for CODA files on ProcessingHub. Now if the file includes a subtype 5 entry, FinDock skips the entry for type 1 (total file record) and instead creates a Transaction record for the entry with transaction subtype 5 (detail record of type 1 entry).

Mandate schedule enhancement for large runs

Issue: If a Bacs Manual or SEDA mandate schedule for contains more than ~2,000 records, the generated file may contain errors. Some mandates are duplicated, while others are missing. This would result in some new mandates not getting registered.

Solution: FinDock has reached out to the limited number of impacted customers to resolve faulty mandate schedule runs. In addition, we have introduced a new file validation mechanism that checks the contents of the generated mandate file. This ensures the expected mandate records are included and without duplication. If the file does not pass validation, the mandate schedule is set to Failed with the error message: Generated file is invalid. Please contact FinDock Support for assistance.

Support for Salesforce Winter '24 authentication

With the Salesforce Winter '24 release, new restrictions around authorization flows were introduced which blocked ProcessingHub connections. We have now updated the oAuth flow for ProcessingHub to support the new restrictions.

WebHub

Improved account management

With this release, we are completing our ongoing efforts to re-engineer access management for FinDock Heroku apps to improve security and maintainability. The work was done first for ProcessingHub, and then Notification Gateway in the previous release. As the final step, WebHub is now also part of the improved account management solution.

PayLinks

New support for custom fonts

The custom font support in FinDock Giving Pages has been extended to PayLinks. Customers can now specify their own fonts for use on the payment form behind a PayLink.

Bacs Manual

Installment aggregation logic update

Issue: Installments with Pending Recollection status (transaction code 018) are aggregated with new or uncollected installments (transaction code 17). This broad aggregation can lead to challenges with certain Bacs guidance around recollection.

Solution: We have updated the aggregation logic to exclude installments with Pending Recollection status. This change does not apply to customers that use Smartdebit.

Last payment transaction code

Issue: Bacs Direct Debit has a specific transaction code (19) for the last installment of a recurring payment. Though supported, FinDock did not use the code for the last installment.

Solution: FinDock can now set the expected transaction code correctly for the last installment of a recurring payment. This is done through a new Use Last on Next Run checkbox on Mandate. Before the final installment is due, manually check the checkbox (set to true). When the installment is collected, FinDock deactivates the related mandate with a Close Reason indicating the last installment has been processed.

AUDDIS reason code C handling correction

Issue: With reason code C in an AUDDIS report, FinDock automatically cancelled the related mandate, whereas the reason code indicates a mandate update is needed.

Solution: We changed the FinDock action for AUDDIS reason code C to set the resulting Inbound Report record status to Manual. This allows the existing mandate to merely be updated rather than cancelled.

Gift Aid

Data Quality rule update

Issue: The validation rules for Gift Aid Declaration incorrectly allowed overseas addresses without postal codes.

Solution: We updated the rules so that postal code is required for both UK and overseas addresses.

GoCardless

Quick DD fails on recurring setup

Issue: When using the Quick Direct Debit component for GoCardless, setting up a recurring payment would fail in some cases. This was likely caused by changes made around bank account handling in the Jan. '23 release. Since then, if the bank account for the new recurring payment was already known, the setup process would fail. In some instances, FinDock also would not always create the expected record type for GoCardless.

Solution: The component now will always create a BBAN record type for the recurring payment. Because the new record may not have all required information to pass normal data quality, we now also exclude the record from account and sort code validation if the bank account field starts with BA (which indicates the Id is from GoCardless).

Mollie

Notification handling failure when payer info is missing

Issue: In rare cases, FinDock may receive a Mollie notification that does not include payer details like holder name. The handling rules assumed such details are always present and tried to create a payment profile, which caused the whole notification handling process to Failed.

Solution: We updated the Mollie notification handling to allow for missing payer information. If the information is not included, the notification is still parsed and matched, but the payment profile creation step is skipped.

Nordic Payments

Correction to KID generation with Modulo 10

Issue: When using Modulo 10 for KID generation, FinDock would in some specific cases generate a KID that is one digit too long, resulting in failed mandates.

Solution: The issue was caused by an incorrect calculation when the generated KID ends with 0 (zero). We have now updated the calculations to correctly handle this according to the Modulo 10 specifications from Mastercard Payment Services.

SEPA

One-time payment sequence type

Issue: In our July '23 release, FinDock introduced support for setting the SEPA sequence type for first payments (FRST). However, this code was in some cases incorrectly used for one-time payments.

Solution: We have fixed the type handling to correctly set OOFF for one-time payments.

Last payment sequence type

Issue: SEPA Direct Debit uses a specific sequence type (FNAL) for the last installment of a recurring payment. Though supported, FinDock did not use the code for the last installment.

Solution: FinDock can now set the expected sequence type correctly for the last installment of a recurring payment. This is done through a new Use Last on Next Run checkbox on Mandate. Before the last payment is due, manually check the checkbox (set to true). When the payment schedule is completed successfully, FinDock deactivates the related mandate with a Close Reason indicating the last installment has been processed.

SmartDebit

Handling of large payment schedules

Issue: If a SmartDebit payment schedule includes over 5,000 records, the payment schedule process on ProcessingHub fails due to an issue with FinDock batch processing for SmartDebit.

Solution: If a payment schedule has more that 5,000 records, FinDock automatically splits the results into multiple files and send the batches to SmartDebit as expected.

AUDDIS reason code C handling correction

Issue: With reason code C in an AUDDIS report, FinDock automatically cancelled the related mandate, whereas the reason code indicates a mandate update is needed.

Solution: We changed the FinDock action for AUDDIS reason code C to set the resulting Inbound Report record status to Manual. This allows the existing mandate to merely be updated rather than cancelled.

Vipps

Handling update for pending agreements

Issue: During periods of high traffic, the Vipps service may not immediately activate new agreements. They instead go through a pending registration phase before becoming active. Agreements not immediately activated were redirected to the FinDock failure URL and no corresponding mandate was created.

Solution: Both active and pending agreements are now redirected to the FinDock success URL. A Mandate record is created in both cases, but the mandate for pending agreements is set to Pending Registration. A new FinDock Heartbeat polling job checks Vipps for the status of pending agreements. Once and agreement is active in Vipps, FinDock activates the corresponding mandate in Salesforce.

New data validation and retry mechanism

Issue: Recurring Vipps payments could result in failed messages and stalled inbound report processing.

Solution: To reduce the chances of failures and stuck reports, we have implemented additional measures for collecting Vipps payments:

1. Vipps added to FinDock Data Quality with rule(s) to validate values, such as description length, that were a common source of message failures
2. New retry mechanism to resolve failures caused by temporary issues