Release Notes November '20

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

Important Dates:

• Release to sandboxes: November 01, 2020
• Release webinar: November 06, 2020
• Release to production: November 15, 2020

Progress continues with our new Enhanced Online Payment Experience. We are adding more payment extensions to beta with the November release, as well as opening up FinDock Giving Pages.

We have several other announcements as well, such as new payment methods for SIX Saferpay and a completely re-factored Adyen package. As well as important enhancements and bug fixes.

Enhanced Online Payment Experience (beta)

New packages made compatible with APIv2

In this release, we are making the following packages available for the Enhanced Online Payment Experience:

• Axerve for FinDock
• SIX Saferpay for FinDock
• Swiss Payments for FinDock
• Adyen for FinDock

APIv2: Added Campaign and Origin to root of API call

Issue: We updated the way in which to pass the Campaign and Origin with a paymentIntent via the API v2 (Beta). Before there were two problems:

1. When a recurring was created through the APIv2 and a Campaign value was passed as the below example, the campaign was not attached to the recurring record dependent on the source.
2. Other use-cases like one-time payments were supported, but were inconsistent with the handling of other fields passed in the SalesforceFields object since "hidden" logic was applied to only the cpm_ _campaign_ _c and cpm_ _origin_ _c fields.

     "SalesforceFields": {
            "cpm__campaign__c": "7012p000001HMs2AAG"
        },

Solution: To increase consistency and clarity in the APIv2 and solve the issue with campaigns for Recurring donations with NPSP, we have added a CampaignId and Origin field to the root of the POST PaymentIntent request body. Values passed here will be copied to the Recurring and or Installment objects, regardless of what source is used.

Example paymentIntent request:

    {
        "FailureURL": "https://example.com/failure",
        "SuccessURL": "https://example.com/success",
        "Payer": {
            "Contact": {
                "SalesforceFields": {
                    "Email": "eric@johnsontest.com",
                    "FirstName": "Eric",
                    "LastName": "Johnson"
                }
            }
        },
        "PaymentMethod": {
            "Name": "CreditCard",
            "Parameters": {
                "locale": null
            }
        },
        "Recurring": {
            "Amount": 15,
            "Frequency": "Monthly",
            "StartDate": "2020-10-14"
        },
        "CampaignId":"7013X000001mAZbQAM",
        "Origin" : "Webform at findock.com",
    }

API v2: Improved names and images for user-facing parameters

When you perform a GET on /PaymentMethods in API v2, some parameters return an enum of possible values. For the user-facing iDEAL issuer and Creditcard brand parameters, this list of possible values has been reworked to return a list of objects.

Each object (issuer or brand) contains:

• the value that FinDock expects in the API call to /PaymentIntent
• a friendly label that can be shown to the end-user
• an image that can be shown next to the label (e.g. bank logo)

{
        "Required": false,
        "Name": "issuer",
        "Enum": [
            {
                "image": {
                    "svg": "https://images.findock.com/issuers/abnamro/issuer.svg"
                },
                "label": "ABN AMRO",
                "value": "abnamro"
            },
            {
                "image": {
                    "svg": "https://images.findock.com/issuers/asnbank/issuer.svg"
                },
                "label": "ASN Bank",
                "value": "asnbank"
            }
        ],
        "Description": "The issueing bank. Use this parameter to skip the bank selection screen of the PSP and send the user directly to their bank's authorization environment.",
        "DataType": "Enum"
    }

This enables you to dynamically show a list of options to the payer based on the GET /PaymentMethods response, instead of hard-coding options and values passed in the API call. That brings two main benefits: (1) when a PSP and FinDock add an issuer or brand, you do not need to update your web form, and (2) you do not need to map the API values to user-friendly names and images yourself.

You can still choose to not use the labels and images provided by FinDock, and instead create and serve your own.

For more information, please visit our API v2 Reference or perform a GET on /PaymentMethods to see a full list of options.

API v2: Return http code 422 instead of 400 where applicable

Issue : When receiving a valid JSON through the /PaymentIntent endpoint that contains incorrect data (such as a non-existing Campaign), FinDock would return HTTP error code 400 (Bad Request). This led to call retries using the same message.

