Skip to main content

Release Notes - March '24

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

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 the release date.

Important Dates:

  • Release to Sandboxes: February 25, 2024
  • Release to Production: March 24, 2024

NEW PILOT - FinDock e-mandates​

FinDock is developing a new end-to-end service for electronic IDs (eIDs) used to digitally sign e-mandates. The use of eIDs is gaining popularity and even required by some schemes, such as Autogiro direct debit in Sweden.

FinDock e-mandates is an an optional paid add-on feature for FinDock customers. In this release, we are rolling out the service specifically for Autogiro direct debit payments. If you are operating in Sweden and would like to participate in our e-mandates pilot, please contact FinDock Support.

NEW PILOT - Swish for FinDock​

We are adding another new payment processor to the Nordics. This time it’s for the Swedish mobile payment offering Swish. The new Swish for FinDock payment extension supports one-time payments using the Swish (e-wallet) payment method.

As usual, if you would like to participate in this pilot, please contact FinDock Support.

NEW PILOT: FinDock MOTO for Worldpay Corporate Gateway​

With the release, we are adding support to the FinDock Payment component for MOTO credit card payments through Worldpay Corporate Gateway. Support for this PSP option is being launched as a pilot, but is available to all customers for testing.

With the introduction of the FinDock Payments component for collecting MOTO payments, we are deprecating legacy MOTO solutions. The Worldpay MOTO and Ayden MOTO components are no longer actively used, so they are being removed from FinDock.

NEW GA FEATURE - FinDock Integration User​

We are happy to announce that our first FinDock permission set group, the FinDock Integration User, is now generally available. We’ve made a few more minor changes as part of this release:

  • Changed the “FinDock Nordic Integration” permission set label to “FinDock Norway Integration”
  • Removed the “beta” label from integration permission sets
  • Updated permission assignment checks for the ProcessingHub user

FinDock for Sweden pilot update​

We are adding several new capabilities to our ongoing pilot of the FinDock for Sweden payment extension. These enhancements further expand the scope of our native processing of Autogiro direct debit payments.

New integration user permission set​

With the additional capabilities of our native Autogiro direct debit processing, a new permission set, FinDock Sweden Integration. This new permission set needs to be assigned to the integration user profile.

Automatic Bankgirot file transfer​

The FinDock native support for Autogiro direct debits now features automatic posting and fetching of Bankgirot files via direct integration with the Bankgirot secure file transfer service.

This new capability eliminates manual upload and download tasks. FinDock will automatically submit generated files to Bankgirot for processing. The Bankgirot file service is also regularly polled for incoming statements. New statements are automatically uploaded to Chatter for matching and reconciliation.

Whitelist for Bankgirot target accounts​

With the automatic file transfer capabilities of FinDock for Sweden, FinDock needs to confirm that the Bankgiro account in a file is a legitimate, unique target in a Salesforce org. To manage this, we are introducing a whitelisting procedure to allow customers to register their Bankgiro accounts with FinDock.

Every org with the Nordic Payments package will have its own whitelist, so account numbers need to be registered with FinDock for sandbox and production orgs separately.

Contact FinDock Support for the new registration procedure.

Automatic account and clearing number validation​

Payment intent calls to the FinDock Payment API (including through Giving Pages) now include automatic clearing number and bank account validation for Swedish bank accounts. The Payment API returns a new response code 206 if either value is invalid or otherwise unusable.

Nordea Total IN reconciliation for Sweden​

In this release we are adding support for Nordea Total IN bank files that capture PlusGiro, Bankgiro and other payments. The Total IN file is a common format used in Sweden, similar to BGMax.

Total IN files uploaded to Chatter are automatically picked and parsed by ProcessingHub for matching and reconciliation. For further details, please refer to the Total IN article in the March '24 version of the knowledge base.

If you would like to participate in the Total IN pilot, please contact FinDock Support.

FinDock for Fundraising pilot update​

With this release, our source connector for Salesforce Fundraising reaches feature parity compared to FinDock for the Nonprofit Success Pack. We've added several capabilities as well as made some important enhancements to existing features.

Support for Quick Tikkie​

The Quick Tikkie component now supports person accounts, allowing the component to be used on Fundraising objects such as Gift Transaction.

The component itself does not change, but the related Guided Matching rules have been updated to handle Person Account records when matching and reconciling inbound reports.

Support for GoCardless Quick Direct Debit​

The GoCardless Quick Direct Debit component, used for manually entering GoCardless direct debit payments, can now be used with FinDock for Fundraising. We added support for using the component on Person Account in addition to Contact.

Support for Payment Request Generator​

