Release Notes - April '21

We are happy to present the FinDock April '21 Release!

Important Dates:

• Release to Sandboxes: April 05, 2021
• Release to Production: April 18, 2021

New pilot features

Automated collection of payments

FinDock gives you fine-grained control over when and how payments are collected through (Recurring) Payment Schedules. However, this mechanism required regular manual work.

With this release we are introducing the ability to run the same schedules for a fixed frequency without further intervention. This automates payment collection for the given payment method and processor.

This feature will be launched as a pilot. If you are interested in participating, please contact support@findock.com.

Payment schedule data quality

To collect payments, FinDock needs a set of data specific for a payment method and processor. This data may differ per payment method and per processor. With our new data quality features, FinDock can help you make sure that the right data is in the system before you start the process of collecting payments.

Payment data quality includes:

• A description of requirements for data in the system
• Visual components that validate records in terms of scope (Installment or Payment Schedule) readiness for collection

Core

Improved error handling for Guided Matching

Issue: There are certain Apex exceptions that are not catchable. If this kind of exception occurs in Guided Matching, the transaction record gets stuck in “Processing” status without further information. The root cause could only be found under Salesforce Setup > Apex Jobs details.

Solution: We have added the status reason from the Apex Job exception to Guided Matching where it is displayed in the Guided Matching Progress component window.

New retry option in Guided Matching

Issue: The Retry All option in Guided Matching is useful, but it was limited to individual transactions (i.e. retrying the complete ruleset for one transaction record). It was not possible to retry all unmatched or ignored Transactions in a Transaction Set.

Solution: We have added a new button on the Transaction Set Progress component window. The new button, Retry Unmatched Transactions, re-runs the Guided Matching ruleset for transactions in the set that are not yet matched or were ignored.

In addition, to provide more transparency on the function of the “Retry All” option for a transaction record, we have renamed the button to Retry All Rules.

CODA Reason Code extraction

We’ve added a new rule to the CODA Guided Matching ruleset called Extract Reason Code. This new rule extracts the Reason Code from the CODA line starting with 22, using characters in position 114 through 117. This Reason Code stores the ISO Reason Return Code. For a list of possible codes, see the ISO20022 documentation.

Guided Matching stops due to message ordering

Issue 1: In rare situations, an inbound report of a PSP confirmation message may arrive earlier than expected, creating an unusual ordering sequence of payment notifications. When this occurred, Guided Matching would match the affected inbound report but then stop, leaving any further inbound reports in “Pending” status.

Solution 1: We added a new mechanism to catch this unusual scenario. Guided Matching will now try to continue to process further inbound reports.

Issue 2: An Inbound Report normally goes through a check for pending, related Inbound Report records as part of Guided Matching because there may be notification related Inbound Reports that are pending. This happens, for example, when the original Payment Intent inbound report was not processed yet. This check was not working as expected if the "Update And Refresh Before Processing" feature was part of the Guided Matching execution plan. The issue could cause pending notifications to not be updated automatically.

Solution 2: We identified the bug that was causing the issue and fixed it in this release.

Guided Matching locked row handling with NPSP

Issue: Guided Matching automatically retries an operation when it encounters a Locked Row Exception error from Salesforce. This retry functionality stopped working for customers with NPSP in the Manage Source rule when a locked row occured when creating a Opportunity.

Solution: We updated the Locked Row Exception handling so that it properly recognizes the error in this NPSP case and retries the operation as expected.

Simplified 'generate' step in payment schedule runs

Issue: Currently the ‘generate’ step in a payment schedule performs several actions. Most are related to installments, but this step also includes generating payment references for certain payment methods. The complexity of the ‘generate’ step may cause certain issues when manually adjusting payment schedule behavior.

Solution: We have moved the generation of the payment reference to an Installment trigger. This does not affect the end result of payment schedule runs, but rather makes the ‘generate’ step cleaner and improves performance in certain scenarios.

The solution also changes the format of SEPA Direct Debit payment references.

• Old format: 13 digits with 2nd digit always '0'
• New format: 21 digits with 2nd digit always '1'

Long errors from payment schedule processing stored

Issue: Some error messages that may arise from payment schedule processing are longer than would be stored in the Last Failure Reason field. Messages longer than 255 characters would be truncated, which could mean valuable information for troubleshooting was not readily available.

