Skip to main content

Release Notes - October '20

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 release to production.

We are happy to present the FinDock October '20 Release! Lots of progress on our new Enhanced Online Payment Experience has been made, which means we are ready for beta testing.

This release also includes a new Guided Matching rule type for updating existing records, along with a solid list of enhancements and fixes for all customers.

Important Dates:

  • Release to Sandboxes: September 27, 2020
  • Release webinar: October 2, 2020
  • Release to Production: October 11, 2020

Enhanced Online Payment Experience for beta testing​

We are opening our Enhanced Online Payment Experience up to all customers as part of our beta rollout. This includes the following Enhanced Online Payment Experience features:

  • Version 2 of the Payment API (API v2, for short)
  • FinDock WebHub and Notification Gateway
  • Upgraded extensions with API v2 integration:
    • Buckaroo
    • Mollie
    • Stripe
    • SEPA
    • Gift Aid

API Token deprecated in API v2​

Issue: If the token for API v1 is included in API v2 message headers, the message would cause an error.

Solution: The API Token is a deprecated feature and not needed in API v2 implementations. We have removed the code allowing the token in API v2 headers.

Payment Intent ID added to webhook notifications​

Previously, FinDock only stored PaymentIntentId on the installment in Salesforce. To help 3rd party integrations maintain a fully transparent record of payments in their systems via webhook notifications, we have added PaymentIntentId to the webhook notifications so that external systems can easily connect intent and installment.

PaymentIntent errors stored in Log object​

To support API v2 debugging, we have updated error handling to store errors on the /paymentintent API in the Log object. When the API v2 responds with an error, that error is also logged a Log record in Salesforce.

How to use beta features​

We have collected all the new documentation and guidance for migrating to and using the new Enhanced Online Payment Experience here.

Some key points to keep in mind:

  • You can use classic and enhanced versions of payment extensions simultaneously.
  • Before you use the enhanced version, you should configure the new WebHub and Notification Gateway.
  • Payment extensions with the enhanced features have new toggles in the extension settings.
    • The classic toggle is enabled by default for existing installations.
      Toggles for classic or enhanced version of payment extension
    • New package installations have the enhanced toggle enabled by default.
    • The SEPA and Gift Aid pakcages do not have these toggles because the enhnaced version does not impact the settings for these extensions.

FinDock Core changes​

New Update Record rule type for Guided Matching​

We have added a new rule type for Guided Matching to further extend matching capabilities. With the new Update Record rule type, you can update any record of any object. The rule can be configured on any lookup or master-detail field on the Transaction or Inbound Report objects.

For further information, please refer to Guided Matching rule types.

note

With the introduction of this new rule type, the existing update installment rule has been deprecated. The generic Update Record rule can be used instead. The update installment rule still works, but it cannot be added to new rulesets.

After this release, one object-specific update rule remains: the Update Campaign Member rule. We have this special rule because Salesforce does not allow lookups to Campaign Member. The Update Campaign Member rule acts on the text field “Campaign Member Id” which comes from FinDock pre-shipped on Transaction and Inbound Report.

Set ESR processor in Payment Request Generator​

Issue: The ESR payment method is implemented by two different processors, CH-DD or LSV+. Prior to the September '20 release, both processors used the same reference generation process from the Payment Reference Generator. However, the September release introduced a prefix that is specifically used for LSV+ ESR references. This lead to the possibility that when selecting ESR as the request type to get the LSV+ reference with prefix, the outcome may not include the prefix. This was due to the fact the ESR method selection did not specify a processor selection.

Solution: We have added the processor (in parentheses) to all options in the payment request type drop-down list. And for ESR, there are two options in the list, ESR (CH-DD) and ESR (LSV+).

Generator type with processor selection

New permission sets to Site Guest User​

With the Salesforce Winter ‘21 release update, Salesforce is actively de-assigning permission sets that contain certain permissions for Site Guest Users. More information can be found here.

We have written an FAQ to explain which FinDock permission sets are impacted and how we are handling this. Some manual actions are needed. Please check the FAQ here for further information.

Birthday added to Giving Pages (pilot)​

We have added a new Birthdate field to the payment form Personal Details configuration. The field is hidden by default. If you use the field, please ensure the date order is maintained and separated by semi-colons. The values can be translated, but order and placeholders fixed. For example: year;month;date → Jaar;Maand;Dag

ProcessingHub changes​

Restartable jobs on ProcessingHub​

Issue: In certain cases, jobs running on ProcessingHub may be interrupted before they are completed. This can happen, for example, when Heroku dynos are cycled while ProcessingHub is working on a job. This issue has affected or potentially affects process involving Gift Aid (HMRC), Redsys, SmartDebit and Worldpay.

Solution: From now on Installments are marked as 'Submitting' on ProcessingHub right before the Installment is submitted. After the Installment is submitted to the processor (HMRC, RedSys, SmartDebit or WorldPay), it is marked as 'Done.'

When ProcessingHub encounters an Installment with the status 'Submitting' in a job that has been restarted, the job fails and the following error is logged to ProcessingHub Manager:

ERROR: An error occurred when submitting Installment data to an external system. Please contact FinDock support for assistance.

Buckaroo changes​

Added Handelsbanken BIC for iDEAL payments​

Issue: When you make a payment via the Payment API with the payment method iDEAL that is processed by Buckaroo, the BIC for the ‘Handelsbanken’ was not allowed although this is a legitimate option.