We are happy to report that our testing has confirmed that the Payment Request Generator can be used with Fundraising and the Nonprofit Cloud. No changes are required to start using the Payment Request Generator. We just updated a Salesforce API version to enable support for Fundraising objects and fields.

The only thing to keep in mind is that Fundraising relies on person accounts and leans on outreach source codes. Adding payment references to campaigns or campaign members that are person accounts works as normal. For adding references to an outreach source code, you should create a report for the source code and then use the Report type with mapping to Outreach Source Code, as pictured in the example below.

Payment Request Generator mapping for Source Code

Support for UK bank account and sort code check​

With this release, the FinDock sort code and account checking for Bacs Direct Debit can be added to Fundraising objects including Gift Commitment, Gift Commitment Schedule and Gift Transaction.

This is an update to the FinDock BACS package which needs to be installed in an org with Fundraising to be able access the new checking capabilities.

Other enhancements​

UX improvement to field mapping​

We made visual adjustments for the Gift Transaction and Installment field mapping in the Fundraising for FinDock setup configuration. For certain mappings managed by FinDock, there is new information to clarify how those mappings work.

Handling update for Effective From Date​

Issue: When setting up a recurring gift with a start date in the future, FinDock throws the error: Value for Effective From Date parameter is invalid because it's before the start date. This occurs if the set up channel, such as GoCardless Manual Entry, allows the start date to be set to a future date rather than the expected current day (today).

Solution: If the start date for a new recurring gift is in the future, FinDock now uses that future date as the Effective From Date on the gift commitment.

Recurring payment setup via Payment API error​

Issue: When setting up a new recurring gift commitment through the Payment API (Giving Pages, PayLinks or other front-end), the resulting inbound report for the payment intent could fail with the error: SObject row was retrieved via SOQL without querying the requested field: Contact.LastName.

Solution: This issue was caused by how FinDock handles name fields if both Contact and Account are included in the payment intent message. This has now be resolved.

Multicurrency handling update​

Issue: If multicurrency is enabled in an org, a payment intent message that does not include CurrencyIsoCode would result in a failed inbound report with an UNKNWON_EXCEPTION error.

Solution: If the payment intent does not have a declared currency, FinDock falls back to the default currency of the org.

Classic Online Experience End-of-Life​

The first version of the FinDock Payment API (APIv1), our “Classic” experience, will be decommissioned at the end of 2024. All integrations should be migrated to API version 2 (APIv2), the Enhanced Online Experience, by January 2025.

In addition to enhanced security, the APIv2 framework delivers significantly better performance, as well as greater flexibility and extendibility for advanced integration use cases. Not only are online payments processed faster, but you get full transparency of the processing for building insights, easier troubleshooting, and more.

At the beginning of 2024, we reached out to customers and partners still using APIv1 to inform them of the EOL and help them prepare. We have detailed instructions on how to migrate to APIv2 in our Knowledge Base. You can start here.

If you have any questions, don’t hesitate to contact FinDock Support.

ProcessingHub​

Support for version .008 of camt.053 and camt.054​

With this release, FinDock supports camt.053.008 and camt.054.008 bank statements. The .008 version, introduced by the 2019 update of ISO20022, is becoming the required minimum version level for many banks.

The parsing logic remains largely the same for .008. However, there are significant changes in the substructure of the Party40Choice, which is used to identify a person, organization or financial institution. In our updated parsing rules, if the RelatedPartyType is Financial Institution, the address fields are ignored because they are not applicable for CRM data under normal circumstances.

ProcessingHub Manager Salesforce connect error​

Issue: In certain scenarios with specific orgs, the ProcessingHub Manager cannot open, instead reporting a critical Salesforce connection error even when ProcessingHub Manager is actually running normally.

Solution: The error thrown by ProcessingHub Manager indicated an authorization issue. However, the problem arises due to a delay in the response from ProcessingHub Manager when opening the application. We have made several enhancements to improve response times as well as replaced the connection error message. The new error message instructs users to wait and then retry opening.

Environment renaming​

We have updated the naming of backend test environments to consolidate types and better reflect their purpose. The new names clearly indicate which type is for customer sandboxes and which are for FinDock-internal or other special scenarios.

Batch process handling and permission errors​

Issue: If there are permissions-related errors blocking batch processes on ProcessingHub and ProcessingHub Manager, FinDock would get into a retry-loop resulting in processes that appear to run indefinitely.

Solution: When a batch process runs into permission issues, FinDock will now throw an invalid batch error. The error message in ProcessingHub Manager includes the fields where required permissions are missing so permissions can be fixed accordingly.

Access PaySuite (SmartDebit)​

Process handling to Salesforce​

With this release, the mechanism for trigging SmartDebit processes moves from ProcessingHub to Salesforce. By starting processes from Salesforce, FinDock increases stability and enables stronger security measures.

