Release Notes - January '21

We are happy to present the FinDock January '21 release!

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: January 03, 2021
• Release to Production: January 17, 2021

2020 has been a busy and tough year for everyone, but there's hope for the future. On the Findock font, for our last release announcement of the year we have positive news. In January we are going fully live with the FinDock Enhanced Online Payment Experience. The performance and robustness of the Payment API v2 will be generally available for all customers.

In addition, we are excited to announce FinDock has signed a new partnership with GoCardless and is rolling out a new payment extension, GoCardless for FinDock (beta), in the Jan. '21 release.

Enhanced Online Payment Experience is now GA

We're proud to anounce that the 'Enhanced Online Payment Experience' is now Generally Available. The Enhanced Online Payment Experience includes the following components:

• Payment API v2
• FinDock Webhub and Notfication Gateway

These bring expanded functionality in the API but also major non-functional improvements in architecture, robustness and performance. It makes FinDock much easier to setup up for the first time and removes the use of the VisualForce Site Guest User completely for FinDock! For a detailed overview of the features and benefits please read our API migration article.

The change to GA has the following implications:

• The concept "Enhanced Online Payment Experience" will not be used anymore. The term "Classic" will used to refer to the original API v1 and VisualForce Site Guest User architecture.
• For new FinDock installations, the payment processor extensions settings won't include the Classic and Enhanced toggles anymore. New installations will use API v2 by default.
• The term Payment API and general references to the "API" now refer to version 2 of the FinDock Payment API.

The following sections provide an overview of the changes made for the General Availability release of the Enhanced Online Payment Experience.

APIv2: Reworked and added webhook notifications

Previously, when a WebhookURL attribute was included in the request to the /PaymentIntent endpoint, only webhook notifications were sent when an Installment was created or the status of the Installment was changed.

Now, wehbook notfications are also sent for other events. The body of the notification is also updated to include the type of the event. See the table below for a full overview of the current webhook notifications events:

Event	Description
paymentIntent.created	When the processing of your API call has started in the Salesforce environment.
paymentIntent.processed	When the processing of your API call has finished successfully. Note: this does not mean that the payment has been collected!
paymentIntent.in_review	When the processing of your API call has stalled and manual intervention from Salesforce side has been requested. Note: this will not stop the customer from completing the payment flow!
paymentIntent.failed	When the processing of your API call has failed and needs to be handled in the Salesforce environment. Note: this will not stop the customer from completing the payment flow!
installment.created	When an Installment (expected one-time payment) is created.
installment.status_change	If the status of the One Time Payment (Installment record in Salesforce) changes, either by an update from a PSP or from within Salesforce.

For more information on notifications, please visit the webhook section in the API Reference.

APIv2: Updated GET /PaymentIntent response and added GET /Installment endpoint

Before, the response to a GET request on the /PaymentIntent endpoint returned a PaymentIntent object with a detailed OneTime object, but not a PaymentMethod object similar to the structure in the request. This made the response both confusing and inconsistent since the PaymentMethod was included in the OneTime object as a string instead of the original object. Also, for other objects like Contact, Account and Recurring we did not pass this much detail.

Now, the response to a GET request on /PaymentIntent contains the original PaymentMethod object and a reduced OneTime object, similar to the other objects.

    "OneTime": {
            "Url": "/services/data/v48.0/sobjects/cpm__Installment__c/a081j000003t0uJAAQ",
            "Type": "cpm__Installment__c",
            "Id": "a081j000003t0uJAAQ",
            "Status": "Pending"
        }

