Release Notes - March '21

We are happy to present the FinDock March '21 Release!

Important Dates:

• Release to Sandboxes: March 07, 2021
• Release to Production: March 21, 2021

GoCardless goes GA

We are very happy to announce that our GoCardless payment extension has reached General Availability for all customers after successful pilot and beta testing. GoCardless for FinDock provides a simple path to Bacs Direct Debit processing through GoCardless.

The current version enables you to:

• Connect your GoCardless account to Salesforce with a few clicks
• Collect online one-time and recurring Bacs Direct Debits through GoCardless
• Manually enter DDIs and set up one-time and recurring payments from Salesforce
• Automatically send the required Bacs notifications through GoCardless
• Handle updates and refunds automatically through GoCardless notifications

For customers who have already been using GoCardless for FinDock, we have included important enhancements worth noting.

Multi-merchant support fixes We discovered during beta testing a few issues that were preventing multi- merchant configurations from behaving as expected. These have been resolved now so multi-merchant accounts are fully supported.

Lead-time handling improvement When running a payment schedule to collect recurring payments, FinDock could try to create a payment in GoCardless with a charge date before the next possible charge date for the given mandate. The next possible charge date is always a few days in the future because of the mandate lead-time required by the Bacs Direct Debit scheme. Creating the charge too soon would result in a failed installment, and the payment could not be collected without additional action.

With this release, the payment schedule run now checks what the next possible charge date is from the related mandate for each payment. If the installment due date is before that next possible charge, no charge date will be provided when creating the payment in GoCardless, which means that GoCardless will collect the payment as soon as possible.

For more information on GoCardless for FinDock, please visit our documentation:

• Configuring GoCardless for FinDock
• Using GoCardless for FinDock

Stripe enhancements

The Stripe for FinDock payment extensions sees several updates in this release. These include new functionality as well as enhancements and fixes.

Implementation upgrade with Stripe Connect

We have upgraded the integration of our Stripe for FinDock extension with the Stripe Connect service. With Stripe Connect, setting up your Stripe integration is significantly easier. Instead of filling in settings in both FinDock and Stripe, you can now just click a button to authenticate and set the right subscriptions for webhook notifications.

Multi-merchant support

We have added multi-merchant support to the Stripe for FinDock extension. This allows for managing multiple Stripe accounts from the same Salesforce environment. For more information about our multi-merchant feature, see Multi-merchant accounts for PSPs.

Pre-fill email address on checkout page

If the email address of a customer is known, either because the customer was de-duplicated in Salesforce or the email address was passed in the API call, we now pre-fill this email address on the Stripe Checkout page. This prevents a user from having to type their email address twice in the same payment flow.

Support for SEPA Direct Debit processing

You can now process SEPA direct debits, both one-time and recurring, through Stripe. For more information, please refer to our Knowledge Base.

Incorrect currency set for payment in multi-currency orgs

Issue: In multi-currency orgs, payments were created based on the org default currency instead of the currency of the payment as set in the notification from Stripe, which could lead to incorrect payments.

Solution: We identified and fixed the bug causing this error. In multi- currency orgs, Stripe payments are now created with the correct currency.

FinDock Core

Giving Pages: dynamic campaign assignment

We’ve added a new method for linking a donation through Giving Pages to a specific campaign. One way is to add the campaign ID in the Payment Form configuration. This acts as the default assignment for payments made through that form.

Now you can override the default (if there is one) by adding the campaign directly to the Giving Page URL using the parameter CampaignId. For example, the URL https://www.<subdomain>.givingpage.org/a-lot-of-whales?CampaignId=abc123 will insert the campaign ID “abc123” into the payment record. If the value is invalid, the URL redirects to the Payment Form error message/page.

Giving Pages: metadata and image settings not working

Issue: The metadata and image settings for Pages were not working as expected for social media (and other) previews.

Solution: The underlying reason for the issue was a minor bug that we have fixed now. The Page metadata and image settings work as Meta Tags.