Solution: For both versions of the Payment API, the BIC for ‘Handelsbanken’ is available and handled correctly when processing an iDEAL payment with Buckaroo as the processor.

Gift Aid changes​

Gift Aid file check​

Issue: In our previous release, we solved a bug in Gift Aid (Faulty Gift Aid claim batches on ProcessingHub). In this release, we have added extra safeguards to further ensure similar bugs are avoided.

Solution: There are two new checks on the Gift Aid submission file that will prevent final submission to HMRC and generate an error message in ProcessingHub (viewable through ProcessingHub Manager) should either check fail. Both the number of records processed and the total Gift Aid amount of the processed records are counted and compared against the resulting submission file. If either do not match the count from the processing job, the submission is canceled.

Gift Aid start query too slow​

Issue: Gift Aid processing uses Batch Apex jobs for certain tasks. The first step in preparing a Gift Aid submission uses a Batch Apex query to check for eligible installments. For some LDV orgs, this initial start query could take several minutes and possible fail.

Solution: To reduce the time needed in the start phase of Gift Aid processing, we have changed the initial query (Batch Apex start method) to only select the Id field of the installment. The remaining required fields are fetched later during the execution phase.

Heroku dyno cycling may break Gift Aid submission​

Issue: Gift Aid processing has been handled as one job, doing everything from file generation to submission and polling of Gift Aid files from HMRC. This means large Gift Aid jobs may run for a long time. Since Heroku schedules cycling of dynos, in some cases these cycles may force a large Gift Aid job to be stopped prematurely. When this happens, the data of the cancelled job was not correctly updated, and instead of continuing from the point of cancellation, the entire job was restarted from the beginning.

Solution: We have taken a two-fold approach to this issue to minimize the risk of dyno cycles affecting Gift Aid processing. After this release, Gift Aid jobs are split into two separate jobs: one for generation and submission, and a second for polling and processing the HMRC response. This reduces the overall processing time of a given job. If a job does get interrupted by Heroku dyno cycling, the job is not restarted from the beginning. We handle the job data now so that the job can be restarted from where it left off.

SEPA changes​

Duplicate payment profiles​

Issue: The Create Installment rule in Guided Matching has auto-mappings for Custom_IBAN__c , Custom_BIC__c and Custom_Account_Holder_Name__c. These fields should be blank by default.

Solution: We have removed these auto-mappings from the Create Installment rule. If you would like to have such mappings, you can add them to your Create Installment rule mapping.

Issue: The SEPA package has functionality that would create a payment profile if any of the fields Custom IBAN, Custom Account Holder Name or Custom BIC are filled. This could lead to duplicate payment profiles and query exceptions in certain situations.

Solution: We have determined that this functionality is generally unnecessary. However, to avoid causing any issues with existing configurations, we have added a new setting in the SEPA package which is checked (activated) for existing orgs, but is off by default for new installations. SEPA will only create a payment profile if the new setting is activated.

Disable auto-generation

Bollettino Postale guided matching failed​

Issue: When uploading a Bollettino Postale file, the Inbound Report records created would get an invalid source, causing the Guided Matching processing to fail.

Solution: Inbound Reports records for Bollettino Postale, will get the default source. This makes sure they are processed correctly.

CAMT.053 & CAMT.054 files XSD error on datetime fields​

Issue: When a bank returned the value 24:00:00 instead of 00:00:00 in a datetime field, the CAMT file would be rejected by FinDock upon upload based on standard ISO 20022 XSD validation.

Solution: When FinDock encounters the value 24:00:00, a minute is substracted to transform the value into 23:59:00. This value passes ISO 20022 XSD validation.

Axerve changes​

New recurring payment authorization requirement​

Axerve has recently introduced a new mandatory field, ´BankTransactionId´. The ID code is sent from Axerve with the first transaction and must be included with all following transactions of the recurring payment in ´previousTransDetails.BankTransactionId´.

To support this requirment, we added a new field BankTransactionId to the Mandate object. When the authorization token is generated for the recurring payment, the BankTransactionId is stored on the Mandate record. For further information, please see Axerve for FinDock.

New token handling for Axerve MOTO​

With the FinDock Axerve integration, you can run Payment Schedules for recurring credit card payments. Based on how the credit card token was acquired from the customer (payer), Axerve requires different input. To make sure FinDock handles both recurring and MOTO tokens correctly, we have made changes to Mandate and Installment objects. For further information, see Axerve for FinDock

Worldpay changes​

Refunded status not handled automatically​

Issue: In production, Worldpay does not send the expected status REFUNDED without manual intervention for refunds. Instead, the messages SENT_FOR_REFUND and REFUNDED_BY_MERCHANT are used. FinDock was not able to interpret these messages, leading to incorrect refund handling.

Solution: In sandbox, REFUNDED is still used, so this remains as before. However, in production orgs, FinDock now triggers refund processing and sets Installment to refunded when Worldplay sends the message REFUNDED_BY_MERCHANT.

Authorization error handling improvement​

Issue: If the authentication fails when ProcessHub polls Worldpay, the error is not shown in the ProcessingHub Manager and the polling process continues.

Solution: We have updated the process handling so that if authentication fails, an error is logged in ProcessingHub Manager and the polling process is terminated. The new error message is:

Authentication error. Please check your configuration values "XML_API_ENDPOINT", "XML_API_USERNAME" and "XML_API_PASSWORD" for the target [TRAGET_NAME].