Release Notes - October '21

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

Important Dates:

• Release to Sandboxes: September 26, 2021
• Release to Production: October 10, 2021

New: status.findock.com

Before we dive into the October release content, we'd like to share our new FinDock Status service with you. You can use this site to check the current status of all FinDock system components, see incident details, including release updates and hotfixes (classified as "Planned Maintenance"), as well as status history.

Subscribe to our new service to get email (or Slack) notifications about the latest incident news.

Payment Collection: Auto-collect to GA

With this release Payment Collection: Auto-collect is moving to General Availability. This means that the features are available to all FinDock customers without restrictions and with full support from FinDock.

Collection of recurring payments with FinDock allows for fine-grained control but requires manual and repeated handling of payment schedules. This control is not always needed for more ‘standard’ collection use cases. We want you to be able to collect your payments automatically so you can significantly reduce the need for ongoing payment operations.

With the release of the auto-collect functionality, you're now able to automatically collect all your recurring payments without the need for manual operations.

Payment Collection: Data validation to GA

With this release, Payment Collection: Data validation is moving to General Availability. This means that the features are available to all FinDock customers without restrictions and with full support from FinDock.

In addition, we have added new Data Quality Validation rules to help facility mandate management. We also made updates for SmartDebit payment validation rules.

Data Quality Validation for Mandate and Mandate Schedule

In this release, we are expanding the application of FinDock Data Quality to mandates and mandate schedules. Similar to payment collection where we validate installments and payment schedules, you can now run the data quality component to check that mandates are ready to be processed and mandate schedules have valid values. The new validation rules cover mandate handling for:

• Bacs Direct Debit mandates | FinDock
• Bacs Direct Debit mandates | SmartDebit
• SEPA Direct Debit SEDA mandates | FinDock

Updated data quality rules for SmartDebit

We’ve added an additional rule to the ruleset for SmartDebit that checks Payment Reference values. This is added to accommodate possible differences in the reference value depending on the Mandate ID value. This update includes the following:

• Maximum length of Final Payment Reference = 18 (was 140).
• If length of Mandate Id = 18, then Final Payment Reference must equal Mandate Id.
• If length of Mandate Id < 18, then Final Payment Ref must start with Mandate Id + “-”.
  Example: If Mandate Id = ‘MREF', then valid final pay references would be “MREF-” or “MREF-1234”

Worldpay Business Gateway 350

We are happy to announce that we are adding support for Worldpay Business Gateway 350 (BG350) This includes one-time credit card payments via the paymentIntent api and MOTO. The BG350 support comes in the same Worldpay for FinDock extension package as our existing Wordplay Corporate Gateway integration. However, the two payment services are otherwise independent with their own processor configuration in FinDock and account setup at Worldpay.

Launch of SEPA Credit Transfer Pilot

As some of you may know we've a very long running pilot around SEPA Credit Transfer. With this release our SEPA Credit transfer support has been completely refactored to build a more robust solution for disbursement of payments. The current pilot scope is limited to core functionality and, as normal, limited to specific customers for testing and feedback. If you are interested in participating in the pilot or would otherwise like to discuss your SEPA Credit Transfer needs with us, please do reach out to our team.

Core

Improved Deploy Config stability

The Deploy Config operation is used to deploy FinDock configuration changes to an org. As explained in our FAQ, this operation can fail due to a known Salesforce issue.

To help reduce the failures, we’ve implemented an automatic retry that attempts to restart deployment a certain number of times. Based on our own internal testing this should eliminate almost all failure cases. When deployment still fails, you can retry deployment again as instructed in the FAQ.

Guided Matching: create Installment rule fix in multi-currency orgs

Issue: In multi-currency orgs, the Create Installment rule in Guided Matching fails on Inbound Report, because CurrencyIsoCode was not included in the underlying SOQL query.

Solution: We have updated the rule to include CurrencyIsoCode to the query.

Platform event notification timing change

Issue : In some edgecases, incorrect installment data is sent through webhooks when an installment record is updated. This is caused by the platform events occurring immediately when the data, including status, is not updated yet. The events should instead occur after commit when the data is actually updated.

Solution : We’ve changed the setting for platform events to “Publish after commit” instead of “Publish Immediately” to avoid this timing issue. This change affecting notifications through both v1 and v2 of the Payment API.

Giving Pages: birthdate correction

