Release Notes - March '23

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

Important Dates:

• Release to Sandboxes: February 26, 2023
• Release to Production: March 26, 2023

Lift off for the Nordics

FinDock now supports AvtaleGiro direct debit payments for Norway! While we have announced support for new payment methods from time to time, this announcement is bigger.

Not only are we building support for AvtaleGiro, but we are doing it for FinDock as the processor, much like Bacs Manual, SEPA Direct Debit, and Swiss Payments. The AvtaleGiro direct debit method is just the initial step, too. It is the first method in our new payments extension package called Nordic Payments.

Additionaly, FinDock also supports reconciling payments using the Norwegian OCR file specification via Mastercard Payment Services (formerly known as Nets).

As with all major new features, we are launching this support as a pilot with testing carried out by participating customers. If you are interested to be included in this pilot, please reach out to support@findock.com.

Native MOTO support to Beta

We are happy to announce the FinDock Payment component for collecting MOTO payments natively in Salesforce is now open to all customers for beta testing. Though MOTO is a paid add-on feature, it is available in all Sandbox environments as trial. A big Thank You! to all our pilot customers for your valuable feedback!

As part of the beta release, we have added support for re-using existing credit cards. If a payer already has payment details for one or more credit cards in Salesforce, the agent can now select from these cards directly from the FinDock Payment component.

FinDock automatically checks for available credit cards using details stored on Mandate and Payment Profile records for the given contact/account. Cards that meet the required criteria (e.g. mandate is active, card is active and has not expired) are displayed in a picklist on the component. If no card is found, the re-use block remains empty and disabled.

Multiple Stripe accounts and card reuse Credit cards can only be re-used from the Payment Component if they are authorized within the Stripe Account (FinDock Target) that the component will use to process the payment. If you have multiple Stripe accounts connected to FinDock, this may lead to cards not being available for reuse in the Payment Component even though the related mandate is active. This depends on how you have configured your Target settings.

In addition, we've made a couple of important enhancements to existing MOTO capabilities:

• Default component preview in Flow layout
  The Save card for one-time payments setting on the FinDock Payment component is off (false) by default. However, when adding the component to a Flow, the setting appeared to be checked (true) in the layout preview. This led to the Flow not creating a Mandate record as expected. Now the component shows the setting is unchecked (false) in the default Flow layout. For current Flows, the issue can be resolved by unchecking and checking the option again.
• Recurring card payment processing update
  Authorization requirements for an existing credit card can change, for example, through new 3DS verification imposed by the bank. If this occurred, FinDock could not collect using the existing card. The payment intent would appear to succeed, but the collection would fail. Now FinDock sends additional information to Stripe to notify Stripe the card has already been set up for MOTO payment collection. If additional action is still required, the payment intent should now fail instead of appearing to succeed.

New improved Notification Gateway

We’ve completely re-engineered the engine that drives Notification Gateway. This new proactive development ensures future scalability, as well as steady performance even under very heavy loads. While we are excited about this enhancement, the changes are entirely backend. The gateway endpoints for every customer remain the same, and notification handling continues without pause.

Core

Data Quality rule selection update for mandate schedules

Issue: With the new field dependency between Payment Processor and Target on Mandate Schedule introduced in the January '23 release, it was possible for Bacs Direct Debit data quality validation to fail with the error No default Setup Record found for category PSP.

Solution: The error was caused by a bug in the Data Quality rule selection logic. We’ve now fixed the logic so the rules are selected correctly when a dependency is defined for Bacs Direct Debit.

Payment Schedule path view

Issue: When auto-run is used for payment schedules, the payment schedule status in some cases appears to not go to Generating. This is a visual error caused by the Payment Schedule Path element not getting updated correctly by FinDock HeartBeat. The payment schedule would however progress correctly.

Solution: We fixed the underlying heart beat job to ensure the path element is updated to correctly reflect the latest payment schedule status.

Summary amounts on payment schedules missing

Issue: In some cases, the counters used to report summary totals for tracking payment schedules would not return a value and instead appear empty.

Solution: The missing values were caused by errors in the batch job that runs the calculations (as part of the FinDock Heart Beat and when counters are manually triggered to recalculate by pressing the button on a payment schedule). The errors would appear on occasion due to the underlying query and unexpected, yet technically possible, null values, such as an empty amount field on an Installment. We’ve updated the query logic and addressed the null exceptions to ensure summary totals are available on payment schedules as expected.

