We are happy to present the FinDock July '20 Release and a new online payment experience!
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: June 28, 2020
- Release to Production: July 12, 2020
New features in pilot phase:
- Enhanced FinDock Online Payment Experience
- Version 2 of the Payment API , bringing significant performance improvements and enhanced data processing
- FinDock WebHub , a new foundation built on Heroku for connecting with FinDock and Salesforce that dramatically simplifies, for example, payment extension setups
- FinDock Notification Gateway , hosted on WebHub, further improves connections with PSPs and ensures customers have a smooth online payment experience
- FinDock Giving Pages , our new out-of-the-box fundraising solution that enables you to easily create and launch donation pages without needing to code anything. The Giving Pages capabilities are built on top of our new enhanced API experience
- GoCardless for FinDock , a new payment extension for the GoCardless platform that provides an easy path to support Bacs Direct Debit payments for customers in the UK
The enhancements and bug fixes included in this release are described below and sorted according to which FinDock package is impacted by the changes.
We’ve updated the permission sets in FinDock Core to include Apex classes that have @AuraEnabled. For more information about this authentication change, please refer to the Salesforce release notes [here](https://releasenotes.docs.salesforce.com/en-us/winter20/release- notes/rn_lc_restrict_apex_authenticated_users.htm).
We have added a Bank Identification Number (BIN) field to the Payment Profile
Card_Bin__c. The BIN field identifies the issuing bank of the card
and consists of the first 4-6 letters of the card's Primary Account Number
(PAN). After this release, FinDock automatically stores the BIN number in the
new field on Payment Profile. Currently, this new field is only populated by
transactions through Axerve. If you are using Axerve already, you can add the
BIN field to the
Payment_Profile_c-Credit Card page layout if needed. For
new installations of FinDock, the BIN field is included in the
Payment_Profile_c-Credit Card page layout.
Issue: Upserting a file record from ProcessingHub can fail because an upsert on a non-unique external ID field requires View All permission.
Solution: We added View All permission to
File__c in the ProcessingHub
Operations permission set to allow upsert.
Issue: In some cases, CAMT files from the Dutch ING bank would have an empty value for SEPA mandatory tags. When this file was imported, FinDock would flag the file processing as failed due to an XSD validation error, requiring you to contact FinDock Support.
Solution: Instead of setting the process to failed, FinDock rejects the file and provides and error message indicating the XSD validation issue. You can manually add the missing values in the CAMT file and re-upload the file.
Issue: Certain banks in Germany do not use the standard tag
<NM> in the
CdtrChmeId in PAIN.008 files as allowed by SEPA. Instead, they follow the data format according to DFÜ Agreement Appendix 3: Specification of Data Formats. For these banks, the PAIN.008 files generated by FinDock were not accepted.
Solution: FinDock checks for the Country Code for Germany
DE in the IBAN, and, if found, the tags that are not allowed according to the DFÜ specification are removed from the PAIN.008 file.
If the Mandate for an InBound Report could not be found, the status of the report was set to ‘error’ without further information. We’ve updated the error to help identify the root cause of the error. The new error message is:
Couldn't find Mandate with Mandate ID:. This message is shown in Salesforce on the field
We have added new parsing rules to our PAIN.002 processing to support the CBI envelope CBIBdySDDStsRpt. This allows Italian customers to process PAIN.002 files wrapped in a CBI envelope as is without needing to make any modifications prior to uploading.
Issue: With Field Mapper enabled, when an Installment and Opportunity were created via the Payment API, the bank statement description on the Installment was empty.
Solution: The source of the bug was identified and corrected. When the bank statement description is provided from the Opportunity, the value will be synced between Opportunity and Installment based on the Field Mapper configuration.
We’ve added support for the Belgian SEPA Additional Optional Service, Overschrijving met gestructureerde mededeling (OGM), both as a payment method and payment request type. Similar to Acceptgiro, you can use OGM for one-time and recurring payments. You can also use OGM with the Payment Request Generator to create payment requests with OGM references. After this release is deployed, simply take OGM into use as a payment method by activating OGM in the SEPA payment extension settings. For payment requests, OGM is available as a reference type with this release update.
The SEDA service from FinDock uses the customer's tax code to register new
mandates. To support situations where another tax code is needed instead of
the one from the customer, we added a new field
the Payment Profile. If this field is left empty, the tax code on Contact is
used. If you already have SEPA installed and want to use this new field, you
need to add the field to a page layout.
Issue: After completing a credit card payment, the user was redirected to the incorrect URL. Solution: We identified the bug causing the redirect error and fixed it so the user is taken to the correct URL.
Issues: With Tikkie for FinDock, we had two bugs:
When IsTest was switched OFF for Tikkie, you would get a “Subscription Error: API key is invalid for the requested resource” error when you tried to create a Tikkie through the Quick Tikkie component, the Payment Request Generator or the Payment API.
When IsTest was switched ON for Tikkie, you would get a “appToken is in invalid format” error when trying to save your Tikkie configuration.
Solution: These problems were caused by incorrect configuration and access of the FinDock keys for Tikkie with regards to Test and Production. Both Test and Production settings now work properly with Sandbox & Production keys and tokens, and our documentation has been updated accordingly. For more information, please see Tikkie for FinDock.
In the previous version of Stripe for FinDock, the Stripe payment method ID
passed from Stripe to FinDock was stored in the Payment Profile
field. However, we see Payment Profile as a key object in the customer 360° view.
If a customer has only one credit card, there should only be one payment profile record, regardless of which processors use the payment profile for collection. This not always the case yet, but we are working towards that goal. After this release, the Stripe token is be stored in a Stripe-specific field, the
Payment_Method_Id__c field, on Mandate. However, a Stripe Payment Schedule will also look for the payment method ID on Payment Profile as fallback. This means there is no impact on existing installations, and no actions are required to start using the new field.
Issue: In some cases, notifications sent by Stripe to FinDock could change the Payment Profile on an existing Installment, even though the Payment Profile was already valid and correct. This lead to incorrect or unwanted handling of the payment.
Solution: We modified our Stripe solution to ensure Stripe notifications do not change the Payment Profile on the Installment once the profile is set.
Issue: If Customizable Rollups were enabled in NPSP, when the mandate on a Recurring Donation was changed through a SIX Saferpay payment, the mandate was not updated correctly on related Opportunities.
Solution: We modified the execution process to ensure that changes on Recurring Donations are populated to related Opportunities in any context.