# Release Notes - October '20

Our release communication aims to inform you early of upcoming releases. The scope of a release is subject to change prior to the release date. Release notes are updated accordingly until the release date.

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


iframe
## 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.

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](/docs/setup/configure-webhub).
* 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](/assets/classic-enhanced-toggles.4b66181a5032c7fe0b05db3c60d47e18f29c8c9ef166b6ba6161802c0c2bbd79.f78e0b2f.png)
  * New package installations have the enhanced toggle enabled by default.
  * The SEPA and Gift Aid packages do not have these toggles because the enhanced 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](/docs/reconciliation/guided-matching-rule-types).

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](/assets/prg-type-with-processor.036e2497ac6fbc0af976fb26198b9104f16173f20e5aa92865e9650c7ea7cde7.f78e0b2f.png)

### 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](https://help.salesforce.com/articleView?id=networks_guest_policies_timelines.htm&type=5).

We have written an FAQ to explain which FinDock permission sets are impacted and how we are handling this. Some manual actions are needed.

### 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](/assets/disable-auto-generation.b9ff67c43176c116e400899cdd5dfcb0b275e1a6f386cac1e583c103d7557449.f78e0b2f.png)

### 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 subtracted 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 requirement, 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](/docs/payment-processors/axerve#bank-transaction-id).

### 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.

## 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 Worldpay 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].`