Guided Matching rules clickable from execution plan

We’ve enhanced the Guided Matching interface to make it easier to see and edit rule details directly from the setup page. The rules in the Rule Execution Plan in the right-hand pane are blue to show that they are links. Clicking on a rule opens a new window where the rule details can be viewed and edited.

Guided Matching rule updates for extracting account numbers from CODA files

Issue: In our January '21 release, we introduced a new way of processing CODA files using Guided Matching. The pre-shipped rules in that release, however, did not handle BBANs well. BBANs use an older and shorter bank account number format. In these cases, the currency would be included in the extracted bank account number.

Solution: The fixed width result is first stored in Custom 5 field, after which a regular expression rule extracts the bank account number and discards the currency value if it is present in the raw extraction.

Guided Matching rule updates for handling payment profiles in CODA files

Issue: In our January '21 release, we introduced a new way of processing CODA files using Guided Matching. The pre-shipped rules with that release, however, did not handle joint accounts well, such as when a couple or family use the same bank account. If there were multiple payment profile records with the same IBAN, FinDock could not identify a match, and instead created a new payment profile record.

Solution: We added new rules that put records into Guided Review when multiple payment profiles with the same IBAN are encountered. These new rules (31-33 pictured below) are unmanaged, so they can be modified to meet the specific requirements of your organization.

Guided Matching rule updates for payment method code in CODA files

Issue: In our January '21 release, we introduced a new way of processing CODA files using Guided Matching. The pre-shipped rules in that release only extracted the the Family for the Reported Payment Method (characters 55-56 on line starting with 21). We received feedback from customers that the Uniform Code needs to be extracted as well, which are the next two characters.

Solution: Characters 55-58 on the line starting with 21 are now stored in the Reported Payment Method Code field.

New iDEAL issuer Revolut

We’ve added the iDEAL issuer Revolut to the list of available issuers in FinDock. Revolut can be used with the following processors:

• Adyen
• Buckaroo
• Checkout.com
• Mollie

If you are using v1 of the Payment API with these processors, instead of using the Revolut value you need to use a specific BIC value for the Revolut issuer.

• For Adyen: issuer = REVOGB21
• For Buckaroo, Checkout.com and Mollie: issuer = REVOLT21

Deploy Config overrides alphabetical listing option for picklists

Issue: If the ordering option “Display values alphabetically, not in the order entered” was selected for a picklist, Deploy Config would not maintain that setting and changed the order of the picklist.

Solution: We changed the Deploy Config rules to respect the alphabetical listing option, restoring it if deployment makes changes to the respective picklist values.

Shield Platform Encryption blocking update

Issue: If an org has Shield Platform Encryption enabled and the Name field on the Opportunity object is encrypted, FinDock package updates could not be installed due to a failing unit test.

Solution: We identified and resolved the issue preventing package updates in this encryption scenario. Package updates will pass Salesforce encryption support checks as expected.

ProcessingHub

Currency ignored in camt.053 charge element

Issue: Currency may be defined in the transaction sub-element for charges. FinDock did not check for currency in the <Chrgs> tag as part of camt.053 processing.

Solution: When processing camt.053 files, FinDock now checks for currency in <Chrgs> and sync the value with Salesforce if the org has multi-currency enabled.

Incorrect currency extracted from camt.053 files

Issue: When processing camt.053 files, in certain cases, FinDock would not use the correct amount for a given transaction. This was due to FinDock only comparing <Amt Ccy> in the <Bal> and <NtryDtls> tags. However, <AmtCcy> can also appear between these two levels within the <Ntry> tag.

Solution: The FinDock processing rules for camt.053 files now also take into consideration the currency defined at the <Ntry> level of the file.

Bacs Input Report processing fails on missing errors tag

Issue: If there is no <errors> tag declared in the Bacs Inbound Report, FinDock would not process the file and fail with an “invalid argument” error message. This was unnecessarily strict since the report file can be otherwise valid, and normal processing therefore expected.