Issue: Due to an automatic time zone function of Javascript, if the birthdate field was used on the Giving Pages payment form, the date stored in Salesforce was incorrect.

Solution: We identified the source of the problem and fixed it. A birthdate entered by a donor is now stored with the expected value in Salesforce.

Giving Pages: empty field handling

Issue: If a payment form field that is not required is left empty, the empty value (Null) is passed to Salesforce and overrides deduplicated values (i.e. existing values are deleted).

Solution: We identified the bug causing the issue and fixed it so that empty field values are ignored as expected in deduplicated scenarios.

Giving Pages: non-visible API parameters

Issue: If there is only one payment method parameter configured for a Giving Pages page, and that parameter is not visible, the default value of the parameter is not sent to the Payment API.

Solution: We found and fixed the bug causing this issue. All parameters for a page, visible or hidden, are now correctly sent to the Payment API.

Gift Aid

Revamped guidance for admins and Gift Aid managers

We've completed a major overhaul of all our documentation related to Gift Aid. The new knowledge base articles are more extensive and include a great deal of new, enriched information. We hope you find it helpful! The new guidance begins with how Gift Aid works.

Update to Current Fiscal Year custom setting

Issue: When you run the first Gift Aid payment schedule in a given org, the schedule fails for no apparent reason. This was caused by a missing initial record for the Current Fiscal Year custom setting. This initial record needed to be manually created, but we had not provided instructions as part of the Gift Aid extension setup.

Solution: The Current Fiscal Year custom setting is used during the payment schedule process to determine when your current fiscal year started, which in turn is used to calculate installment eligibility. As per HMRC rules, Gift Aid is only relevant from the current fiscal year minus four years (i.e. a total timespan of up to 5 years). Rather than continue to require customers to manually create a custom setting record, with this release we are including post-install actions for the Gift Aid package that automatically create (or update) the first Current Fiscal Year custom setting record.

Buckaroo

FinDock migration and Simple Direct Debit

Issue: When migrating from the Simple Direct Debit payment method to Direct Debit, as part of a FinDock migration, in certain cases recurring payments ran into issues. Depending on the bank of the donor, we saw:

• Initial payment was registered with Buckaroo with StartRecurrent = False. This could lead to the bank registering the related mandate as one-off and not usable for recurring payments.
• Next payments were registered with Buckaroo through the Pay endpoint, not the PayRecurrent endpoint. This also meant that some banks would not allow collecting recurring payments with the related mandate.

Solution: We identified the underlaying causes of these issues and resolved them so that they will not affect migration cases or new FinDock customers. Now StartRecurrent on first payment is set to True for recurring payments, and the PayRecurrent endpoint is used for next payments.

API v1 double notification prevention

Issue: With our Payment API v1 flow for Buckaroo, there was an edge case in which a browser refresh or double-clicking could lead to double payments registered in Buckaroo and double notifications to FinDock.

Solution: We have taken actions to reduce the risk of this happening by disabling the Submit button on the redirect Visualforce page after the page is submitted. We have also adjusted the payer-facing text which should lead to fewer double clicks as well. However, with the API v1 architecture, it is not possible to fully eliminate the possibility of double payments and notifications. Our recommendation is to migrate your Buckaroo integrations to Payment API v2.

GoCardless

Address prefill for hosted payment pages

Four new API parameters have been added for the GoCardless processor with Bacs Direct Debit payment method payment option. These enable you to prefill the address on the GoCardless hosted payment page (HPP). The new parameters are:

• prefilledAddressLine1
• prefilledAddressLine2
• prefilledPostalCode
• prefilledCity

If you already ask a payer/donor to fill in an address on your website’s payment form, you can use these new parameters to improve the payment journey experience. By prefilling, the payer/donor can more easily complete the GoCardless HPP, avoiding the need to enter the same address information twice.

Worldpay

Payment Transaction Id

To aid in reconciliation of Worldpay transactions captured via the Payment API v2, with this release FinDock will store payment Intent Id as the Payment Transaction Id on the initial installment as follows:

• One-time payments: the installment uses payment Intent Id as the Payment Transaction Id
• Recurring payments: the initial installment (created using OneTime block in the payment intent request) uses payment Intent Id as the Payment Transaction Id. Further installments related to the recurring installment use the Payment Transaction Id generated by ProcessingHub as normal.

Prior to this release, installments created via the Payment API v2 did not get a Payment Transaction Id value.