Report matching update for case sensitivity​

Issue: For Bacs Direct Debit payments through SmartDebit (Access PaySuite), ProcessingHub could not match mandate references if the original reference value has lowercase or mixed upper and lowercase characters. This occurred because the Bacs reports normalize the mandate reference to all uppercase.

Solution: We’ve updated the matching logic in ProcessingHub to be case insensitive for mandate reference values.

Enhancements for large volume Bacs direct debit runs​

Issue: Payment schedules with very large numbers of installments may not complete successfully due to stalled processes that require manual intervention to resolve.

Solution: Processes running on ProcessingHub may stall due to delayed responses from callouts to Access PaySuite. To help mitigate the issue and reduce the need to manually retry processes, we have implemented a new timeout for callout responses along with a new auto-retry. The auto-retry is triggered for processes that hit the timeout limit. In addition, we have added more detailed logging to help with future troubleshooting of stalled processes.

Buckaroo​

Expanded transaction type support​

Issue: Buckaroo uses granular transaction type codes to distinguish payment methods, card brands, issuers, and so forth. Although FinDock supports many of these codes, some that customers may use were missing, resulting in unsuccessful inbound report matching.

Solution: We have added the following transaction type codes based on recent customer usage and our own internal assessments.

  • C811 Maestro Pay via Buckaroo
  • C813 Maestro Refund via Buckaroo
  • C872 Creditcard - Maestro Pay Collecting via Buckaroo
  • C873 Creditcard - Maestro Refund Collecting via Buckaroo
  • C876 Creditcard - MasterCard Pay Collecting via Buckaroo
  • C877 Creditcard - MasterCard Refund Collecting via Buckaroo
  • C880 Creditcard - Visa Pay Collecting via Buckaroo
  • C881 Creditcard - Visa Refund Collecting via Buckaroo
  • C884 Creditcard - Visa Electron Pay Collecting via Buckaroo
  • C885 Creditcard - Visa Electron Refund Collecting via Buckaroo
  • C990 Amex Pay
  • C992 Amex Refund

Gift Aid​

Expanded object support for Gift Aid Declarations component​

The Gift Aid Declarations component, used for checking Gift Aid declaration status, can now be added to the following objects:

  • Gift Commitment (Fundraising)
  • Gift Commitment Schedule (Fundraising)
  • Gift Transaction (Fundraising)
  • Recurring Donation (Nonprofit Success Pack)

NPSP​

Opportunity Closed Date not updated to Last Collection Date​

Issue: With the standard mapping between NPSP and FinDock, a payment through Stripe or Vipps may not result in an updated Close Date for the related opportunity. The installment Last Collection Date is updated correctly, but the opportunity Close Date remained as is.

Solution: The issue was caused by how FinDock handled the payment success notifications in the context of NPSP field syncing. Status and date changes where handled in such a way that the Close Date sync was not triggered when the Last Collection Date on the installment was updated based on the creation of the Payment record. The Close Date is now updated when the installment is set to Collected, consistent with the other processor payment extensions. This fix is for the Stripe and Vipps payment extension packages.

Redsys​

Fix for recurring credit card payment collection​

Issue: In certain scenarios with some Redsys customers, collection of recurring credit card payments was not working. Recurring credit card payments set up through the FinDock Payment API could not be collected with payment schedules. The payment schedule run would result in an error.

Solution: The issue was caused by how ProcessingHub handled a specific Redsys API parameter value. This has now been fixed so payment schedules result in collected installments for all customers as expected.

Stripe​

Prevent double collection with initial payment on recurring​

Issue: In certain scenarios, the (optional) initial payment of a new recurring payment may get collected a second time with the next payment schedule run. This can occur when the optional payment requires requires additional action from the payer. The timing of the requires_action and charge.succeeded notifications could result in the related installment being first set to Collected by the charge.succeeded notification and then set back to Pending due to the required action. The Pending status, in turn, could then be changed to New by NPSP status syncing.

Solution: FinDock no longer automatically sets installment status to Pending by the requires_action notification. Instead, we have refined the handling of this notification to only allow an installment to be set to Pending when the required action is a microdeposit confirmation.

Vipps​

Ledger handling update​

Issue: In some scenarios, FinDock would create duplicate payments in Salesforce for Vipps ledger transactions. This was caused by the way FinDock was fetching transactions for closed ledgers and triggering batch processing of queued messages to create inbound reports.

Solution: The batch process was triggered too often in the Vipps processing logic that is part of the FinDock Heart Beat. We have updated the logic so that the batch process is not started until after FinDock has checked and retrieved all available ledger transactions. This ensures that the batch processing can finish before the next heart beat.