Solution: We changed how the error messages are handled to allow for longer messages to appear in the Last Failure Reason field.

Payment Schedule user experience enhancements

As part of our usability enhancements for FinDock users, this release includes the following improvements to the Payment Schedule Path Lightning component:

• Progress tiles (Prepare, Process, Close) now also also show in-line ProcessingHub progress information. This change means you no longer need to open ProcessingHub Manager to view progress.
• The link to ProcessingHub Manager from the payment schedule is now a deep link, meaning that the related ProcessingHub process is shown immediately as the selected process in ProcessingHub Manager.
• There is a new auto-refresh checkbox option. When selected, progress information automatically refreshes every 4 seconds.
• There is a new show details checkbox option. When selected, the progress tiles show more details. This new option replaces the chevrons (>) that used to be in the progress tiles.

Payment Schedule progress path simplified and enhanced

We have simplified and enhanced the Payment Schedule Path which shows the status of a payment schedule. The path is now context-sensitive to the processor and payment method of the schedule and dose not show a “close” phase for the combinations where this phase is not relevant or meaningful.

After this release, the following combinations do not have a “close” phase:

• Axerve-for-FinDock / Credit Card
• Buckaroo / Direct Debit
• FinDock-GoCardless / Bacs Direct Debit
• FinDock-Tikkie / Tikkie
• PaymentHub-Adyen / Credit Card
• PaymentHub-CH-DD / ESR
• PaymentHub-Checkout.com / Credit Card
• PaymentHub-LSV / ESR
• PaymentHub-Mollie / Credit Card
• PaymentHub-Mollie / Direct Debit
• PaymentHub-PayPal / PayPal
• PaymentHub-RedSys / Credit Card
• PaymentHub-SEPA / Acceptgiro
• PaymentHub-SEPA / Bolllettino Postale
• PaymentHub-SEPA / OGM
• PaymentHub-Stripe / Credit Card
• PaymentHub-Stripe / Bacs Direct Debit
• PaymentHub-Stripe / SEPA Direct Debit
• PaymentHub-Worldpay / Credit Card
• SIX-Saferpay-for-FinDock / Credit Card

Rounding error with small amounts

Issue: Due to underlying rounding rules, in some cases open amounts could end up being off by a cent (0.01).

Solution: We updated the rounding rules to ensure second decimal numbers (cents) are maintained as expected. A fix was initially introduced specifically for the Adyen package, and we have now rolled out a general solution that corrects the potential issue for the following payment extensions:

• Adyen
• Checkout.com
• Redsys
• Stripe

ProcessingHub

Bulk API usage optimization

Issue: ProcessingHub uses the Salesforce Bulk API to sync data in most operations. The Bulk API is optimized for handling large amounts of data and therefore requires minimal API calls to process that data. However, Bulk API usage creates processing overhead for Salesforces that is unreasonable for small amounts of data. The extra overhead can lead noticeably slower performance working in Salesforce and longer wait times for status updates.

Solution: ProcessingHub will now only use the Bulk API for certain data loads. For smaller amounts of data, it will instead use the Salesforce REST API which is lighter in terms of overhead. The default behavior is:

• 0 records => no API calls
• 1-20 records => REST API
• 20+n records => Bulk API

If the default limit settings for the Bulk API have been modified, ProcessingHub ignores the above cut-off amount and falls back to using the Bulk API.

Payment schedule status handling improvement

Issue: The payment schedule status was changed to 'Pending verification' with the first data push to Salesforce, even if data updates continued.

Solution: A payment schedule status is now changed to 'Pending verification' only when all data updates are completed.

Expanded support for special characters in pain.008 files

Issue : The mandate Id/name from Salesforce that is used for the <MndtId> field in SEPA pain.008 files may contain special characters which were not fully supported by FinDock. The unsupported characters could cause a bank to block the pain.008 file upload.

Solution : We have expanded support for special characters to include all characters allowed by the SEPA pain.008 XML standard. We follow the recommended conversions for non-supported characters.

Installments without targets collected when Converse is source

Issue: When Converse is used as source, FinDock could include Installments without Targets in bulk payment collection (payment schedule runs). The status of these invalid installments would not be updated, and no payment would be created.