Solution : FinDock now returns error code 422 (Unprocessable Entity) when the syntax of the message is valid, but the message cannot be processed because, for example, it contains incorrect data.

APIv2: Installment status set to Pending on redirect

When the APIv2 is called with a paymentIntent, an installment is created in FinDock. The status of this installment is now set to Pending when the customer is redirected to the payment page of the payment processor.

When the customer has completed the payment journey, the processor sends a webhook notification to FinDock. Typically this notification changes the installment status from Pending to, for example, Collected.

New Description parameter for Payment API

We’ve added a new Description parameter to the Payment API for one-time and recurring direct debits, as well as for Buckaroo iDEAL and SIX Saferpay PostFinance PostCard payment methods. For further information about available parameters for specific processors and payment methods, please visit our API Reference Guide.

This new feature replaces the need to set the payment description through Salesforce fields or with the field cpm__Bank_Statement_Description__c for Installment and the description field for Recurring as defined by the source.

To be able to store descriptions on NPSP recurring donations, we’ve added custom field Bank Statement Description to Recurring Donation and Opportunity. NPSP mapping between these two fields is also automatically added.

For new customers, the Opportunity field Bank Statement Description is automatically mapped to the Installment field Bank Statement Description in the Opportunity Installment field mapper.

Existing customers already have a Name to Bank Statement Description in the Opportunity Installment field mapper. This can be changed to use the new Description parameter, but this is not required.

Giving Pages goes beta

We are excited to open up FinDock Giving Pages for beta testing. Several customers have been involved with pilot testing, so we are including here a list of changes that we made for the beta release.

You can access Pages through the Giving Pages setup tile in the FinDock Setup, or the Pages Salesforce tab in the FinDock app. Start your journey here!

Redesigned payment form

To further improve donor experience with Giving Pages, we have redesigned the payment form with a clean, more modern look and feel.

Improved Page builder ease-of-use

To make it even easier to create and update Giving pages, we have implemented several improvements to the Page Builder , including (but not limited to):

• Added a sidebar with the structure of the page to easier find and edit sections, rows, columns & components.
• Updated the Payment Form settings to reflect the pages of the form and simplified the configuration
• Added a true preview of the payment form, that reflects the actual look & feel of the form based on the current configuration.
• Improved the section / column / row appearance settings.

Page title cannot be set

Issue : The page title under the page settings (metadata) did not appear in the rendered Giving Page.

Solution : We fixed the underlying issue so that the page title you provide now correctly shows in the web browser.

Lowercase, case sensitive URLs and domains

Issue : It was possible to create a page URL with capital letters, which made the URL case-sensitive. For example, browsing to <https://my-page.givingpage.org/specific-campaign> would not work when the page name was “Specific Campaign.” Only the URL with capitalization would work, <https://my-page.givingpage.org/Specific-Campaign>.

Solution: All page domains and URLs are now completely lowercase. Capitalization in the page name is also checked and changed to lowercase.

Added check to ensure Content Deliveries feature is enabled

Issue : FinDock Giving Pages makes use of the Salesforce Content Deliveries feature. If this feature is not enabled in the org, Giving Pages will not load properly. There was no feedback about this requirement in the Pages Manager or Builder.

Solution: We added a check for Content Deliveries in Pages Manager. If the feature is not enabled, we display an error message with instructions how to enable Content Deliveries in Salesforce.

Enhanced amounts checking

To avoid errors and bad data in Salesforce, FinDock now validates amounts entered in the ‘Other amount' field. For instance, negative amounts or amounts with multiple decimals are blocked.

Improved loading speed of payment methods

Issue: The payment method selection step (3rd step) of a Giving Page often took a few seconds to load the payment methods, which was a noticeable pause in the donor experience.

Solution: The payment methods are now pre-loaded so they appear immediately with the donor moves to the payment method selection step.

New description parameter for direct debit payments

We have included the option to add a Description to direct debit payment methods in Giving Pages.

You can set a standard description in the Payment Form Settings under Payment Methods → Configure Payment Methods.

New Origin field

An Origin value can now be set per Giving Page. This value can be used to indicate the source of a donation, for instance Online webform X, enabling the possibility to trigger relevant follow-up business logic.

The value is copied to the cpm__Origin__c field on the Inbound Report object.

For one-time payments, the value is picked up and copied to the cpm__Origin__c field on Installment.