Solution: We have updated the Bacs Inbound Report validation rules to allow processing files that do not include the <errors> tag.

Some pain.008 files rejected due to adjustments for UK banks

Issue: Due to the new way BIC and address fields are handled for the payment profile (to support post-Brexit UK ban processing), generated pain.008 files were not accepted by Triodos validation rules.

Solution: We added two AdrLine elements for the address of the debtor:

• 1st line: street and house name/number
• 2nd line: zip code and city

NPSP

Initial payment not linked to related recurring donation

Issue: When using initialPayment in API v2 calls, the Opportunity record for the initial payment was not linked to the related recurring donation record.

Solution: We fixed the bug causing the linking issue so that now the Opportunity record for the initial payment is linked to its related recurring donations in NPSP as expected.

Syncing issues with auto-created household account

Issue: When NPSP creates a household account after a new contact is inserted through a Forward to Source operation (e.g. as part of Guided Matching), the account is attached to the opportunity but not synced back to the related installment, which is not expected. The account field should remain in sync between opportunity and installment.

Solution: We modified how the account field is handled so that auto-created household accounts are consistently synced to the related installment of the opportunity when Forward to Source is used.

One-way mappings may cause Guided Matching error

Issue: One-way mappings from Opportunity to Installment in the Opportunity Installment Field Mapper could lead to a field query error in the Guided Matching Manage Source rule.

Solution: We identified a problem with the scope of one of the methods used for handling custom field mappings. This was fixed now so that one-way mappings are properly fetched and processed in Guided Matching.

Adyen

Enhanced iDEAL issuer handling

We have added a new optional issuer parameter for Adyen where you can set a specific issuer (bank) for iDEAL payments. This redirects customers to the specified bank rather, eliminating the step where customers would otherwise make their own selection from the full list of official issuers.

When an Adyen configuration is in test mode, FinDock bypasses its normal set of iDEAL issuers and overrides any issuer in the API message to Adyen with a test issuer value.

Optional parameter for setting Adyen Pay-by-Link expiration

We’ve added support for changing the default 24-hour expiration of Pay-by-Link links. This is handled with the optional expiresAt parameter (see Adyen API Explorer). For further information on how expiration works, visit the Adyen Docs.

This new parameter support is available for custom integrations and FinDock Giving Pages (Payment Form configuration). In the expiresAt parameter of the Payment API call, please note that the value is specified in minutes. FinDock calculates on the fly the timestamp value expected by Adyen.

Support for 'offer cancelled' events

If a customer abandons a payment journey (after being redirected to the online banking method), Adyen can send an OFFER_CLOSED webhook event which FinDock now supports. If FinDock receives this event, the related installment is set to failed.

This event is not available by default. You need to contact Adyen Support and ask them to enable it for your account.

Rounding error with open amounts

Issue: Due to underlying rounding rules, in some cases open amounts could end up being off by a cent (0.01).

Solution: We updated the rounding rules to ensure second decimal numbers (cents) are maintained as expected.

Incorrect time stamp parsing

Issue: Notification event dates from Adyen use GMT for the timestamp. FinDock was parsing these timestamps using the time zone of the integration user account for the WebHub which could lead to incorrect results if that user time zone was not GMT.

Solution: We have changed how FinDock parses Adyen event dates so that the date is always interpreted as a GMT timestamp.

SIX Saferpay

First installment of recurring payment not updated with payment profile information (only API v1)

Issue: On collection of an initial payment for a recurring payment from SIX Saferpay, FinDock did not update the payment profile for the associated installment.

Solution: This issue was caused by an obsolete condition used with SIX Saferpay payment handling. We removed the condition, and now installments are updated as expected.

Worldpay

Notifications with special characters causing issues

Issue: Special characters in the payload of notifications from Worldpay were not handled correctly in Salesforce due to encoding issues.

Solution: We changed the message handling so that special characters are escaped to conform to Salesforce decoding capabilities.