However, to still offer the same richness of information in the API, the Id in the OneTime object can be used to query the /Installment endpoint. This returns detailed data from the Installment in Salesforce that was created based on the OneTime in the API call.

    {
        "Url": "/services/data/v48.0/sobjects/cpm__Installment__c/a081j000003t0uJAAQ",
        "Type": "cpm__Installment__c",
        "Id": "a081j000003t0uJAAQ",
        "Target": "Account NL",
        "Status": "Pending",
        "RecordTypeName": "Receivable",
        "Payments": [],
        "PaymentProcessor": "DummyExtension-PSP",
        "PaymentMethod": "ideal",
        "PaymentIntentId": "pi_18hgjqq7ox5i1u8tf",
        "AmountOpen": 1.25,
        "Amount": 1.25
    }

For more information on the PaymentIntent and Installment endpoints, please visit the API Reference

APIv2: Dates in SalesforceFields object for recurring not accepted

Issue: When a date in a dateformat like “2020-12-12” was passed in a SalesforceFields block as part of a Recurring object, an error was returned.

Solution: The API now properly handles non-string formats in the SalesforceFields block in the Recurring object.

APIv2: Empty values in required parameters are detected

Issue: It was possible to send empty string values for required parameters. This leads to, for instance, creation of recurring donations without a payment profile and mandate, which are normally required.

Solution: We have updated our implementation to not allow empty string values for required parameters.

APIv2: Error code '020' moved to '200'

When the api is not called succesfully, you will receive an HTTP Status Code describing the error. In the the body of the response additional information from FinDock is included in the following structure:

    {
        "Errors": [
            {
                "error_message": "Invalid data: the supplied data is incorrect",
                "error_code": "200"
            }
        ]
    }

The FinDock the case of invalid data the HTTP errorcde is always a 422 and the FinDock errorcode is updated from 020 to 200. This gives us room to add additional errorcodes in the 2xx range for specific invalid data errors. In this release this is implemented for the IBAN and Bank Account / Sort Code validation.

For more information on the Error and Response codes, please visit the API Reference.

APIv2: Error message clarification for incorrect processor value

Issue: If an API call includes a processor that is inactive or the processor name is invalid, the 200 error message referred to the payment method being wrong instead of the payment processor.

Solution: The 200 error message now reads:

    {
        "Errors": [
            {
                "error_message": "Unable to process. Processor [VALUE] is not supported or is not active. Check extension configuration in the org.",
                "error_code": "200"
            }
        ]
    }

APIv2: Added sort code validation to the BACS package

For BACS Direct Debit payments initiated through the FinDock Payment API v2, we have added a new sort code & bank account check. The checking is done automatically, so no additional work is needed to take this feature into use.

The validation is done instantaneous. When the validation fails the api will respond with a 400 HTTP error and a specific error code and message attached: 201: Sort code or bank account invalid (BACS Direct Debit schema).

    {
        "Errors": [
            {
                "error_message": "Sortcode and Bank Account are not valid",
                "error_code": "201"
            }
        ]
    }

APIv2: Specific error thrown for invalid IBAN

To make it easier to handle common errors in your app using our APIv2, we have implemented a specific error code when an invalid IBAN is provided in the POST /PaymentIntent message: 202.

This error can - and should - be used to display a specific error to the user in your front-end if possible.

    {
        "Errors": [
            {
                "error_message": "IBAN [VALUE] is not valid",
                "error_code": "202"
            }
        ]
    }

APIv2: New paymentIntent error for missing ID

Issue: If an ID value in a paymentIntent message is missing in Salesforce, there was no specific error message for this type of error.

Solution: If a paymentIntent message contains an ID value for Installment, Contact, Account or Campaign that cannot be found in Salesforce, the Payment API returns the following error, where ‘Record’ is the object type and ‘ID value’ is the value from the message:

    {
        "Errors": [
            {
                "error_message": "[Record] with [ID value] could not be found.",
                "error_code": "200"
            }
        ]
    }

WebHub: Tweaked experience of WebHub connection flow

To improve the WebHub setup experience and align the connection flow with the ProcessingHub, we now:

• End the connection flow on the main WebHub page instead of the Notification Gateway page.
• Open WebHub tile in the same screen as the setup
• Open the ‘Connect with WebHub’ flow in a new tab
• Added a back button to the Notification Gateway tab.

