Release Notes - May '24

We are happy to present the FinDock May '24 Release!

Important Dates:

• Release to Sandboxes: April 28, 2024
• Release to Production: May 26, 2024

NEW BETA - FinDock for Fundraising

With this release, we are moving the FinDock for Fundraising source connector into beta testing after a successful open pilot. Thanks to everyone who tested our solution and provided feedback! The beta release includes the following enhancements:

• Updated configuration guidance
  • Minimum configuration for Fundraising needs a default designation
  • Page layouts recommendations include adding related list to see installments on a gift transaction
  • Improved guidance around handling the standard Payment Method field and the FinDock Payment Method custom field
• Update Page Builder to make it easier to select the right option when adding RecordType as an additional input field for Personal Details (required for Person Account). The builder now uses a picklist that automatically displays available record types rather than having to enter a record type Id manually.
• Simplified mapping for Bank Statement Description so that this FinDock field is always mapped to the corresponding custom Bank Statement Description field on Fundraising objects. This change ensures the purpose of the bank statement description text remains clear. The standard Description field can be used for other purposes.
• New advanced setting that allows you to disable automatic installment creation when migrating historical donation data.

Recurring payment requests on Gift Commitment Schedule

Issue: As part of pilot testing, we discovered that the advanced payment method setting Generate on Recurring Level did not result in payment reference value on Gift Commitment Schedule as expected.

Solution: We resolved the underlying issues so that the payment request reference is generated and stored on Gift Comment Schedule as expected. This works both for a new Payment Request Generator run, as well as when the Payment Method or Payment Processor are changed on a Gift Commitment Schedule record.

Installment update syncing to Gift Transaction

Issue: When creating a gift transaction with payment request method such as iDEAL, the reference would be generated on the installment as expected, but the reference value did not get updated to the mapped field on the gift transaction.

Solution: We’ve updated the sync trigger to ensure all mapped fields on Gift Transaction records are updated when new Installment records are inserted and then updated.

NEW BETA - FinDock permission set groups

We are continuing in this release with the restructure and redesign of FinDock permissions to make them easier to manage and modify. This work started with the FinDock Integration User permission set group, and now we are adding the following new permission set groups for beta testing:

• FinDock Administrator (beta available now)
• FinDock Service Agent (beta available now)
• FinDock Payments Operations (coming soon)

These groups include several new permission sets. Our new permissions framework combined with new Salesforce features for customizing permissions bring more flexibility, transparency and better security control for our customers.

Package-specific permissions sets to groups

To help with permission set and permission set group management, FinDock now automatically adds package-specific permission sets to the relevant FinDock permission set group.

NEW - Support for Google Tag Manager

We have added integration to Google Tag Manager for tracking performance of Giving Pages and PayLinks. You simply add your Google Tag ID under the general page settings to get started. Keep in mind that you should use either the existing Google Analytics integration or Google Tag Manager. Using both simultaneously may lead to incorrect page metrics.

NEW - Worldpay Corporate Gateway overhaul

This release includes a lot of new capabilities for our Worldpay Corporate Gateway (aka Worldwide Payments Gateway) extension. See below for details.

Core

Guided Matching general Salesforce API updates

Issue: Some Guided Matching rule types may run into system errors due to the Salesforce API version used by FinDock Apex classes which did not support the latest Salesforce standard features and objects.

Solution: We have updated all Guide Matching framework and rule classes to use the latest Salesforce API version. These updates do not require any changes to Guided Matching setups.

Installment eligibility check for FinDock Standalone

Issue: When FinDock is the source for payment data (FinDock Standalone), the installment eligibility check in the payment schedule prepare phase did not automatically include the state of the related mandate or payment profile. This could result in installments being selected for collection even if the related mandate or payment profile is inactive.

Solution: We have updated the eligibility check to require mandates and payment profiles to be active when FinDock is the source. This behavior is now the same as with other sources.

ProcessingHub

SFTP file handling update for Sweden

Issue: Files fetched from Bankgirot through the automated handling service may not picked up by ProcessingHub, leading to potential gaps in processing for Swedish payments.

Solution: The issue was caused by the backend transfer logic FinDock uses for handling files fetched from Bankgirot. This has now been resolved so that files from Bankgirot are picked up by ProcessingHub as expected.

BGMax files with images

BGMax files may include scans of payment slips as TIFF images. These can be helpful in the reconciliation process, so we have added support for retaining these images as part of the BGMax extraction process. FinDock splits multi-page image files and attaches each to the related Transaction record based on the image metadata.

In addition, FinDock can convert the images to PNG format so they can be previewed in Salesforce. This is controlled by a new Image Option setting on FinDock for Sweden targets where you can choose to just keep originals, convert, or both.

Camt.053 processing extended to Norway and Sweden

Prior to this release, camt.053 file processing required the SEPA payment extension and a SEPA target. However, in non-SEPA countries Norway and Sweden, camt.053 statements may also be used for reconciliation.

To support this option for our Nordic customers who do not need to process SEPA payments, we are adding support for camt.053 (and camt.054) processing to the Nordic Payments scope. Targets for AvtaleGiro and Autogiro direct debit get additional settings that enable the new file processing.

Total IN parsing and matching improvements

Issue: Payer information can be present in a Total IN file in more than one record location. The automatic matching provided by FinDock supported a single record structure for payer information, which meant some relevant information was not extracted, requiring custom Guided Matching rules.

Solution: We have expanded our out-of-the-box parsing and Guided Matching rules for Total IN files to handle payer information that is in Payment sender records and now also Sender account record locations. Automatic matching prioritizes Payment sender in the unlikely event information is available in both locations.

E-mandates (PILOT)

Redirect for abandoned sign up

