Release Notes - November '21

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

Important Dates:

• Release to Sandboxes: October 31, 2021
• Release to Production: November 14, 2021

SEPA Credit Transfer with integrated data quality

As part of our ongoing SEPA Credit Transfer pilot, we have added new data quality validation capabilities. Payment schedule data validation is now an integral part of the payment schedule process. Our standalone Data Quality component can still be used to validate generated schedule content. However, validation will always happen as part of the payment schedule path.

Payment API support for public Experience Cloud pages

We have had several customers requested access to the FinDock Payment API from a public page via Experience Cloud and the Site Guest User. Due to the inherent restrictions for the Site Guest User, connecting to the Payment API was not feasible.

With this release, we are repurposing a well-proven piece of our API technology to solve this problem. If the synchronous part of the Payment Intent API call recognizes that the Site Guest User is the caller, the asynchronous part of the API flow will run under the FinDock ProcessingHub integration user. The user switch happens through a callout to the ProcessingHub, which then immediately makes a callback under a different user. This triggers (and allows) further processing.

Once an org is connected to ProcessingHub, the only permission the Site Guest User needs is access to Apex Class cpm.API_PaymentIntent_V2 which can be allowed by changing the related profile or by creating a permission set.

Gift Aid

Gift Aid usability improvements

While working on new documentation for Gift Aid, introduced in the previous release, we noted areas where changes to the user interface would help in setting up and using Gift Aid for FinDock. With this release, we’ve implemented a number of those findings, including:

• new Gift Aid target setup flow
• new in-line guidance
• updated and new tooltips
• dynamic layouts

You will find these improvements throughout the Gift Aid implementation on Gift Aid installment, declaration and distribution records, as well as target and general settings.

Improved Gift Aid target configuration

To make Gift Aid configuration easier and key information more accessible, we added target details to the Gift Aid general settings.

When you first open the Gift Aid extension settings (under FinDock Setup), you see default values and a reminder to configuration a target.

Instead of having to close this view and going to the ProcessingHub settings to configure a target, now you can click Create target here to add your Gift Aid target. The button takes you to a new view of your targets where you can add targets and configure them as normal.

Once you have defined a target, it appears under the Target section of the Gift Aid extension settings.

Gift Aid reversal process trigger changes

In the following situations, a Gift Aid installment was marked as Pending Reversal or Cancelled:

• Status of the related receivable installment (original donation) changes to Reversed.
• Excluded from Gift Aid field on the related receivable installment (original donation) changes from false (unchecked) to true (checked).
• The Valid Gift Aid Declaration lookup field on the related receivable installment (original donation) is empty (indicating the Gift Aid declaration for the claim is no longer valid).

Certain edge cases were not properly caught by this process, leading to potential duplicate Gift Aid claims.

New behavior:

A claimed Gift Aid installment is now marked as Pending Reversal or Cancelled when:

• Status of the related receivable installment (original donation) changes to a reversed status and did not have a reversed status before. Reversed status values are: Reversed, Refunded, Cancelled and Rejected.
• Excluded from Gift Aid field on the related receivable installment (original donation) changes from false (unchecked) to true (checked).
• The Valid Gift Aid Declaration lookup field on the related receivable installment (original donation) is empty (indicating the Gift Aid declaration for the claim is no longer valid).
• Amount Open changes from 0 to a value other than 0. This makes reversal consistent with the Eligible for Gift Aid formula, which only marks installments as eligible for Gift Aid if the open amount is 0.

Claimed Gift Aid for donations that regain eligibility

There are situations in which an installment (donation) is reversed or loses eligibility. This changes the related claimed Gift Aid status to Pending Reversal. In some cases, the donation might regain eligibility before the next Gift Aid payment schedule run. For instance, an agent might manually check the Exclude from Gift Aid checkbox on the donation, but later realizes that it was a mistake and uncheck it again.

Before, this would lead to a second Gift Aid installment being generated and from a cash flow perspective, the Gift Aid amount is reversed from HMRC and then reclaimed.

New behavior: The already claimed Gift Aid installment is just set to Collected again, and there is no change to cashflow.

Claimed Gift Aid checkbox when donation is reversed

If a Gift Aid installment was set to Pending Reversal, the Gift Aid Claimed checkbox on the related receivable installment (the donation) would be unchecked at the same time as setting the status to Pending Reversal. In some cases, this could erroneously lead to a new Gift Aid installment being generated as part of the next Gift Aid payment schedule generate phase.

New behavior: The Gift Aid Claimed checkbox is unchecked after the Gift Aid payment schedule run where the Gift Aid installment has actually been reversed.

