Skip to main content

Release Notes - June '21

We are happy to present the FinDock June '21 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: June 6, 2021
  • Release to Production: June 20, 2021

In this release, we have a new add-on feature, FinDock PayLinks, for beta testing, and introduce updates to our on-going piloting with the new Payment Schedule features.

For any kind of business, regardless of your online presence, payment links are an incredibly effective and easy way to collect payments. With FinDock PayLinks, you get auto-generated payment links in Salesforce. Share the link through any channel, from a customer service agent call, to email, messaging apps, or even a pay button in a PDF.

The payment link takes customers to your own branded payment form hosted by FinDock. Customers can pay with their preferred method, and you get fully-integrated, end-to-end payment handling automatically. Set up FinDock PayLinks once and use anywhere for any purpose at any time.

Because FinDock PayLinks is built on top of existing FinDock core capabilities such as the Payment API, we're able to roll this out as a beta feature. This means we're open to work with all of our customers on FinDock PayLinks and looking forward to your feedback and experiences.

Please note that FinDock PayLinks will be an add-on feature to FinDock with additional pricing. Join us at the this release webinar to find out more!

Payment Collection: Auto-collect payments moves to beta​

We are happy to announce that the Auto-collect payments feature is moving to beta. The underlying technology is stable, and we made a solid update to the user experience. Based on pilot feedback, we have modified the initial configuration to make it easier to set up and manage auto-collecting payments.

Notable changes since the pilot release include:

  • Option to exclude a specific payment schedule from auto-collection
  • When a payment schedules is running automatically, and no installments are selected (no payments for that schedule), the status is put to done instead of failed
  • Added daily option next to the already existing weekly and monthly recurring payment collection intervals
  • Updated the initial configuration flow for increased usability

New auto-collection settings on payment method

Payment Collection: Data validation pilot update​

We'd link to thank all our customers for the value feedback we've gotten. We continue to work on fine-tuning individual validation rules for different payment methods. There are also some notable enhancements coming in this release.

Validation performance improvement

We’ve made significant improvements to the performance of the Payment Collection: Data Validation feature pilot compared to our initial release. Next to optimizing the underlying validation architecture, we especially focused on speeding up validation for large data volume (LDV) orgs.

In our testing we’ve consistently been able to validate 300.000 installments in around 2.5 minutes. Exact performance will vary per org, but performance jump is significant for LDVs where validation was lasting hours.

The performance improvements make the Data Validation component useful for all our customers, regardless of data sizes.

Simplified validation results

In the initial release of the Payment Schedule: Data Quality pilot feature, running the validation on a payment schedule would show a payment schedule error, such as missing run date, as multiple occurrences on installment level. Conversely, validation results on installment level would show errors on the payment schedule related to that installment.

We’ve now cleaned up the validation results views to only show the relevant validation rule results.

Data Quality RecordType value changed to Label

We’ve made a minor change to the Payment Schedule: Data Quality feature pilot to improve readability of validation results. Where we used to have the DeveloperName, we now use Label. For example, “bank_account” will now appear as “Bank Account.”

New restart option

To make it easier to re-run data quality validation rules for installments and payment schedules, we have added a new Restart button on the data quality component. Just click the button to re-run the validation rules for the record. You can re-run the validation on both successful and failed validations.

Restart button on unsuccessful validation

Core​

Giving Pages preset amounts for monthly frequency​

Issue: When 'Monthly' is selected as the default frequency for a Giving Page, the page shows the correct frequency but the amount presets are for one-time payment. The correct presets on shown on the page when the visitor switches to the one-time payment option and then back to monthly.

Solution: We identified and fixed the bug causing this issue so that monthly presets are shown as expected.

Payment schedule: path details for completed stage(s)​

With this release, you can now click on completed stages in the paymentschedule path to see the details for that stage.

Previous stage details on Payment Schedule Path

Recurring payment schedule: New weekly and daily options for recurring payment schedules​

We have added Saturday and Sunday to the day options for weekly recurring payment schedules. In addition, we have added a new daily recurring payment schedule record type.

Coming soon: Mandate Schedule Path​

We are working on a brand new Mandate Schedule Path, very similar to the Payment Schedule Path, for mandate schedule processes. In preparation, this release includes three new fields on the Mandate Schedule object:

  • Generate Async Apex Job Id
  • Validate Async Apex Job Id
  • Status Before Failed

These fields are filled automatically with the correct values by FinDock triggers. They do not impact FinDock functionality.

ProcessingHub​

Bulk vs. REST API selection​