Issue: If a payer abandons the e-mandate signup flow when using the BankID same-device option, FinDock showed a 405 error from WebHub instead of redirecting the payer to a specific failure URL.

Solution : We fixed the issue so that the payer is redirected to the failure URL set in the payment intent message as expected.

Access PaySuite (SmartDebit)

DDICA message handling

Issue: A ProcessingHub component for DDICA messages was missed in the process handling update for our March '24 release, leading to blocked processes.

Solution: The intended updates have now been applied to DDICA message processing so that they are handled the same ways as other SmartDebit reports and messages.

Autogiro

Mandate file format for bank account

Issue: Mandate files for transaction code 04 (TK04) did not use the required value format for the payer's bank account number, leading to the mandate being rejected.

Solution: We have corrected the Autogiro mandate file generator to present the payer’s bank account number in accordance with the Autogiro mandate file specification.

Online payment validation update

For Autogiro direct debit payments set up through Giving Pages, PayLinks and other Payment API front-end implementations, FinDock automatically checks if the entered values for required parameters conform to the expected format.

With this release, we've improved the handling of incorrect civic identity number (ssn), clearing number (branchCode) and bank account (bankAccount) for Giving Pages. Failures are now shown directly in the form, rather than causing a redirect to the failure URL, allowing a payer to fix them and continue their payment.

AvtaleGiro

New MPS endpoints

In preparation for new endpoints announced by Mastercard Payment Services (MPS), we added the new IP addresses to the FinDock for Norway package.

The new addresses are used by default for new targets. For existing targets, you can activate them through a new toggle on the target setup once MPS informs you of your account migration.

MPS integration upgrade

As part of an ongoing environment migration that will be completed this year, Mastercard Payment Services is discontinuing the integration methods FinDock currently uses to set up new payments.

With this release, we are moving to the new integration framework from MPS. All changes are on the FinDock backend, so this upgrade does not require actions from FinDock customers.

SEPA/SEDA

CBI version update

We have updated FinDock to use the latest CBI version for file generation (pain.008) and parsing (pain.002).

Customers in Italy whose banks have not yet switched to the latest CBI version can revert to the previous version by disabling the Use Latest XML Version in their target settings. The toggle is on for new targets by default, but off for targets configured prior to this release.

Swish pilot updates

Thanks to everyone who has provided feedback on our Swish integration. We continue to work on improving the implementation. The pilot continues in this release with several updates:

• New permission set for integration user
• Inline help and guidance improvements
• Icon updates
• Currency set to SEK for notifications from Swish
• Payment Transaction Id captured via paymentReference notification

Vipps

Updating payment status based on ledger entries

Issue: In certain scenarios, FinDock may skip a ledger date, resulting in the status of paid installments from that day not being updated to Collected.

Solution: The issue was caused by how FinDock handles closed ledger dates and checking ledgers for the next date to start processing. This has now be modified to ensure FinDock does not miss ledger entries on any given date.

Worldpay Corporate Gateway

Multi-merchant support

We are happy to announce that our Worldpay Corporate Gateway payment extension now supports multi-merchant accounts. If you have a Worldpay account with multiple merchant codes, you can add each of your codes as a target in FinDock to process payments for that specific code.

The new multi-merchant support can also be used with Worldpay MOTO payments through the FinDock Payments component.

Expanded card reuse for MOTO payments

Prior to this release, the FinDock Payments component would only display cards for a specific target (tied to a Worldpay merchant code). For Worldpay multi-merchant setups where multiple targets are used across multiple Worldpay accounts, you can now select a card from any target for an account group.

This is enabled through a new Worldpay Account Group Name setting on Worldpay targets. If you have multiple targets and accounts, you add your Worldpay admin code or a unique name of your own making to each target (merchant code) of the account to allow card reuse across those targets.

As part of this development, we have also simplified the target selection logic for MOTO payments. Now the FinDock Payments component will always use either the default target from the component settings or the targets passed to the component as a variable in a custom flow. If the installment has a defined target, this is overwritten by the target used for the MOTO payment. We also now enforce a default target in the component settings, so there is no longer a fallback to a processor level default target.

Shopper Id enhancement for multi-merchant support and card updating

To support collecting card payments from the same payer across multiple Worldpay merchant codes, we are moving the Worldpay Shopper Id storage point from the wpayc__WorldPay_ShopperId__c field on Contact to a new cpm__External_Customer_Id__c field on Mandate.

This change only impacts new payments and new migrations of Worldpay data to FinDock. Existing recurring payments where the Shopper Id is on Contact can continue to be collected as before. Running FinDock Data Quality on new payment schedules and installments will check for both old and new Shopper Id locations.

With this change, FinDock can also better support card updates for payers. Changes to the details of an existing card through FinDock MOTO trigger a new authorization token with Worldpay.

Zero authorization for MOTO payments

For recurring MOTO card payments set up through the FinDock Payments component, FinDock can now use the zero authentication (0-auth) flow from Worldpay. This flow allows you to catch incorrect payer information before actually trying to capture the payment.

When the Worldpay 0-auth flow is not used, the initial tokenization can succeed with incorrect payer details. However, the payment collection itself will fail when you would, for instance, run a payment schedule for recurring payments in the future. That is harder to resolve than catching the incorrect details while an agent is working with the payer to set up the MOTO payment.

To use 0-auth, you need to contact Worldpay and ask them to enable it for your merchant account. Once enabled, activate the new 0-auth option on your target(s) in FinDock.

Zero authorization for online payments

As part of our Worldpay development around MOTO payments announced in our last release, we introduced support for the zero authorization. This option for recurring payments set up through the Payment API is now generally available to all customers.

Note that zero authorization needs to first be enabled for your Worldpay account, so please reach out to Worldpay before you can start using the option with FinDock.