We are happy to present the FinDock February '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: February 07, 2021
- Release to Production: February 21, 2021
UPDATE: 2021-02-22 The issue we encoutered with automatically pushing updates for the NPSP and Buckaroo packages to some orgs has been resolved. All sandbox and production orgs now have the Feb. '21 release updates.
We're very proud to announce that FinDock Giving Pages will be Generally Available with this release. What started many months ago, end of June '20, with a closed pilot has steadily grown and matured and we're very happy, thanksfull and proud on the result. Many thanks to all our partners and customers who have been working with us on FinDock Giving Pages. Your feedback and testing has made it possible to reach this final step of making Giving Pages Generally Available to all FinDock customers.
For those of you who have already been using Giving Pages, we have more than a few improvements, enhancements and fixes to announce. For those who don't know yet what FinDock Giving Pages is please visit our dedicated webpage for more information.
Based on learnings & feedback during the pilot and beta phase, we have designed and implemented two new templates. These templates replace the old templates, without breaking the old templates.
The templates are fully responsive and render beautifull on all common screen sizes, browsers and devices, both desktop and mobile.
Two templates are now available:
- Activate: a large, page-width hero image with a title and subtitle set above a donation form with space for copy on the left.
- Excite: focused on just the donation form with a full-height image on the left, without distraction.
It's our goal to make it very easy to create a beautiful page based on the two new templates. Therefore we have included example images, text and titles in the templates. These assets & texts are included when you first create a page from a template. Pictures include instructions on the optimal size in pixels. The payment form will also have some example values included.
All example assets, text & values can be edited. But this gives you the ability to create a tryle beautifull pages, for example the two screenshots above, in minutes.
Visit our Knowledge Base for updated Giving Pages set up instructions.
We’ve upgraded the customization options for the thank you and error pages that are part of the Payment Form setup. The new options allow you to adjust font appearance and add images to the pages. Here is what the new options look like:
500 error results in frozen page
Issue: If the
GET /PaymentMethods call returns a 500 error, the page would freeze and no longer function.
Solution: 500 errors are now redirected to the expected
IBAN validation and transformation
We’ve added new transformation rules to handle IBAN values that are valid on front-end user entry, but are otherwise invalid for Salesforce and the FinDock Payment API. The new transformation rules remove empty spaces in the IBAN value and convert lower case letters into upper case letters.
Address handling update for Payment Form
Issue: Previously, the Payment Form address option provided two fields - one for street name and one for street number - for donors to fill in. These two fields were concatenated in Salesforce, but the ordering of street + number did not work for all countries.
Solution: The address entry on the front end of the Payment Form only has one field, so donors can write their street address as needed. The address value will be stored in one Salesforce field based on your Personal Details mapping.
New page & domain deletion flow
Issue: Previously, subdomains could be deleted even if there were existing pages for that domain. These pages would appear again when a new subdomain is created, but they could not be used. You could delete pages, but it was not possible to delete the last page as this was automatically set as the default page for the domain.
Solution: We’ve changed the domain and page deletion logic so that you cannot delete a subdomain if there are any pages associated with it. All pages under a domain need to be deleted, including the last (default) page, before you are allowed to delete your subdomain. After all pages are deleted, the subdomain can be deleted. When a new subdomain is created, it starts with a clean, empty list of pages.
Page Builder: new targets not visible in payment settings
Issue: New targets added to FinDock were not available in the list of targets under the Payment Form settings for existing pages.
Solution: We identified and fixed the bug causing this issue. The list of target options in the Payment Form settings for both new and existing pages now shows all available targets.
Page Builder: enhanced amount configuration
We’ve added new options and additional customization features to the Amounts & Frequency settings for the Payment Form configuration.
Default payment period: you can now select which payment period (currently one-time or monthly) is shown to page visitors when they fill in the payment form
Hide decimals: new toggle for showing or hiding decimals places in the donation amounts for page visitors
Open Amount error messages: you can use the default texts from FinDock or create your own.
Page Builder: personal details dropdown lists ordering
Issue: The dropdown lists in the personal details mapping table where sorted chronologically by CreatedDate instead of by name, making it difficult to find certain values in the lists.
Solution: We have reordered the lists to be alphabetical according to name.
Page Builder: user interaction improvements
Several of the Page and Payment Form settings in the Page Builder need to be properly filled in for a page and form to work correctly. This includes, for example, page metadata, at least one payment method is selected, a target is defined for direct debits and so forth.
To ensure these settings are filled in (and saved), we’ve added a number of new prompts and messages to help guide users when creating new pages.
Page Builder: unsaved changes warning
In the Page Builder, we’ve added a new prompt if there are unsaved changes when you try to publish the page. The message gives you the opportunity to either cancel publishing or continue with saving the changes and publishing.
Page Builder: new info texts and tooltips
To make it easier to understand the Giving pages builder functionality, we have added info text and tooltips to many fields.
Issue: With every release, the Payment Intent rule for Guided Matching was updated, overwriting customizations and returning the rule configuration to the default setup.
Solution: We changed the update process so that this rule is not overwritten if there have been any modifications done to the default rule configuration.
Issue: When adding business hours for weekly or monthly recurring payment schedule setup, the preview of the schedule was not generated as expected.
Solution: We identified the bug causing the issue and resolved it. Previews are generated as expected now.
We’ve added the automatic calculation now so that the Bacs processing date is calculated according to Collection Date (taking business hours and holidays into consideration) and added to the generated payment schedules accordingly.
Issue: If there is a payment journey value set on the recurring payment schedule, it was not added to the generated payment schedules.
Solution: We identified the source of the bug and fixed it. If payment journey is defined on a recurring payment schedule, it is now reflected in the generated payment schedules.
Issue: Guided Matching uses auto-retry when locked row exceptions are encountered. If the locked row happens to be the on the main Transaction or Inbound Report record, auto-retry could lead to already executed rules being re-run and causing unexpected results.
Solution : The Guided Matching auto-retry functionality now checks the type of record which caused the locked row exception. If the type is Transaction or Inbound Report, the Guided Matching job is not retried. Instead, a clear error message is generated, which can be found under Setup > Apex Jobs. The affected records remain in the “Processing” state when this error occurs.
Issue: In Manual Review, if you split payments to different campaigns, FinDock would save the last selected campaign to all related installments.
Solution: We fixed the mapping logic so that FinDock always maintains the individual campaign mappings per installment as it does with payments.
We’ve added specific support to our MT940 file parsing for specific banks/BIC's from BancoPosta (Italy), Barclays (UK) and Triodos Bank (Belgium).
Issue: ProcessingHub automatically retries create and update operations when locked row exceptions are encountered. However, the retries were only for master records and ignored locked row exceptions on records updated via triggers.
Solution: We have updated the retry mechanism so that retries are attempted for all possible locked row exceptions.
Issue: In most cases, the the IBAN of the debtor can be extracted from a specific element within the CAMT file. However, in some cases this location is not specifying the debtor account, but rather the creditor account. The debtor account is instead a BBAN value that is stored in a different element within the CAMT file. FinDock parsing rules did not account for this edge possibility and always used the IBAN in the file.
Solution: We have updated our CAMT parsing rules to include extracting BBAN values which may be for the debtor or creditor accounts. FinDock first looks for IBAN values and checks these values against the IBAN of the target to determine the IBAN/BBAN of the debtor.
Issue: When the status of an opportunity is changed to closed-won, the close date on the Opportunity is updated to today, different then standard SFDC behavior. This occurs when the Last Collection Date is empty.
Solution: We have changed the relevant data processing logic so that Last Collection Date from Installment is used to set the close data on opportunities only if the Last Collection Date field is not empty. If Last Collection Date is empty, no changes are made to the opportunity close date, and standard SFDC behavior applies.
Issue: The forward-to-source rule used in API calls, Guided Matching and Manual Review, ignored the status mapping in FinDock for NPSP settings when the status of an installment was manually changed. The status of the related opportunity was hardcoded (to posted status) and did not allow for mapping.
Solution: We have introduced a new custom setting
NPSP4Hub_Settings__c and added checkbox for this to the FinDock for NPSP general settings. The new option, “Use Status Mapping in Forward To Source,” is selected by default for new installations. For existing installations, this option is not enabled to ensure backwards compatibility with current org settings. When this new option
is selected, FinDock checks first if there is a status mapping. If not, the related opportunity is set to the default NPSP closed opportunity stage setting. If this default setting is not defined, FinDock uses sets the status to ’Posted'.
Issue: The SEPA Direct Debit Core scheme has been updated to take into account the status change of UK banks due to the regulatory impact of Brexit. Collection files (pain.008) now require additional information if the debtor is using a UK bank account. Specifically, the collection files need to include the full address of the debtor and the BIC code of the debtor bank.
Solution: We’ve updated the field mapping for pain.008 file creation to include BIC and address fields on the Payment Profile object. These fields will only be mapped if the IBAN of the payment profile record indicates the debtor is in the UK. FinDock does not validate the values for BIC and address fields as part of this mapping. Customers need to ensure the fields are correctly filled in for pain.008 compliance (of UK collections). Please also note that for this collection scenario, the country field on Payment Profile needs to use the Alpha-2 ISO country code (e.g. "GB" for United Kingdom) for the pain.008 to be valid.
Issue: If the same mandate appears in an SEDAD file more than once, processing the Inbound Report record would fail.
Solution: Mandates are normally not repeated in a SEDAD file. However, there are cases when, for example, a bank amends or cancels a mandate on the same day (or very soon after) it was created. These cases are unusual and need further attention. With this release, if a mandate is found more than once in a SEDAD file, the Inbound Report record in question is set to manual review.
Issue: If the redirect URL for a Buckaroo payment was opened more than once (e.g. the browser tab was refreshed), this would create additional transactions in Buckaroo.
Solution: We added a new parameter to the
redirectURL that prevents multiple transactions from being created at Buckaroo if that URL is used more than once.
Issue: If the redirect URL for a Mollie payment was opened more than once (e.g. the browser tab was refreshed), this would create additional transactions in Mollie.
Solution: We added a new parameter to the
redirectURL that prevents multiple transactions from being created at Mollie if that URL is used more than once.
Issue: The message content and code for Axerve errors were being added to the same field in Salesforce,
installment.cpm__Last_Failure_Reason__c. Based on customer feedback, this approach made certain business logic unnecessarily complex.
Solution: The error code and error message are now stored in separate fields. The error code is stored on
installment.cpm__Last_ReasonCode_Received__c, and the error message is stored on
We have upgraded the Redsys for FinDock integration to support the FinDock Payment API based on the request submission form integration option from Redsys. This new implementation supports both one-time and recurring credit card payments taken by Redsys directly into Salesforce.
Issue: In the Redsys ProcessingHub process credit cards were considered expired on the first day of the expiration month instead of the last day of the month.
Solution: We fixed the bug causing the incorrect interpretation of the expiration date. Now, for example, if the expiration date is 1/2020, the card is valid until 1/2/2021 as expected, instead of being considered expired already on 1/1/2021.
Issue: The endpoint setting in the Redsys for FinDock extension configuration page was hard coded to point to the Redsys test environment.
Solution: We updated the code so that the endpoint value entered in the FinDock configuration page is used for the Redsys integration.
With this release, Checkout.com for FinDock is compatible with version 2 of the FinDock Payment API.