FinDock Core

Missing mandates for one-time direct debits

Issue: In the past the FinDock Payment API could not be used for one-time direct debit payments. The work around was to make it a recurring payment with start and end times set to be close to each other. Now the Payment API can be used for one-time direct debit payments. The root issue was that a bug was preventing mandate creation for one-time direct debits using our Buckaroo, Mollie and SEPA packages.

Solution: We identified and fixed the bug in the affected packages. Mandates are now created as expected for one-time direct debits.

Guided Matching: Corrected Update Record Rule setting text

Issue: In the settings for the Update Record Rule, the entry criteria text said “if empty” instead of the intended “if not empty.”.

Solution: Update Record rule entry criteria now says “if not empty.”. This was also fixed for the Update Campaign Member rule and Normalize rule the “if empty” setting was hidden. Now they explicitly say “if not empty.”.

Guided Matching: Fixed all records in a job failing when one record failed

Issue: When a Guided Matching job failed on a DML statement, all records in scope of the job were marked as failed instead of just the records that actually failed. This meant that a DML exception, e.g. a validation rule in Salesforce, for record A could lead to record B failing as well, just because record B was in the same job as record A.

Solution: We have fixed this by moving from DML statements to Database Class Methods. This gives a more fine-grained control on the partial success of records in the scope of particular job. We can isolate failed records and continue with the job. Now only failed records are marked as failed instead of all records in the job. However, the following exceptions will still lead to the entire job failing:

• A DML exception on creating a Payment record in the Process Installment rule.
• A DML exception on creating a NPSP Payment or updating the Installment in the Manage Source rule.

Guided Matching: Fixed issues caused by multiple clicks in Guided Review

Issue: There were several scenarios in which a Transaction or Inbound Report record could be processed multiple times in parallel causing unwanted behavior, such as double installments being created. This could happen, for example, by clicking the Save & Continue button, and then clicking it again after the browser refreshed.

Solution: Each Guided Matching operation, job or user interface, now starts with locking the underlying Transaction or Inbound Report record. This fundamentally means that it is impossible for multiple processes to work on the same record at the same time.

Guided Matching: Recalculate formulas after every rule

Issue: When using formula fields in Guided Matching rules, the formula values would only be calculated at the very end of the last Guided Matching rule. This meant that the value of the formula field could not be used during the Guided Matching process.

Solution: After every rule is executed, formula fields are recalculated so the values can be used by the next rules. No setup is required to enable this change. This change also significantly increases what can be done using Guided Matching. Formula fields can now be used in Guided Matching rules and can be trusted to be up to date with previous rule results.

Guided Matching: Replaced process icon with Retry & Continue button

Issue: For Transaction and Inbound Report records with status 'Failed,’ a retry button was shown in the Guided Review component. However, this button icon was not very clear, causing users to use the Retry All Button instead, triggering unintended processing logic.

Solution: We have replaced the retry icon with a Retry & Continue button. In most retry scenarios, this button should be used and not the Retry All button. Because our previous retry solution was not very clear, some users may have learned to use the Retry All button for failed Transaction or Inbound Report records. This still works, but it leads to retrying all rules from the top and not just the failed rule and those that follow it. Starting from the top should be the exception, so we encourage users to click Retry & Continue button as the standard procedure.

Guided Matching: Incorrect display of available fields in field mapper

Issue: In Guided Matching, the Create Record rule only shows fields in the field mapping that can be updated, which is expected. The Update Record and Update Campaign Member rules, however, show all fields, so also fields that cannot be updated such as formula fields. In addition, the Create Record rule does not show master-detail fields in the field mapping if the master-detail is not reparentable.

Solution: The Create Record, Create Payment Profile, Create Contact, Create Installment, Update Record, Update Campaign Member rules now only show fields in the field mapping that are either updateable or creatable. This includes not reparentable master-detail fields.

Inbound Report access missing from PaymentHub Integration Base permission set

Issue: The FinDock permission set PaymentHub Integration Base did not grant users access to the Inbound Report object. This lead to the API v2 failing in cases where the API authenticates with a user that only has this FinDock permission set assigned (best practice).

Solution : We have added completed Inbound Report access permissions to the FinDock permission set PaymentHub Integration Base. This permission set now grants the user full CRUD rights, including View and Modify All, as well as full field level security.