FinDock Giving Pages

Translation support for frequency picklist

Issue: If the frequency picklist values are translated, the Payment API would reject the values because it could only validate the original English values (e.g. “Monthly”).

Solution: We’ve updated the validation framework to accept translated frequency picklist values.

Birthdate label correction

Issue: The default placeholder labels for the birthday field were in the wrong order causing day and year to display incorrectly on Giving Pages.

Solution: This is now fixed so that day and year appear in the expected order.

Field mapping handling issue

Issue: If a field in the Personal Details section is mapped to a field that is a picklist, the field renders on the page as a picklist. However, if that same field is changed to map to a field with a different type, such as text, the field would still render as a picklist on the page.

Solution: We identified the cause of the issue and fixed it. Fields are now rendered as expected based on the field type of the latest mapping.

IBAN with lowercase

Issue: When an IBAN is entered with lowercase characters, Giving Pages accepts it as a valid IBAN. However, the Payment API would reject the value because the PaymentIntent endpoint does not allow lowercase characters.

Solution: All IBAN values entered by donors are now first transformed to uppercase before being passed to the PaymentIntent endpoint.

Newsletter checkbox mapping

Issue: Custom mapping of the newsletter option (under Personal Details) was not passed to the Payment API when the newsletter checkbox is marked.

Solution: We identified the source of the bug and fixed it so that the checkbox mapping is included in the API message as expected. For example:

Before

    {
      "Contact": {
        "SalesforceFields": {
          "FirstName": "James",
          "LastName": "Smith",
        }
      }
    }

After

    {
      "Contact": {
        "SalesforceFields": {
          "FirstName": "James",
          "LastName": "Smith",
          "email_optin_mapped_field__c": true
        }
      }
    }

Non-SEPA IBAN handling improved

Issue: If a non-SEPA IBAN value is entered into a Giving Pages payment form where SEPA Direct Debit as the payment method, the Payment API throws an error when no BIC code is provided. However, Giving Pages did not recognize the issue and instead redirected to the payment failure page.

Solution: We’ve created specific error codes for this case in the Payment API (similar to invalid IBAN or invalid Sort Code for Bacs). Giving Pages catches the error now and marks the BIC field as required. We’ve included the new 200-series error codes to the API reference guide.

Special characters in text fields

Issue: If a text field, like street name, included a special character (eg. ü), the value was not stored correct in the inbound report and caused processing errors.

Solution: We fixed the bug causing this issue so that special characters are stored as expected.

Impact narrative not shown when empty

Issue: The impact narrative block on the page was shown even when there was no narrative text.

Solution: We’ve updated the page rendering to exclude the narrative block when the text field is empty.

Core

FinDock PayLinks: created via the paymentIntent API

With this release, we are adding the ability to distribute PayLink URLs created through the Payment API. If FinDock PayLinks is enabled in your org, the PayLink URL is included in the GET /Installment response and in the webhook notifications. For further information, please see the Payment API reference guide.

FinDock PayLinks: one-time Direct Debits

Issue: When changing to or updating a direct debit payment method with FinDock as source, FinDock did not perform a mandate check as part the installment update flow. The mandate check either keeps an existing mandate or creates a new one depending on certain conditions.

Before FinDock PayLinks was introduced, it was rare to see processor or method changes for an existing installment. However, we noticed internally that an installment updated via PayLinks did not lead to a new mandate as expected. The updated installment collection would fail due to the missing mandate.

Solution: We’ve updated the installment update flow to include a check on the mandate as expected.

Guided Matching: Search rule update

Issue: In Guided Review table view of a Search rule results, the reference fields would not display.

Solution: The table cells now behave as expected with Search rules. For example, in the screenshot below, before this fix, the Account Id and Owner ID columns were empty, but now the display properly.

Multi-currency orgs got updated calculation for open amount on installments

Issue: In multi-currency orgs, the Amount Open field might not be correct if the installment and/or payments were not in the default currency of the org.

Solution: The issue was caused by the way FinDock queries and summed amounts using the SOQL SUM aggregate function. This has been changed now to handle amounts that are not in the default currency of the org by querying all payment records individually to calculate the amount open.

Payment API: create account or contact without being present in the request

Issue: A null pointer exception would be thrown in the asynchronous paymentIntent handling in the following two scenarios:

• An Account is created in the Guided Matching part of the payment handling using a Create Record Guided Matching rule, but there is no Account defined the SalesforceFields section in the JSON request.
• A Contact is created in the Guided Matching part of the payment handling using a Create Record Guided Matching rule, but there is no Contact defined in the SalesforceFields section in the JSON request.

