We are happy to present the FinDock April '21 Release!
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.
- Release to Sandboxes: April 05, 2021
- Release to Production: April 18, 2021
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.
PILOT STATUS UPDATE 2021-04-21
The new data quality features are being made available to all customers with the April '21 release. For further information, please see FinDock 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
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.
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.
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.
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.
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.
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'
This change impacts FinDock Core and SEPA packages. Other payment methods and processors will be added in the future.
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.
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.
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
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:
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.
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.
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.
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.
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.
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.
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.
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.
Issue: In the following unique case with NPSP, the Opportunity stage was not correctly updated.
- Installment with a linked Opportunity already exists.
- Installment is changed.
- Installment stage is changed.
- 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.
You can now process Bacs Direct Debit payments, both one-time and recurring, through Stripe. For more information, please refer to our Knowledge Base.
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__crecords (for informal logging when logging is enabled)
- A new field
cpm__Log__con Message records
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.