FinDock ProcessingHub

Incorrect uniqueness check for CAMT.054

Issue: Our CAMT.054 processing only checked for uniqueness using the file identifier. However, CAMT.054 files can share the same identifier across several targets. This can lead to duplication errors when processing CAMT.054 files.

Solution: We have updated CAMT.054 processing to check uniqueness by combining both the file identifier and target (IBAN). This ensures all unique files are processed and not marked as duplicates if the file identifier (CAMT statement Id) is the same.

UTF-8 handling error with N43 files

Issue: UTF-8 encoded special characters in N43 files, such as ó, could result in file processes getting stuck in Running state on ProcessingHub.

Solution: The issue was caused by how ProcessingHub was interpreting special characters. We fixed the bug so that UTF8-encoded special characters are interpreted correctly as expected.

Adyen for FinDock

Renewed Adyen for FinDock package

The Adyen for FinDock payment extension has been completely re-done. The new extension is refactored to use Adyen Pay by Link. As a result, configuration is easier, you get access to more payment methods, and you can create advanced, stylized payment pages.

The new Adyen for FinDock implementation is available for both the Classic and Enhanced Online Payment Experience in FinDock. With the November release, the Adyen package for Classic is ready for general availability. The package for the new Enhanced Online Payment Experience is for beta testing.

Gift Aid

GiftAid: Create PaymentHub file record with details about GiftAid submission

To increase transparency and enable additional controls, the details about a Gift Aid submission to HMRC are now stored on a PaymentHub File record. The record includes:

• The payment schedule used to create the file
• The related onstallment records
• The number of claimed and reversed records
• The sums of amount claimed and amount reversed
• The actual file that was createdand

NPSP

Extra Opportunity payment creation

Issue: When an Opportunity is changed to closed won instead of changing the related Installment to collected, NPSP marks any open payments for that Opportunity as paid. FinDock did not recognize this state change by NPSP and instead created new paid payment on the related Opportunity.

Solution: When an Opportunity is manually changed to closed won, FinDock correctly sums up already paid payments and then changes the status of unpaid payments on the related Opportunity to paid.

Buckaroo

New Description parameter for Buckaroo iDEAL

It is now possible to set a (optional) Description value when starting a payment with the Payment APIv2. This description will show up in the Bank's iDEAL payment authorization page. Previously this would show the less user friendly paymentIntentId.

The new parameter is also available through Giving Pages.

Redsys for FinDock

Updated Redsys error code handling

Issue: Redsys can response to API calls with two different codes. The Codigo field is for technical error responses. The Responsecode is for business responses. FinDock did not evaluate Responsecode which could lead to incorrect installment status in ProcessingHub.

Solution: ProcessingHub now takes both fields into consideration when setting the status of an installment. If the CODIGO field value is 0, ProcessingHub check the Ds_Response field value. Pending installments are set to collected if the value is between 0000 and 0099. When any other value, the installment is set to failed and the reports reason is prefixed with the Codigo or Responsecode value.

SEPA

SDD PAIN.008 file based on CBI standards

About three million companies in Italy use CBI standards. Among other functions, the CBI standards describe the SDD file format including the CBI additions to the ISO 20022 PAIN.008 standard. FinDock now supports the creation of SDD PAIN.008 files in the format prescribed by CBI.

In combination with the PAIN.002 CBI file processing, FinDock now support the full CBI described SDD standards with this enhancement.

SIX Saferpay

New PostFinance payment methods

With this release, we have added PostFinance E-Finance & PostCard as new payment methods supported by SIX Saferpay for FinDock payment extension. They are available in both classic and enhanced versions of the extension.

Please note that both payment methods have to be added to your account by SIX Saferpay. You can ask to do so by making a support ticket with SIX from your account.

Worldpay

Transaction Id missing on payment record

Issue: When using payment schedules for Worldpay payments, the transaction Id from Worldpay was only stored on installment records instead of both installment and payment records as expected.

Solution: The Worldpay transaction Id is now stored on both installment (cpm__Installment__c.cpm__Payment_Transaction__ID__c) and payment (cpm__Installment__c.cpm__Payment_Transaction__ID__) records when using payment schedules.