Worldpay extension compatible with APIv2

With this release, the Worldpay for FinDock payment extension is now compatible with Payment API v2, including multi-currency support.

GoCardless for FinDock goes beta

We are very happy to move our GoCardless extension to beta testing.

With our GoCardless integration, you can easily set up BACS Direct Debit processing in a few clicks.

The current version enables you to:

• Connect your account GoCardless account to Salesforce with a few clicks
• Launch a customer onboarding via online flow through GoCardless hosted payment page
• Collect one-time and recurring payments through GoCardless
• Automatically send the required BACS notifications through GoCardless
• Manually enter DDIs and set up one-time and recurring payments in Salesforce
• Issue refunds through GoCardless

We are actively looking for your feedback on what we’ve built, so please do not hesitate to contact us!

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

• Configuring GoCardless for FinDock
• Using GoCardless for FinDock

FinDock Core

New custom object tabs for Installment and Inbound Report

We have added two new custom object tabs - one for Installments and one for Inbound Reports. These new tabs come in handy in many different workflows, including Guided Matching debugging and configuration.

The tabs are implemented through a new permission set and package called ‘FinDock Additional Setup.' This new package is selected for installation by default but is not mandatory. It is an unmanaged component, so organizations can modify the associated settings if needed.

We are rolling this out as a separate package to avoid potential conflicts with orgs that may already have added custom object tabs for the Installments or Inbound Reports objects. Please go to the FinDock Installer and install the new package.

Once installed, your org admin needs to add the permission set ‘FinDock Additional Setup’ to end users (and/or admins) who also have the primary FinDock Core permissions set ‘PaymentHub Operations’. When you want the new tabs available in the FinDock you can attach them via the Salesforce setup. Then the new tabs are automatically visible for users who have the new permission set.

CODA: Reworked reconciliation and improved extensibility of logic

Based on feedback of partners we have reworked our CODA solution. We have:

• Moved the parsing logic from the ProcessingHub to Guided Matching
• Updated the CODA specific parsing to ignore ‘parent’ Transactions of Type 2 while only storing the ‘child’ Transactions to prevent duplicate records

By moving the parsing logic to Guided Matching, we hope to achieve the following:

• Increased transparency of what is parsed from the CODA file and how.
• Increased ability to debug by showing where in the process an error occurred.
• Increased extensibility of parsing logic, to handle bank & customer specific requirements - especially around unstructured communication.

To make it easier to extending CODA reconciliation with Guided Matching logic beyond Regex rules, we have also introduced a ‘Fixed Width rule' specifically for Fixed-Width files, like CODA. Check out our recent blog post to learn more about the complexities of CODA files and how FinDock handles them for you automatically.

For more information about reconciling CODA files with FinDock, please see our new CODA article.

For more information about Fixed-Width parsing with Guided Matching, please see Guided Matching rule types.

Guided Matching: Managed rules for specific file types

In this release, we are expanding Guided Matching to support matching on the Transaction object with pre-shipped rules for specific file types. These Guided Matching managed rules will be linked to the file type, not a target. This expansion does not impact existing Guided Matching functionality or rules.

The first application of this new capability is a new pre-shipped managed rules set for the CODA file type. For further information about this and other Guided Matching flows, please see our updated article What is Guided Matching?

Guided Matching: New extraction rule type - Fixed Width Extract rule

We have added a powerful new extraction rule to our Guided Matching rule types, the Fixed Width Extract rule. This rule allows you to extract values from any Transaction or Inbound Report field based on the position of the value in the field. You can use this rule for just about anything - extract IBANs, amounts, dates, and so on.

For details on how to set up a Fixed Width Extract rule, please see Guided Matching rule types.

Guided Matching: Salesforce query limit

