Skip to main content

Release Notes - May '23

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

note

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.

Important Dates:

  • Release to Sandboxes: April 23, 2023
  • Release to Production: May 21, 2023

Native Credit Card MOTO to General Availability​

We are excited to announce the FinDock Payment component for collecting MOTO payments natively in Salesforce is now Generally Available. 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 and beta customers for your valuable feedback!

As part of the GA release, we have implemented several improvements:

  • To prevent errors related to Mandate and Payment Profile update and creation from interrupting a MOTO payment flow through the FinDock Payment component, some logic has been moved to the PaymentIntent Inbound report. No significant change is expected to the user experience.
  • Re-named "re-use existing card" feature to "re-use stored card" feature to align with industry-standard language.
  • Several other user experience improvements based on feedback from beta customers.

New support for Vipps mobile payments​

As part of our development to support the Nordics payments market area, we have built a new payment extension for Vipps, a very popular Norwegian payments appclication. You can collect both one-time and recurring payments through Vipps directly from FinDock. Customers who are interested to join the pilot for Vipps can reach out to support@findock.com to learn more.

Stripe​

Handling payment profile without credit card number​

Issue: If a contact had a related payment profile for credit card (type = Credit Card), but the card number field was empty, FinDock would throw a de-reference null error when trying to accept a credit card payment on the contact using Stripe. This would heavily impact MOTO payments that re-use a stored card, since a Contact would always be found.

Solution : This scenario will now create a new payment profile for the entered credit card number rather than result in an error.

US Direct Debit payments with ACH through Stripe​

Support was added for Direct Debit payments with ACH in the USA through Stripe. Both one-time and recurring payments are supported. Stripe supports bank detail verification through Instant Verification - where the payer logs into their bank account - and micro-deposits.

Bacs​

New bank account and sort code check capabilities​

To prevent issues with UK Direct Debit, payers' bank account and sort code combinations are automatically checked when a payment is accepted through the FinDock Payment API, PayLinks and Giving Pages. Additionally, the sort code and bank account could be manually checked on the payment profiles through a LWC component.

With this release, three new methods are added to check the validity of bank account & sort code combinations:

  • An Apex Action that can be used in Flow
  • The existing LWC which can now be used not only on Payment Profile, but also Installment, Recurring Payment, Opportunity, Recurring Donation, as well as in a custom Flow
  • An invokable Apex Class

The Sort Code and Bank Account Checker can confirm the validity of a sort code and a bank account passed directly, or it can check existing data for a given Payment Profile Id.

Data quality validation update​

Issue: When running a Bacs Manual mandate schedule, the validation could raise a false validation error. This was caused by the scope of the built-in validation rules. Some SmartDebit rules - like address being required - are not relevant for our Bacs Manual processor, but were checked anyway.

Solution: The built-in validation rules for Bacs Manual are part of the original Bacs package implementation. Since then, FinDock has developed a new Data Quality solution with more capabilities, including proper rule filtering. With this release, the validation step in a Bacs Manual schedule kicks off the latest Data Quality rules so that no SmartDebit rules are included in Bacs Manual validation checks, as expected.

To reduce impact, this is enabled automatically for new installations. If you have an existing installations your can request the new validation to be switched on by contacting support@findock.com.

GoCardless​

Failed Billing Request Notifications​

Issue: GoCardless notifies FinDock via the billing_request.fulfilled notification. In some cases, FinDock expects a contact on the inbound report when there was no contact present. This resulted in failed inbound reports, with no impact on collection.

Solution: Execution of the Guided Matching rules is now skipped when it is not required.

Buckaroo​

Missing Installments for some iDEAL QR payments​

Issue: When an iDEAL QR payment amount of 100.00 or higher, the inbound report fails, preventing FinDock from creating an installment.

Solution: This issue was caused by an incorrect pattern search on amounts. We’ve fixed the error so that amounts of 100.00 or higher are recognized as expected.

Notification delivery error due to long strings​

Issue: If a Buckaroo notification includes very long string values, FinDock could not store them, leading to undelivered notifications to Notification Gateway.

Solution: FinDock now truncates long strings to allow for storage. The customer impact was minimal, with a small number of delayed notifications used to update Salesforce data. The payments themselves are still collected.

Core​

Notification Gateway: improvements to auto-retries​

When FinDock can’t deliver a notification from a PSP to a Salesforce environment, this notification is retried. Improvements to the timing of the retry have been made to improve the chances of success of the retry.

Bollettino Postale: Find Installment Guided Matching rule update​

Issue: If a contact has multiple closed and open installments with the same payment reference, FinDock may incorrectly match the Closed installments based on the payment amount and payment reference in newly uploaded Bollettino Postale files. When this happens, FinDock does not update the first open installment as expected, and the related inbound report goes to Failed.

Solution: FinDock now filters out installments with Closed status as part of the Find Installment rule.

CODA: rounding error on amount​

Issue: Due to a rounding error, amounts would sometimes be parsed with a lot of decimals. For instance, 4 euro would become 3.999999995 euro. This would prevent the Transaction from being matched to an Installment based on amount.

