Release Notes - July '21

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

Important Dates:

• Release to Sandboxes: July 04, 2021
• Release to Production: July 18, 2021

FinDock PayLinks goes GA

Thanks to all our customers using the beta release of FinDock PayLinks, we are now ready to move our new add-on feature to General Availability. As part of our GA release, we are introducing a major expansion in our PayLinks capability with support multiple PayLinks pages. In addition, we have further improved the design of our Payment Form.

Support for multiple pages

With this release, FinDock PayLinks now supports using multiple pages. We recommend using one PayLinks page for simplicity, but additional pages can be created, for example, to handle regional localization (language, payment methods, currency, etc.).

Creating a new page permanently changes PayLinks by

• Adding Page Manager to PayLinks configuration
• Requiring the PayLinks Page field on Installment

Once you create a new page, please ensure the PayLinks Page field on installments uses the correct page. You can do this using Salesforce automation to set the value or by manually setting the value.

For more information, see Configuring FinDock PayLinks.

Redesigned payment method selection experience

We redesigned the Payment Form to make it easier to select payment methods. The improved design is used for both FinDock PayLinks pages and Giving Pages.

Instead of present a simple drop-down list, payers now see a list of buttons with logos representing the payment methods that can be selected. Apart from a better look and feel, this helps payers realize there are different ways to pay.

The default payment method as configured in the Page Builder for Giving Pages and PayLinks is still pre-selected.

New PayLinks Builder introduction

We've added a new welcome pop-up and introduction to the PayLinks Page Builder to help first time users. You can skip the introduction and go straight to the Builder or click through the guided introduction of the Builder components.

Mandate Schedules

Mandates, the authorizations you receive from payers that allow you to collect payment from them, are an essential feature of FinDock as it enables FinDock to act as a processor for certain direct debit payment methods and scheemes. We are putting the final touches on a major update for mandate schedule management in FinDock.

As part of these updates, we have also written and updated our documentation around mandate handling and mandate schedules, including:

• Introduction to mandate handling
• Using mandate schedules
• New or updated object reference articles for
  • Mandate
  • Mandate Schedule
  • Recurring Mandate Schedule

New Lightning page for Mandate Schedule

The Mandate Schedule object is getting a new Lightning page as the defaul page layout. This new page feature dynamic fields and a Progress Path component to help you process and track the progress of the mandate schedule.

Recurring Mandate Schedule

With this release we introduce a Recurring Mandate Schedule object. This can be used much in the same way as recurring payment schedules, creating a mandate schedule template that generates mandate schedules on a certain frequency over a specified period of time. Recurring mandate schedules can also use for automatic mandate management.

Automated mandate management

We are introducing the same automation capabilities for mandate management as we have for payment collection. As with automatic payment collection, automatic mandate management is a combination of auto-creating and auto-running mandate schedules.

• Auto-create mandate schedules: you can use the auto-create setting on a recurring mandate schedule to automatically create an indefinite number or mandate schedules.
• Auto-run mandate schedules: you can enable auto-run of mandate schedules for a given payment processor and method combination, as well as exclude specific mandate schedules from auto-run.

Other fixes and enhancements

Empty processing date on mandate schedule

Issue: If a mandate schedule was missing a processing date, ProcessingHub would throw an exception instead of putting the schedule status to failed.

Solution: If a mandate schedule does not have a processing date, when the schedule is run, ProcessingHub sets the schedule status to ‘Failed’ and puts the following message in the Last Status Reason field: “Processing Date on Mandate Schedule can't be empty!”

Failed mandate schedule handling update

Issue: If a mandate schedule with status ‘Pending Verification’ is set to ‘Failed,’ this change would start the closing process which should only happen after the mandate schedule is in ‘Verified’ state.

Solution: If a mandate schedule with status ‘Pending Verification’ is set to ‘Failed, the mandate schedule status is now set to ‘End’ state.

Core

Recurring payment schedule preview of run dates

Issue: The start date calculation used for the preview of generated payment schedules, both auto-collect and manual, contained two bugs. First, for daily, the start date was used for auto-collect, even if the calculated start date was in the past. Second, for weekly and monthly, the start date was today for auto-collect, even if the calculated start date was in the future.

Solution: For daily, weekly and monthly, the start date calculation is now as follows: use start date unless it is in the past, in which case use today.

Recurring payment schedule validation for collection date

We have added a new validation rule for recurring payment schedules which ensures the collection dates on generated schedules are in the future. The new rule enforces that value for the field “Run # of Business Days Before Coll. Date” is equal to or greater than 1 if the payment method is Direct Debit and the processor is FinDock (for SEPA, CH-DD, LSV+ or Bacs).