Issue: Salesforce has a per-transaction governor limit of 50,000 for total number of records retrieved by SOQL queries. This limit applies to the Guided Matching Query rule type, and if the limit was exceeded, Guided Matching could not recognize the error. This would result in the Transaction or Inbound Report records remaining in ‘Processing’ state without a clear error message.

Solution: The Guided Matching Query rule type now explicitly checks if the query returns more records than allowed by the Salesforce limit with the addition of LIMIT [Remaining Rows] to each generated query. If the number returned equals Remaining Rows, it is assumed that the governor limit has been exceeded and the Transaction or Inbound Report records are set to Failed with a clear error message indicating the query limit was exceeded.

Guided Matching: Formula field recalculation

A new rule-level advanced feature called Update And Refresh Before Processing has been introduced in Guided Matching. If this setting is checked for a certain rule, the current state of all transaction or inbound report records within the scope of the Guided Matching job (or the record in Guided Review) is updated to the database and then re-queried before processing the rule.

This means that all formula fields can be trusted to be up-to-date for further processing of the given rule, including entry criteria. It also means that workflow rules, processes, flows or Apex triggers may be triggered. This significantly increases the use cases that can be solved with Guided Matching.

Using this feature introduces a new event that triggers Salesforce customizations, including workflows, Apex triggers and processes. Please take this into consideration and make sure that the new trigger does not lead unintended consequences.

This feature replaces the “Guided Matching: Recalculate formulas after every rule” which was introduced in the November '20 release and later retracted.

Guided Matching: New advanced settings for Create Record rule type

Issue: When Guided Matching runs jobs in parallel, if those jobs include Create Record rules, duplicate records, such as duplicate accounts, could be created.

Solution: A new rule-level advanced feature called Upsert Field has been introduced in Guided Matching for the Create Record rule type for Record, Contact and Installment. If a field is selected, the rule will not do an insert operation, but an upsert operation using the selected field as the key. Please refer to the Salesforce developer documentation for more information about the upsert operation and what kind of fields can be used.

Use this feature if you want to avoid any chance of duplicate records being created. A deduplication approach using a query rule type to first find existing records and then only create if not found catches most duplication scenarios. However, this approach cannot 100% guarantee no duplications because of the parallel processing characteristics of Guided Matching.

Guided Matching: Multiple update operations

Issue: In situations where multiple Transaction or Inbound Report records were matched against the same Contact, Campaign, Campaign Member or any other standard or custom object, and then an Update Record rule was performed on the same object, the system could fail. The resulting error message was: System.ListException: Duplicate id in list.

Solution: In situations where this occurs, we now check if there are update conflicts or not. If there are no update conflicts, in other words, all Transaction or Inbound Report updates rules want the same change in the related object, the update is performed without error. If there is an update conflict, only the related records are failed gracefully with a clear error message.

Deploy Config error for identical target names

Issue: Our team identified a bug in how Deploy Config handled target names that are identical, but for different processors. For example, if you had two payment processors each with the target name “Main,” the Deploy Config process would fail with an error: “Duplicate picklist value main.”

Solution: We updated the Deploy Config functionality so that if identical target names are encountered, a specific error message is shown for this issue. The message now reads, “Duplicate target names. Unable to deploy picklist values. Please ensure target names are unique.”

Giving Pages (beta): Custom success URLs not working

Issue: Custom success URLs were not being used by Giving Pages due to a bug in our URL handling implementation.

Solution: We’ve fixed our implementation so that custom success URLs are used in the same manner as custom failure URLs.

Scheduled Apex job clean-up

Issue: Over the course of FinDock’s development, schedulable Apex jobs have been used for various purposes. Some of those jobs may no longer be necessary given the latest capabilities of FinDock and Salesforce. In some cases, these old Apex jobs could run into scheduling conflicts where jobs are trying to run in the same timeframe, leading to data quality issues.

Solution: The RefreshSchedule Apex job was already deprecated, and with this release, we are adding to the depreciated list both MessageSchedule and MessageScheduleInbound. These jobs will no longer be triggered nor will they be automatically reschedule.

