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 the release date.
- Release to Sandboxes: October 30, 2022
- Release to Production: November 27, 2022
New pilot feature - FinDock MOTO
We are very excited to start piloting our native Salesforce support for Mail Order Telephone Order (MOTO) payment collection. The new FinDock Payments component can be used to set up one-time and recurring credit card payments on the phone or from paper donations straight from Salesforce. This feature is first enabled for use with Stripe as processor.
Join us at the release webinar to learn more!
Giving Pages custom domains to GA
Custom domain with FinDock Giving Pages is now generally available to all customers. Thanks to everyone who participated in the beta testing! We made some improvements along the way:
- Support for domains with three full stops
We updated the domain validation rules used by the Pages Builder to allow domains with three full stops, such as
- Better support for copying DNS instructions
In certain browsers (like Firefox), copying is blocked in the DNS instructions box in the Domain Manager, making it difficult to transfer the CNAME value to the custom domain hosting provider. We changed how the CNAME record is presented, to ensure it can be copied.
- Enhanced SSL certification process
When a custom domain is created at a hosting service provider, it may take some time for the new domain to propagate through DNS networks. If FinDock tries to register an SSL certificate during this period, the certification would fail. The URL could be reached, but with an SSL certificate warning. We’ve now implemented an automatic check and retry procedure when registering new SSL certifications. For any domain that fails, FinDock automatically retries registering the failed domain. If the retry also fails, FinDock Support is notified.
Payment schedule LDV performance to GA
The performance enhancments for payment schedules in Large Data Volume (LDV) orgs are now generally availalbe. Many thanks to our LDV customers for your valuable testing results.
With this GA release, we've included some important fixes as outlined in the following sections.
Batch deleting of old jobs
Issue: In certain circumstances, such as testing LDV orgs, a very large number of records may accumulate. When FinDock tries to delete all these records, an error is thrown by
CleanJobRecordsBeat when it tries to delete
Job__c older records. This occurs because deleting all the records at once exceeds Salesforce processing limits.
Solution: We’ve changed how records are deleted in the framework used for Payment Schedules. Large numbers of records are broken into batches first (that are well below Salesforce limits) and then deleted batch by batch.
Handling malformed SOQL
Issue: In our new queueable framework for enhanced payment schedule performance in LDV orgs, malformed additional SOQL on a payment schedule did not throw an error. The payment schedule would just hang.
Solution: If there is a problem with the additional SOQL on the payment schedule, FinDock now sets the schedule to Failed and records the the error
Error in query: <Query that was executed> in the Last Status Reason field. This is consistent with the behaviour pre-enhancements.
Component error in Page Builder
Issue: The Giving Pages Page Builder from time to time may throw a Salesforce "Component Error" when you are working on the Amounts and Frequency configuration of the Payment Component settings.
Solution: We have instead implemented some code-level optimization that should reduce if not completely eliminate this type of error.
PayLinks performance improvements
We have optimized WebHub backend performance to support high-volume PayLinks users. Additionally, we’ve added more tracing and logging to help with future troubleshooting.
As part of the November '22 release, we are include a number of improvements to ProcessingHub to reduce or automatically fix certain encountered errors. These include:
- Deleted staging records - a
Sync failederror can occur because the Salesforce Bulk API job is closed before all batches are sent to Salesforce. ProcessingHub now checks to ensure all batches are sent before closing the job and deleting staging records.
- Bulk API retry - in the May '22 release, we implemented an automatic retry for the creation of Salesforce Bulk API jobs and batches on every push data load task. This automatic retry could in certain circumstances result a
Retry Id not specified in update callerror which has now be resolved.
- Connection error - processes can at times be blocked due to a generic
sfdc connection error (cURL error 35)error. This has been fixed in the passed with a manual retry, which we have now implemented as an automatic retry by ProcessingHub.
Camt.053 mapping update for Swiss QR-bill payments
With the new QR-bill payment method in Switzerland, camt.053 statements may include payer information in the
UltmtDbtr element of the camt.053 XML structure.
We have updated our camt.053 mapping to now include the payer information under
UltmtDbtr (which is similar to the existing mapping for
MT 940 support for additional Lloyds branches
We’ve added support to our MT 940 file parsing for Lloyds Bank branches with BIC LOYDGB21682 as well as LOYDGB21XXX variations.
MT 940 mapping update for Commerzbank AG
Issue: MT 940 files from Commerzbank AG apply a specific mapping logic for the value that should be used as the payment reference in FinDock.
Solution: We modified MT 940 parsing rules to support this specific mapping logic. This update only applies to MT 940 files from Commerzbank BICs.
File operation errors in sandboxes with Enhanced Domains
Issue: In sandbox orgs, update or create operations through the Salesforce REST API as well as file uploads to Chatter lead to Salesforces errors. The
Invalid session: expired error would result in the process being rejected outright.
Solution: The invalid session error is related to the forced Salesforce Enhanced Domain feature rollout, which changes the sandbox org URL (augmented with
.sandbox). We’ve introduced additional modifications to ProcessingHub (and WebHub) to be able to better handle the new sandbox org URLs with Enhanced Domains.
Undefined offset error with ProcessingHub operations
Issue: Update or create operations through the Salesforce REST API as well as file uploads to Chatter may result in an
undefined offset error. This could for instance impact the upload of bank statement files.
Solution: The error is temporary and can be resolved with a simple retry. FinDock now retries automatically when this error is encountered. This change was also made as a hotfix for the September '22 release.
File processing between production org and sandbox copy
Issue: In rare instances, a full copy sandbox of a production org (including ProcessingHub connection details) could lead to unwanted file processing. A file uploaded to the sandbox copy would under certain circumstances also be processed for the production org, leading to a processing error for the production org.
Solution: We have added a new Salesforce org Id check to ProcessingHub requests to prevent files processed for one org to be re-processed for a different org. If the org Id is not known, the request is rejected by Processinghub.
Enhanced handling of deleted files
Issue: Deleting a file from Salesforce - for instance in an attempt to stop an incorrectly uploaded file from being processed - while FinDock is trying to process that file causes ProcessingHub to get stuck. Once this happens, manual intervention from FinDock was required to restart processing on ProcessingHub.
Solution: If a file is deleted, ProcessingHub will now terminate processing and record an error in ProcessingHub Manager. The new error message is presented in the Reject File field in the manager view:
File [id] not found. Typically this indicates the file has been deleted. This prevents the process from getting stuck and new processes are not prevented from being picked up.
Payment Request Generator
New input field option for manual generator runs
Prior to this release, you could only select an existing field for input mapping when creating a manual Payment Request Generator run. With this release, we have added the ability to add a static value for input mapping.
For example, when using the Bring Your Own Reference generator type, you used to have to select an existing text field as the input Reference Field. Now you can enter a specific value as the input field that will be used for that specific generator run for all records.
This new capability eliminates the need to create custom fields for particular Payment Request Generator types and runs, unless you require advanced logic to determine the value in for instance a formula field.
In addition to these new capabilities, we have fixed a visual bug that was noticed in our testing. If you changed an already saved payment request type, the generator type picklist would not update accordingly. The picklist now updates correctly according to the selected payment request type.
New support for references on Campaign
We are introducing support for adding the generated reference on campaign level instead of only campaign member level.
Before this release, when you created a Payment Request Generator run with
source_type__c = 'Campaign' , FinDock added references on campaign members. With this release, the Campaign source type creates a reference on the Campaign level. To continue to generate references on campaign members, the automatic run configuration needs to use
source_type__c = 'campaignMember'.
Managed Guided Matching rules from FinDock have also been updated accordingly to handle the new source type arrangement. If you are using custom rules as well, you should check whether they need to be updated.
Cancelled payment handling correction
Issue: When using iDeal with Adyen and choosing an issuer over the FinDock Payment API (including Giving Pages and FinDock PayLinks) FinDock would always redirect the user to the success URL, even if the payment is cancelled.
Solution: We corrected our integration with Adyen to redirect the user to the success or failure URL provided in the API call based on the payment status with Adyen.
Increased timeouts for Adyen responses
Issue: Payments initiated through the FinDock Payment API can end in an unexpected error due to delayed responses from Adyen. This could lead to payments not being captured.
Solution: To help mitigate errors caused by response delays, we have increased the Salesforce timeouts for callout processes used with Adyen.
Data Quality rule correction for Bacs Manual
Issue: The FinDock Data Quality component incorrectly applied a Mandate ID validation rule to installments with payment method Bacs Manual, causing them to fail. The rule is a requirement for SmartDebit installments only.
Solution: We’ve updated our Data Quality rules to correctly filter out Bacs Manual installments so that the SmartDebit rule is only applied to SmartDebit installments.
Guided Matching update for Bacs reports
Issue: When Bacs reports (AUDDIS, ADDACS, etc.) are uploaded to FinDock, the resulting inbound reports are created and processed through Guided Matching. FinDock allows you to add your own Guided Matching rules to the ruleset for these reports. However, FinDock would always set the status to Guided Review for some report codes according to default FinDock behavior.
- Report codes that were set to Guided Review are now given the status Manual if no match is found.
- If custom matching rules are added after the FinDock default rules, the end status of the inbound report is Matched.
- Custom rules are now processed automatically. You no longer need to manually skip the last FinDock rule to proceed to a custom rule.
New support for generating iDEAL QRs
For the Buckaroo payment extension, we have added the ability to create iDEAL QR codes using the FinDock Payment Request Generator. The new payment request type
Ideal allows you to generate open or closed (fixed) amount QRs with an expiration date you can define yourself. With this release this is possible on Campaigns, Campaign Members and on Reports
As part of this update, we also modified the Buckaroo Integration User permission set. If you have not done so already and plan to use IDEAL QR, please assign this permission set to your Integration User that is used for the ProcessingHub connection.
You may need to contact Buckaroo to enable iDEAL QR for your merchant account.
Notification sub-types added to Guided Matching
Issue: FinDock did not cover all possible notification sub-types from Buckaroo in the Guided Matching rules for Buckaroo. Sub-types that were not recognized would lead to inbound report errors.
Solution: We have updated the list of supported notification sub-types to include all relevant sub-types from Buckaroo. The added sub-types cover payment and refund actions for specific types of Visa and Mastercard transactions.
Payment schedule fails on Process step
Issue : After the September ‘22 release, customers were not able to run payment schedules for credit card payments through Redsys reported through our Status servie. The Process step of the resulted in a
Payment Schedule could not be processed (404) error, and FinDock set the schedule's status Failed.
Solution : We identified the bug causing the issue and fixed it so that payment schedules for credit card payments through Redsys complete as expected.
Payment schedule installment scope correction
Issue: When running a payment schedule, installments with status Pending Recollection that fall within the selection period are supposed to be included. However, when Redsys was as selected the processor, these installments were ignored.
Solution: We identified and corrected the bug causing the issue so that installments with Pending Recollection are included as expected when Redsys is selected as the process on a payment schedule.
Payment collection for installments that do not have status New or Pending
Issue: When a SmartDebit payment schedule has installments with a status other than New or Pending, the schedule gets stuck in the Processing phase. This can happen, for example, when retrying a payment schedule that has failed installments. This issue arises because ProcessingHub counts the total number of installments in the schedule and compares that to the number of installments processed by Smart Debit to determine when SmartDebit is done processing. The counts in this case would never match because the SmartDebit number only includes installments that have New and Pending status, leaving ProcessingHub in a constant waiting state.
Solution: We’ve updated the counting logic in ProcessingHub to filter out installments that do not have New or Pending status so that ProcessingHub can always determine when SmartDebit is done processing the relevant installments from the schedule.
Bancontact added to supported payment methods
The Stripe for FinDock payment extension now supports the Bancontact payment method.
Collect recurring payments with Apple Pay and Google Pay
Good news! You can now accept recurring payments with Stripe using Apple Pay and Google Pay payment methods. Please refer to the Stripe article in our Knowledge Base for further details.