Issue: To determine whether ProcessingHub should use Salesforce REST vs. Bulk API (for optimum syncing speed), we first run the query over the REST API. If this resulted in more then the 20-record limit enforced by Salesforce, ProcessingHub discarded the result and switched to the Bulk API. However, when ProcessingHub had to sync an exceptionally large number of records (millions), the initial 20-limit check would hang due to a timeout error.

Solution: We added a hard limit of 20 records to ProcessingHub as part of the initial REST API query. This avoids the timeout issue while not changing the intended REST vs. Bulk API behavior.

Parsing fixes for camt.053 and camt.054 files​

Issue: ProcessingHub selected the IBAN of a camt file (by comparing the IBAN of the file against the target IBAN) separately from the account holder name and address details. This could in some cases result in the wrong name and address being used for the selected IBAN in the transaction record.

Solution: We’ve updated our camt.053 and camt.054 parsing rules to group the IBAN, account holder name and address and make a select the whole group based on the target comparison. This method ensures the correct name and address are used for the selected IBAN.

SEPA​

Optional tag removed from pain.008 files for Austrian banks​

Issue: The optional <Nm> name tag FinDock inserts into pain.008 files was preventing file acceptance by an Austrian bank.

Solution: Since the tag is not required by Austrian banks, we have removed it from pain.008 files that are generated for Austrian banks.

Pain.002 processing update for file batches​

Issue: If a pain.002 file included batches with same identifier, ProcessingHub would assume the second instance is a duplicate and ignore the batch. However, in pain.002 files it is possible that batches with the same Id have different transaction entries. In such cases, ProcessingHub would miss the transactions of the “duplicate” batch.

Solution: We have changed how ProcessingHub parses pain.002 files. Batch Ids are now ignored, ensuring that the content of every batch in a given file is fully processed.

Pain.008 support for non-EEA banks​

In our February '21 release, we updated the field mapping for pain.008 file creation to include BIC and address fields on the Payment Profile object to handle UK banks after the regulatory changes of Brexit. In this release, we are expanding the solution to cover SEPA Direct Debit collection for all non-EEA banks.

These fields will only be mapped if the IBAN of the payment profile record indicates the debtor has a non-EEA bank account. FinDock validates these data requirements both during the processing of the payment schedule and in the data validation rules for SEPA.

This enhanced pain.008 support for non-EEA SEPA Direct Debits is enabled automatically with new FinDock installations. If you have an existing installation and would like this new capability, please contact FinDock Support.

note

The functionality introduced in the Februrary '21 release for handling debiting UK bank accounts is now also part of this new toggle. If current customers want to keep using Feb. '21 functionality for debitin UK bank accounts, that toggle should be enabled manually.

Mollie (API v1)​

SOFORT payment redirect​

Issue: When using Mollie with SOFORT through our Payment API v1 (Classic Online Experience), in some cases an error occurred when Mollie redirected the user to Klarna to complete the SOFORT payment. This was caused by FinDock trying to store the redirect URL in a field where it did not fit (due to a 255 character limit). This was done to prevent duplicate notifications from Mollie from being handled in FinDock.

Solution: When FinDock sees that the redirect URL for Klarna is too long, the URL is not stored to prevent errors. The impact on duplicate notification handling is minimal.

Stripe​

Test connection change​

info

If you were using Stripe Connect from a Sandbox environment, please disconnect and reconnect your Stripe account. The current connection will no longer work end-to-end.

Issue: When the isTest option is enabled for the Stripe extension in a Salesforce production org, notifications from Stripe were not received because WebHub could not find the Salesforce org. This was caused by the Stripe test app being connected to the WebHub test app, while the production org was connected to the WebHub production app.

Solution: We reworked the Salesforce-WebHub-Stripe connection logic to ensure no mismatch in environments is possible. From now on the following connections are created based on the type of Salesforce org and the IsTest setting in the FinDock Stripe setup:

  • Salesforce production org & IsTest = False → WebHub Prod → FinDock Stripe Connect Production app (live) → Your Stripe account (live)
  • Salesforce production org & IsTest = True → WebHub Prod → FinDock Stripe Connect Production app (test) → Your Stripe account (test)
  • Salesforce sandbox org & IsTest = True → WebHub Test → FinDock Stripe Connect Test app (test) → Your Stripe account (test)

Using Stripe Live (real payments) with a sandbox org where IsTest = False is no longer possible to prevent production data in test environments. We advise to perform a penny test on your production org with IsTest = False before go-live after successful tests in your Salesforce sandbox and production orgs with IsTest = True.