In existing orgs where the jobs are currently scheduled, you should manually remove them from the Salesforce Apex Classes schedule. For further information about Apex scheduling and best practices, please see our updated article Configuring FinDock Core.

ProcessingHub

Heroku stack (OS) upgrade

All our ProcessingHub pods and WebHub instances will be upgraded to the Heroku-20 stack. A stack is an operating system image that is curated and maintained by Heroku. This is purely an infrastructure upgrade and is implemented automatically.

Duplicate mandate error in Direct Debit run

Issue: If a payment schedule includes two instalments that share a mandate that has been recently updated, the mandate history could be duplicated while processing the payment schedule. This would like to an error due to uniqueness constraints in the processing rules.

Solution: We have updated how mandate history records are handled to avoid this duplication. A primary key is added to the mandate history record and filtered according to that key.

Processinghub Matching performance improvements

Issue: The matching step in large file extraction processes on ProcessingHub was slowing down the extraction process overall.

Solution: We have made adjustments on ProcessingHub which speed up the matching step during file extraction.

Automatic retry on locked row errors when pushing data to Salesforce

Issue: When ProcessingHub is pushing extracted data to e.g. transaction sets in Salesforce, it may run into locked row errors (UNABLE_TO_LOCK_ROW). When this happened, you had to manually retry the processing step in ProcessingHub Manager.

Solution: To reduce the instances where manual intervention is needed, we have implemented a new auto retry function using the Salesforce Bulk API. After this release, if a locked row error occurs during the post-extraction process when ProcessingHub is pushing data to Salesforce, ProcessingHub automatically retries pushing the data. The auto retry is attempted up to five times at pre-determined intervals.

SEPA

Adjustment to CBI PAIN.008 file handling

Issue: In our November '20 release, we introduced support for PAIN.008 files that follow the Italian CBI standards. This initial implementation was not quite complete with regards to how the CBI body tag should be supported.

Solution: We’ve adjusted our implementation to correctly handle the body tag according to the CBI standards for PAIN.008 files.

Bollettino Postale: Generalized Guided Matching rule sets

Issue : When processing Bollettino Postale files, we expected certain Bollettino Postale types (123, 451, 674 & 896) to be delivered in a certain file structure. However, we do now see different types coming in the same combined files: for instance types 674 with image in a ZIP. These records failed.

Solution : We no longer expect a certain type to have a certain file structure, but support two Guided matching rulesets based on the two possible file structures: WithImage and WithoutImage , and process the data based on this. This should cover all combinations of types & files.

SIX Saferpay

Permission error with PostFinance PostCard method

Issue: When using SIX Saferpay and the PostFinance PostCard method together with NPSP, a permission error was encountered that prevented the payment from being processed in Salesforce.

Solution: The issue was caused by the unique flow of the PostCard method which ran into missing access to NPSP Recurring Donations. We’ve updated how this particular method is handled in the NPSP context to avoid the additional access rights that would otherwise be needed on Recurring Donations.

Payment Profile creation for payment method TWINT

Issue: When a transaction using the TWINT payment method is processed, a payment profile is created with an empty card number. If the same contact pays a second transaction using TWINT, FinDock would throw an exception error.

Solution: We modified our TWINT implementation so that TWINT payments do not create payment profiles with empty credit card numbers.

Worldpay for FinDock

Improved notification handling for recurring credit card payments

Issue: When a recurring payment credit card payment is set up multiple times for the same customer and card number, but with different card details (e.g. expiration date, cardholder name or address), Worldpay responds with a CONFLICT status on the token in the webhook notification. FinDock did not have a process for handling this CONFLICT status well. This resulted in an exception being thrown with the error message: Attempt to de-reference a null object - TRACE: (cpm).

Solution: We have added new actions for handling CONFLICT status on tokens based on the payload of the message to ensure mandates and payment profiles are created or matched correctly.