Solution: Amounts will now be properly rounded and Transactions should be matched to Installments again.

Guided Matching component error handling update​

Issue: In certain unusual circumstances, the Guided Review component of Guided Matching can throw an error indicating that it "cannot read properties". This can happen, for example, when the component does not find an Installment record.

Solution: We have made some updates to the component to eliminate this type of error.

Permission for ProcessingHub Manager tab​

Issue: Access to the ProcessingHub Manager tab has not been part of the PaymentHub Operations permission set. This means that by default users without system administration rights could not see the ProcessingHub Manager tab. This made it hard to grant minimum permissions for users who needed access to the tab but otherwise should not have full admin rights.

Solution: We’ve now added ProcessingHub Manager tab access to the PaymentHub Operations permission set.

Guided Matching: work with Salesforce Financial Services Producer object​

Issue: Due to the Salesforce API version used by Guided Matching, it was not possible to query or update the Producer object of the Salesforce Financial Services cloud.

Solution: The API version has been updated to include the Producer object.

Guided Matching: Record type selection improvement​

Issue: When configuring a custom Guided Matching rule to create a payment profile, you can select the Record Type from a picklist. The list is generated from the existing Record Types available for Payment Profile. However, there may appear to be duplicates because the list displays the Record Type Label, which may be the same between processors in some cases, such as Bank Account for GoCardless (gcf__Bank_Account_ _c) and Stripe (phstr__Bank_Account__c). Additionally while processing matching rules, Guided Matching could not distinguish between the different record types with the same label and would randomly select one which could be incorrect.

Solution: To help distinguish between Record Types for different processors that may have common labels, we have updated labels to include the processor name. While processing, the selected record types (with new labels) are used.

note

If you have existing matching rules on Payment Profile where the record type is set to, for example, Bank Account, you need to update these with the new label value to benefit from the corrected behavior.

Guided Matching: Transactions with 15-character references not matched to Installments​

Issue: When a Transaction with a payment reference of exactly 15 characters was processed in Guided Matching, its corresponding Installment was not found even if the payment references matched.

Solution: This issue was caused by FinDock trying to convert 15-character references to Salesforce Ids. With the Salesforce API version used this would not give an error even if the 15-character reference was not an actual Salesforce Id. We updated the Salesforce API version to a version that gives a proper error, so that FinDock treats 15-character references that are not Salesforce Ids as strings.

Leading zeroes in bank account for MT940 with Triodos​

Issue: For MT940 files from the Dutch Triodos bank, FinDock would strip leading zeroes from the bank account, which resulted in bank accounts that start with a 0 to be parsed incorrectly.

Solution: We’ve changed the parsing logic to parse the expected length of the bank account, instead of just removing leading zeroes.

ProcessingHub​

Camt.053 with long remittance values​

Issue: If you upload a camt.053 file containing remittance information (<RmtInf>) that exceeds 255 characters, the file import fails and blocks further file processing.

Solution: FinDock now automatically trims the remittance value to max. 255 characters. This trimming also applies to remittance information inside Payment Reference (<Ref>) elements.

Nordics (PILOT)​

File transfer after payment schedule when not enabled​

Issue: FinDock would attempt to send OCR files generated by payment schedules to the FTP file service of Mastercard Payment Services even if the file transfer option in the Nordic Payments extension settings was not enabled. This resulted in blocked payment schedule processes on ProcessingHub.

Solution: We have implemented the expected settings check to ensure ProcessingHub does not contact MPS if the file transfer option is not enabled.

SEPA and SEDA​

Non-EEA payments for CBI pain.008​

In our June ‘21 release, we added support for non-EEA payments for SEPA Direct Debit. We’ve now extended this support to SEPA Direct Debit through CBI. This is mostly relevant for Italian customers.

SEPA: Shield encryption of FinDock objects​

All FinDock functionality with regards to SEPA are now compatible with Shield encryption. With this change, all FinDock fields can be encrypted through Shield. For more detailed information on FinDock and Shield encryption, please read our FAQ on Shield encryption here.

NPSP​

NPSP: No Installments created for Opportunities created with closed status​

Issue: When an Opportunity is created with a closed status, FinDock did not automatically create installments even when the setting “Create Installments for closed Opportunities” was enabled in the setup. This issue was introduced with the March '23 release fix for double installments for NPSP Opportunities. For more info on this past double installment fix, please visit our release notes

Solution: We fixed the underlying logic to ensure installments are created for new opportunities with a closed status. Customers potentially impacted by this issue have also been contacted directly.

Giving Pages​

Updated localization of currency for Norway​

For the Norwegian Krone currency, the currency for amounts on Giving Pages and PayLinks would show up in front of the amount. This meant that - like euro showing up like €5- Norwegian Krone would simply show up as kr 5 instead of 5 Kr as would be expected by local Norwegian payers. We've updated our localization handling to to show the Kr currency tag behind the amount for browsers in Norwegian language.