Solution: We have added a Target field check to the data validation process on ProcessingHub to enforce having a target for all installments that are included in the payment schedule. Installments that have an empty target field are set to failed, and the following error message is added to the Last Status Reason field:
Target field is empty. Please add a target or remove the installment from the payment schedule.

The affected payment schedule is also set to failed with the following status message: Installment(s) found in this payment schedule with empty target fields. Please check the failed installment records for further information.

The failed Installment(s) can then be found and fixed, after which the Payment Schedule can be re-ran.

N43 parsing update for multi-day files

Issue: In the N43 file format, the characters “:88” indicate the end of the file. However, in N43 reports that cover multiple days, these characters are also used to indicate the end of a day, a usage FinDock did not support.

Solution: We have updated our N43 parsing rules to handle both potential meanings of “:88” in N43 files. If an N43 report covers multiple days, FinDock now creates one transaction set per 88-line found in the file.

WebHub

Multiple user accounts on Notification Gateway

Issue: Under certain circumstances, FinDock Webhub could end up with two integration user accounts for a specific org. This could result, for example, from a user account being removed after the WebHub connection was set up. While only one user has a valid connection to Salesforce, both user accounts remained on WebHub. This caused an issue with Notification Gateway which sets up connections to Salesforce based on the first user it finds for an org (as the assumption is there is only one user). If the first user is the invalid user, the connection would fail.

Solution: We changed how WebHub sets up the initial connection for an org. When a new connect flow is started, WebHub now removes all connection details that may already exist for that specific org to ensure only one integration user account with one active connection is stored to WebHub.

GoCardless

Connection handling between test and production

Issue: The connection flow with GoCardless could result in two active connections. This would occur when the Is Test setting in the GoCardless for FinDock configuration is changed while GoCardless is connected. Two active connections for one org is unintended and should not be allowed.

Solution: We’ve added a mechanism to the GoCardless for FinDock configuration that prevents users from changing the Is Test setting while there is an active connection. If a user tries to change the setting, FinDock prevents the modification and displays a tooltip telling the user that GoCardless needs to be disconnected first.

New Installment status mapping

To better align the status on Installment with the actual processing status at GoCardless, we have made the following changes:

• Quick Direct Debit: after submission, Installment status is set to ‘Pending Processing' instead of ‘Outstanding.’
• API: after the Hosted Payment Page is filled in, the Installment status is set to ‘Pending Processing.'
• Payment schedule (recurring): after payment schedule submitted payment to GoCardless, Installments in the schedule are set to ‘Pending Processing.'

A description of all Installment statusses can be found here.

NPSP

Special Installment-Opportunity update scenario enhancement

Issue: In the following unique case with NPSP, the Opportunity stage was not correctly updated.

1. Installment with a linked Opportunity already exists.
2. Installment is changed.
3. Installment stage is changed.
4. Steps 2 and 3 are done in the same database transaction.

Step 2 adds a so-called trigger stopper for step 3. Trigger stoppers are used to avoid recursive loops or very poor performance, but in this case, it prevented the linked Opportunity from getting the Installment stage change.

Solution: We refined the trigger stopper mechanism to allow for this scenario.

Stripe

New support for Bacs Direct Debit processing

You can now process Bacs Direct Debit payments, both one-time and recurring, through Stripe. For more information, please refer to our Knowledge Base.

New message logging

For advanced troubleshooting, the Message record for Stripe API calls now contains the raw request and response JSON for both incoming and outgoing calls. This includes requests generated by FinDock when a payment schedule is run.

There are two types of logs:

• Our existing cpm__Log__c records (for informal logging when logging is enabled)
• A new field cpm__Log__c on Message records

Connection handling between test and production

Issue: The connection flow introduced in the March '21 release could result in two active connections to Stripe. This would occur when the Is Test setting in the Stripe for FinDock configuration is changed while Stripe is connected. Two active connections for one org is unintended and should not be allowed.

Solution: We’ve added a mechanism to the Stripe for FinDock configuration that prevents users from changing the Is Test setting while there is an active connection. If a user tries to change the setting, FinDock prevents the modification and displays a tooltip telling the user that Stripe needs to be disconnected first.