Skip to main content

Release Notes - July '20

We are happy to present the FinDock July '20 Release and a new online payment experience!

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 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.

FinDock Core​

Support for new @AuraEnabled authentication​

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).

Credit card BIN field on Payment Profile​

We have added a Bank Identification Number (BIN) field to the Payment Profile object, 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.

ProcessingHub​

Upsert failure on non-unique external ID field​

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.

CAMT: Dutch ING file imports failed on empty values​

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.

PAIN.008 file upload failed for specific German banks​

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.

Improved error message for ProcessingHub​

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 cpm__Inoubnd_Report__c.cpm_Status__Reason__c.

XML SEPA CBI parsing added to PAIN.002 file handling​

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.

FinDock for NPSP​

Empty bank statement description​

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.

SEPA for FinDock​

Belgian OGM for SEPA​

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.

Italy custom tax code​

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 paysepa_Custom_Tax_Code_c to 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.

Buckaroo for FinDock​

Incorrect Buckaroo credit card redirect handling​

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.

Tikkie for FinDock​

Tikkie authentication issues with API Key and appToken​

Issues: With Tikkie for FinDock, we had two bugs:

  1. 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.

  2. 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.

Stripe for FinDock​

Stripe recurring token moved to Mandate object​

In the previous version of Stripe for FinDock, the Stripe payment method ID passed from Stripe to FinDock was stored in the Payment Profile Token__c 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.

Stripe notification incorrectly changes Payment Profile on Installment​

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.

SIX Saferpay for FinDock​

Incorrect mandate handling in NPSP​

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.