Payment method logo included in /PaymentMethod response

To make dynamic implementation of the FinDock Payment API easier, logos for all possible payment methods are now included in the response to a GET request on the /PaymentMethod endpoint.

This means that you can now build your payment form dynamically, including the payment methods that are shown in a user friendly way, without having to host and code your own logos. For examplse of how these payment method logos can be used, check out the payment forms in FinDock Giving Pages and PayLinks.

Images are included as SVG for easy adjustment:

    "Name": "PaymentHub-Stripe",
    "IsDefault": false,
    "image": {
        "svg": "https://external.findock.com/icon/payment-processors/payment-methods/creditcard.svg"
    }

iDEAL issuer update

Moneyou is no longer an iDEAL issuer, so we have removed this option from FinDock. This change affects the following packages:

• FinDock Core
• Adyen
• Buckaroo
• Mollie

New optional API parameter for Bacs custom mandate reference

We have added a new API parameters to better support customers who use SmartDebit for Bacs payments. The new customMandateReference parameter can be used to override the mandate reference that is automatically generated by FinDock. The parameter value must be unique and have 6-18 alphanumeric characters.

Small amount on Giving Pages for Safari

Issue: In the Safari browser, if a visitor selects the "Other" amount option and enters an amount below 10, clicking Next results in a missing amount error.

Solution: We identified the bug causing this issue in Safari and fixed it so the payment form behaves now as expected.

ProcessingHub

Performance improvement for sync on deleted records

Issue: When very large numbers of records (millions) are deleted in Salesforce, it could take too much time for ProcessingHub to sync all the changes and update its data.

Solution: We made a number of changes to how ProcessingHub handles deleting records. With these changes, large deletion operations are now synced much faster. Based on our internal testing using over one million records, syncing of deleted records is three times faster.

New insights in creation of files

We’ve improved how ProcessingHub handles various files so that it is easier to see which installments are part of which files. This increased transparency enables, for example, additional control workflows.

The details of files posted to Chatter are now stored on a PaymentHub file record. The file record shows:

• The related installment records.
• The sum amount and count of records inside the file.

The new insights are available for:

• SEPA
  • Pain.008
• Bacs
  • Standard 18 charge file
  • SmartDebit charge file
• CH-DD
  • Pain.008
• LSV+
  • Pain.008

Adyen

Improved MOTO notification handling

Issue: Notifications for payments made with Adyen MOTO were misclassified and put into inbound reports as SETUP_AUTHORISATION with status 'Failed.'

Solution: Incoming Adyen MOTO notifications are now handled with inbound reports with subtype MOTO_AUTHORISATION. If a custom Guided Matching rule for MOTO_AUTHORISATION is defined, then the status of inbound reports with this subtype is set to 'New', otherwise it is set to 'Manual.'

Buckaroo

Payment of existing installment

Issue: When making a payment using Buckaroo, if the payment call to the Payment API (v2) included the GUID/ID of an existing installment, FinDock would throw an exception.

Solution: The underlying bug was identified and fixed so that the flow for paying an existing installment woks as expected now.

Stripe

Dynamic description on checkout

Issue: The FinDock integration with Stripe used “Donation” as a hardcoded description value on the Stripe checkout page, which did not fit with some customer use cases.

Solution: We have updated the integration to support Stripe line item name and description parameters. The name default is “Donation” if no name value is passed. The description value is dynamic and mapped to bank statement description. For example, in the following checkout page screenshot:

• line_item.name = “Donation” (default if no value passed)
• line_item.amount = “50.00” (amount)
• line_item.description = “test 123 abc” (cpm__bank_statement_description__c)

Support for Account as primary relation

With this release, the FinDock integration with Stripe supports Account instead of (or in addition to) Contact for the payer primary relation. Please keep in mind that you need to define which primary relation to use for matching if an Inbound Reports with both Account and Contact.

Worldpay

Support for partial refunds

Prior to this release, Worldpay for FinDock did not distinguish between partial and full refunds. Both were handled as a full refund, where the status of the installment would be set to ‘Reversed’ and a negative payment with the full amount created.

Now we distinguish between partial and full refunds. The behavior for full refunds remains the same. For a partial refunds, the status of installment is now set to ‘Partially paid’ and a negative payment with the amount of the partial refund is created.

If a further partial refund is made for the remaining amount, a second negative payment with the refunded amount is created and the installment status is changed to 'Reversed.'