Giving Pages

Server error in builder

Issue: When many custom fields and/or fields with many picklist values and record types were used to build the payment form, FinDock would sometimes show a Server Error message. This was caused by the configuration of a Giving Pages page is stored as a JSON. For pages with complex payment forms, the JSON file can get quite long. When the JSON exceeded the maximum characters allowed the error was shown.

Solution: We have increased the character limit the JSON storage. The previous limit was 32,768, and now it is 131,072 characters, allowing for exceeding large configurations.

Stricter validation for payer email address

Issue: The email address validation used for Giving Pages would not catch empty spaces in the email value, leading to rejected payer information at the PSP because of invalid emails.

Solution: We have updated the email validation to use the strictest rules to ensure empty spaces in addresses are caught by Giving Pages on entry of the data and before data is the payer information is sent to the PSP.

ProcessingHub

Euro dependency in multi-currency orgs

Issue: If you are using a multi-currency org without EUR enabled, FinDock could encounter a currency error when running a mandate schedule. Instead of completing, the process would end with Currency ISO CODE: invalid currency code: EUR.

Solution: The issue was caused by how FinDock handles updates to PaymentHub File records. We’ve fixed this now to remove the unnecessary Euro dependency.

Raw XML entry encoding error

Issue: As part of lifecycle management upgrades for ProcessingHub software components, we needed to make adjustments to the handling of raw XML entries for parsed bank statement files. The adjustments were applied too broadly, leading to unwanted verbose (very long) XML in the raw XML entries. This would not impact the actual handling of these records, but made it hard to manually analyse the data.

Solution: We rolled back certain adjustments where they are not needed to ensure raw XML entries remain a reasonable length.

NPSP

Installments not aggregated when payment schedule uses auto run

Issue: Installments are not aggregated as expected if Bacs Manual or SmartDebit payment schedule are set to run automatically (Auto Run enabled). This could lead to incorrect payment reports for payers or, in the case of SmartDebit, possible skipped installment collection.

Solution: Due to a bug on the auto-run execution, the aggregation step was skipped. We’ve now fixed this.

Possible duplicate installments for single opportunity

Issue: In certain contexts, NPSP customers may see double installments created for the same opportunity. This happens when triggers for update and insert actions on Opportunity occur in an unexpected order. The duplicate installments could then lead to over collecting for the opportunity.

Solution: To help ensure this does not happen on new opportunities, we have introduced additional logic to prevent duplicate execution of FinDock logic. This logic is similar to what FinDock already performs for update actions. We are contacting customers directly to check for possible double collections.

Payment schedule Generate step error checking

Issue: Since the November '22 release, in orgs using the queueable framework generate step for payment schedules could result in incorrect payment schedule runs. Even when a specific job failed, the payment schedule continued and appeared to complete successfully This could lead, for example, to payment schedules missing relevant installments without indicating an error.

Solution: The issue was caused by a bug in the source connector packages for NPSP. This has now been fixed so that failed job errors are caught as expected.

SIX Saferpay

TWINT recurring payments

With this release we have expanded our support from TWINT payments through SIX Saferpay. Now, in addition to one-time payments, you can set up recurring payments using TWINT.

SmartDebit

Archived Chatter Group check blocks payment schedule

Issue: The archived Chatter Group check introduced in the January '23 release should only be performed when Chatter Groups are used. However, this check was also performed for SmartDebit payments that do not require a Chatter Group, resulting in blocked SmartDebit jobs.

Solution: We identified and fixed the bug causing the issue so SmartDebit is now excluded from the archived Chatter Group check as expected.

WorldPay Corporate Gateway

Payment records missing for collected installments

Issue: Using payment schedules to collect credit card installments through WorldPay Corporate Gateway would result in successfully collected installments without payment records and not updated open amounts. This was caused by an incorrect response to the WorldPay notifications that triggered the creation of these payments. This would cause Worldpay to stop sending notifications for the Worldpay account in question.

Solution: FinDock now sends a the response to WorldPay that correctly initiates the follow-up payment confirmation notification.