Solution: Both scenarios should be supported. We identified and fixed the underlying handling logic that lead to the thrown exceptions.

ProcessingHub

Improved support for special characters in CODA files

Issue: If a CODA file includes a character that does not use UTF-8 encoding, the file processing fails.

Solution: We have improved our character handling to fully cover ASCII and IS0-8859-1 character sets. These sets are mapped and converted to UTF-8 encoding before the CODA file is processed.

Payment schedule handling with invalid installments

Issue: If a payment schedule is processed with both valid and invalid installments, the processing may fail due to a data scope mismatch among the installments on ProcessingHub.

Solution: We’ve introduced an additional data check on ProcessingHub to ensure the scope of the data processed for each installment is the same. However, this does not fix the underlying problem of invalid installments. The Data Quality component should be used to confirm that all data on the schedule and in related installments is valid (after the schedule is generated).

Multi-currency: Gift Aid and Bacs file totals incorrectly set to EUR

Issue: When a payment schedule for claiming Gift Aid or collecting Bacs Direct Debit payments is generated, the file totals are uploaded to Salesforce. However, ProcessingHub did not set the currency, so the file totals used the default currency EUR. For multi-currency orgs, this is a problem when the currency should be GBP. In addition, if a multi-currency org does not have EUR enabled, the payment schedule process fails with the data load error: Invalid currency code: EUR.

Solution: For Gift Aid and Bacs payment schedules, the FinDock now records the currency as GBP on the PaymentHub File record and uses that in the file totals.

WebHub

Creating WebHub endpoints for receiving notifications

Issue: FinDock automatically generates the endpoint URL that external processors use for sending notifications to WebHub. The URL is based on the Salesforce org Id, but the way the unique URL was created could cause errors in some cases.

Solution: We changed the formula for how the URL is generated so that it will now work in all cases.

Buckaroo

Error handling change

Issue: While troubleshooting a situation with Buckaroo SEPA Direct Debit notifications, we ran into a situation where exceptions could be caught without logging an error. This prevented us from determining the root cause of the exceptions.

Solution: An exception is now handled by standard Guided Matching error handing. The related Inbound Report record is set to Failed and contains a clear error message. This change will give us the needed insights to determine the root cause should a customer experience a similar exception.

Mollie

Set description via the Payment API

For Installments created and collected via payment schedules with Mollie as processor, the value in the bank statement description field on installments is included in the submission to Mollie. However, for one-time payments and the initial payment of a recurring payment made via the Payment API, the description was not included because the payment did not pass through Salesforce before being collected.

We’ve now updated the Mollie integration to be able to include a description for one-time and initial recurring payments that uses the payment methods Bancontact, Credit Card, iDEAL, PayPal, and Sofort. The bank statement description is used if the description parameter for the payment method is not provided. If neither is provided, the paymentIntentId value is used for the payment description in the Mollie dashboard (and the Mollie payment page).

SEDA

Multiple mandates for same payment profile

Issue: When uploading a SEDA mandate acceptance file that contains two (or more) mandates linked to the same payment profile, the file processing fails with a duplicate Id error.

Solution: We identified an issue with our Inbound Report logic and changed it now so that files with multiple mandates per payment profiles are processed without error as expected.

SmartDebit

Payment reference generation change

Issue: When a mandate Id is over 16 characters long, FinDock cannot create a unique payment reference value. This is due to the way payment references for SmartDebit are generated: mandate Id '-' unique string = 18 character payment reference. This isn’t a problem for sending out a payment collection, but when processing the response. It can lead to FinDock finding multiple installments that match the payment reference. FinDock automatically selects the first installment found which potentially could be the wrong one.

Solution: To fix this potential issue, ProcessingHub now uses the payment reference (in the file sent to SmartDebit) combined with the payment schedule collection date or Bacs processing date to match installments when processing the response for SmartDebit.

Payment schedule processing improvement

Issue: In some cases, ProcessingHub would not complete all internal data management tasks before the next SmartDebit payment schedule processing started. When this happens, processing of new payment schedules is blocked.

Solution: We identified the source of the issue and improved internal workflow handling to prevent this issue from occurring. Now ProcessingHub completes all tasks for a given SmartDebit payment schedule and associated data before the next schedule processing starts.

Tikkie

Configurable expiration date

We’ve added a new setting to the Tikkie for FinDock extension so you can adjust the expiration date of Tikkies created through FinDock. The new Days Before Expiration setting calculates the expiration date by adding the number of days to the date when the Tikkie is created. If left empty, Tikkies expire after 14 days by default. Entering 365, for example, would set your Tikkies to expire after a full year.