• Current release

Release Notes - September '24

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

   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: September 1, 2024
  • Release to production: September 29, 2024

FinDock for Fundraising to GA

After a few more tweaks and adjustments, the FinDock for Fundraising package is ready for General Availability. We are happy to see so many partners and customers already working with Nonprofit Cloud and the Salesforce Fundraising feature!

The GA release includes new features and several enhancements.

Out-of-the-box support for donation tributes

We are happy to announce that you can now gather donor tribute details through Giving Pages and custom front-end integrations to the Payment API.

You can configure and gather an extensive range of data to use in follow-up actions. These include:

  • Type of tribute (in-memory-of or in-honor-of)
  • The tribute message the donor wants to share
  • Honoree information
  • Details for sending an email notification about the tribute

The Tribute feature is only available with FinDock for Fundraising.

Gift Designation for Gift Transaction

With this release, we have extended support for handling default gift designations to one-time donations initiated through the Payment API or Giving Pages.

The designation for new one-time gifts is now determined according to the Gift Transaction Designation Inheritance Hierarchy as defined by Salesforce and used when FinDock creates the Gift Transaction record for new one-time installments. This follows the same behavior as recurring payments (Gift Commitments) created by FinDock.

Exclude Gift Transaction record types

We have added the ability to exclude specific Gift Transaction record types from the source connector installment handling. Excluded record types do not trigger installment creation when a gift transaction with that record type is created. Updates to those gift transactions also do not trigger installment actions. Select record types to exclude under the FinDock for Fundraising advanced settings.

Payment method syncing between FinDock and Salesforce

The Salesforce Fundraising objects Gift Transaction and Gift Commitment Schedule come with a standard field for indicating payment method (paymentMethod). Because FinDock has its own field for payment method, the Salesforce field needed a custom Flow to be correctly filled with the value used by FinDock. Otherwise, FinDock would set the value to Unknown.

With this release, we have eliminated the need for a custom Flow. The Salesforce Payment Method field is now automatically filled with a picklist of the active payment methods available from the FinDock Payment Method field (fdff__Payment_Method__c). These two fields synced one-way only, from FinDock to Fundraising, and are for informational purposes only.

Please note that payment methods added by FinDock are not automatically removed from the Salesforce picklist when deactivated in FinDock. You can, however, manually remove deactivated values if needed.

Person Account address fields

Person Account address fields (PersonMailingAddress and PersonOtherAddress) are now supported in the Giving Pages builder.

Gift Transaction status mapping update

Issue: The Cancelled status is used for all outstanding gift transactions when the related gift commitment is ended. However this status was not mapped to an Installment status. The installments for those gift transactions remained with New status, allowing them to be collected in a payment schedule.

Solution: The Canceled status of Gift Transaction is now mapped to Cancelled for Installment. When the installment is updated to Cancelled, the Last Cancelled Date field is also updated to reflect the gift transaction cancellation date.

FinDock permission set groups to GA

With this release, all FinDock permission set groups are out of beta testing and generally available.

All new FinDock installations use FinDock permission set groups. The “classic” FinDock permission sets are still available, but we recommend moving to FinDock permission set groups and new permission sets included in those groups.

As part of the generally available release, we have made the following adjustments:

  • Added FinDock Additional Setup permission set to Administrator, Service Agent and Operator permission set groups.

  • Added FinDock Core Base to the Integration User permission set group and removed FLS from the following permission sets:

    • FinDock Core Online Payments Integration

    • FinDock Core File-based Payments Integration

    • FinDock Core Mandate Schedule Integration

    • FinDock Core Payment Schedule Integration

  • Enabled edit for Mandate and Transaction Sub Element fields in the FinDock Core Payment Schedule Integration permission set.

The FinDock Additional Setup permission set is added to existing installations when the classic Setup is opened (or when the PaymentHub package is activated).

The FinDock Core Base permission set is automatically assigned to your integration user if permission set groups are not used.

FinDock Setup expanded Beta

The enhanced setup experience through the new FinDock Setup is moving to beta maturity in this release. Along with a few fixes and enhancements, we have significantly expanded the scope of what you can do through the unified settings interface.

Complete settings for Core and native processors

All Core feature settings, such as mandate settings, logging, etc. are now available through the enhanced setup. In addition, we have updated the existing FinDock native processor settings to cover all general and/or advanced settings related to the processor and method. This includes, for example, FinDock for Norway KID settings and general settings for Gift Aid.

ProcessingHub settings

All ProcessingHub related settings such as Bulk API and matching preferences are now available in the new FinDock Setup. The settings are available on the Connect with FinDock page under ProcessingHub Advanced Settings.

Support for payment method settings

You can now adjust payments settings like defaults and payment reference generation through the new setup.

New landing page and setup guide

When you open the FinDock Setup tab, you’ll see a new home page with guidance and other information to help you set up FinDock. This includes a new setup guide with a checklist to help you through the required steps for a basic FinDock setup.

Essential contact information

To ensure FinDock has current, correct contact information, details that may change over time, the enhanced FinDock Setup now includes a Contact Information setup page. On this page you can enter email addresses for key notifications and queries, such as security or privacy related incidents, billing queries and feature development discussion.

Package management

The new FinDock Setup now supports deactivating and reactivating payment extensions and source packages. Packages can also be uninstalled directly from FinDock Setup.

Source connector management

The FinDock Setup, our new enhanced setup experience, now also supports source connector package installation and configuration.

Custom payment methods

You can now configure and deploy custom payment methods through the enhanced setup.

PSP configurations

We've added more payment extensions in addition to Stripe. The remaining PSPs will come very soon.

Supported PSPs in the enhanced setup:

  • Adyen
  • Buckaroo
  • GoCardless
  • PayPal
  • Saferpay
  • Stripe
  • Swish
  • Vipps
  • Worldpay Corporate Gateway

MT 940 support

The new setup now supports the MT 940 processor. This is a unique processor that is part of the Core package. It allows you to import and process MT 940 files from your bank. However, we recommend using camt.053 files when possible. The MT 940 format can have bank-specific variations. Due to these variations, we maintain a list of supported BICs.

Deployment status

We have added user feedback to the deployment framework used by FinDock Setup. The feedback helps users understand and follow progress when configuration changes are being deployed.

Enhanced setup actions in Audit Trail

Configuration actions made through FinDock Setup are now captured as FinDock Audit Trail records.

FinDock Setup enhancements and fixes

Processors with toggle settings

Issue: Changing toggles in certain payment extension settings would block the changes from being saved, resulting in the error: Invalid conversion from runtime type Boolean to String

Solution: The underlying cause of the issue has been resolved so that toggles and saving behave normally as expected.

Deployments with NPSP

Issue: The configuration deployment mechanism was missing a required field (Business Process) for Opportunity record types. This prevented deployment of configuration changes through FinDock Setup in NPSP orgs.

Solution: We have updated the FinDock Setup deployment mechanism to include the Business Process of the given Opportunity record type.

Stripe account configuration

Issue: In the Stripe account configuration, you could delete the default account which should not be allowed. Stripe account names were also case insensitive when case should be sensitive.

Solution: We have fixed the new configuration to prevent default account deletion and enforce case sensitivity.

Stripe isTest toggle behavior

Issue: The IsTest toggle in the Stripe extension settings did not reflect expected options for production vs. non-production orgs.

Solution: The toggle is now on by default for non-production orgs and disabled in production orgs.

Stripe Log Requests option

Issue: The Log Requests toggle for Stripe accounts was not visible in the enhanced setup.

Solution: This has been fixed now so that you can enable Log Requests through FinDock Setup.

Existing MT 940 targets

Issue: If an MT 940 target was created in the classic setup, the new FinDock Setup deployment would fail.

Solution: The issue was caused by how the payment processor control picklist is handled by the new deployment mechanism. This has now been resolved so that the MT 940 processor (PaymentHub-MT940) is maintained between the classic and new setups.

Sweden to Beta

We are happy to announce that all our features and integrations for the Swedish market are now available to all customers. While we consider this a beta release, pilot customers are already moving to production in many cases.

Our set of Sweden features include:

  • Native Autogiro direct debit processing
  • Bank statement reconciliation for
    • BGMax files
    • Total IN files
  • Giro (OCR) payments and payment requests
  • FinDock e-mandates
  • Integration with Swish for Swish payment processing

Core

Configuration deployment with Salesforce Payment Method

Issue: The if an org has the sObject from Salesforce called PaymentMethod, FinDock could not deploy configuration changes. The deployment process would end with the error Attempt to de-reference a null object.

Solution: This issue was caused by how FinDock syncs fields when the org has an sObject of the same name. In this case, the PaymentMethod field sync was blocked by the sObject PaymentMethod. We’ve now updated the syncing mechanism to properly distinguish between fields and objects that have the same name.

Updated payment method logos

We’ve refreshed all the images used for payment method logos to improve their visual appearance in Giving Pages, PayLink and the new FinDock Setup.

Pre-fill hosted payment pages with person accounts

For certain payment service providers (PSPs), FinDock can pre-fill payer information from Contact and Account records on the Hosted Payment Page (HPP) of the PSP. With this release, FinDock adds support for pre-filling HPP forms with payer information from Person Account records.

Automated steps for Content Security Policy

Issue: If your org used the updated Content Security Policy directives, FinDock builder preview domains for Giving Pages and PayLinks needed to be manually added to the org Trusted URLs list.

Solution: With this release, we have added new prompts to the Giving Pages and PayLinks builders to allow for manual configuration of Trusted URL or automatic deployment by FinDock.

Multiple transactions matched to same installment

Issue: In certain rare cases, Guided Matching may incorrectly match two or more transactions to just one installment of a recurring payment. This may occur when the transactions are in the same transaction set and share the same payment reference. If this issue occurs, the matched installment has the wrong open amount, while the further (unmatched) installments have the wrong status.

Solution: The issue arises when the transactions are processed by separate Guided Matching jobs as the transaction set is handled. We have introduced additional mechanisms to more tightly control the timing of jobs for a given transaction set to help ensure transactions are matched to the correct installments.

Update Record rule enhancement for Account and Contact

Some customers need to make custom modifications to Contact or Account records as part of the payment intent handling in Guided Matching. However, if the raw message only includes the Contact block, you could not use Update Record to modify Account. If only the Account block is present, you could not modify Contact.

We have now removed this Guided Matching limitation. Customers can create custom Update Record rules to Contact and Account records regardless of what is included in the raw message of the payment intent inbound report.

Entry Criteria with empty fields

Issue: In Guided Matching, FinDock interpreted a field with a blank space as not empty (not NULL). In certain rule sets where “if empty” entry criteria are used with several rules in a particular field, this could lead to rules being incorrectly skipped.

Solution: We have updated Guided Matching to handle blank spaces in fields as empty (NULL) so if-empty entry criteria can be used as expected in these scenarios.

Payment Request Generator run with missing references

Issue: In some cases, a Payment Request Generator run for type Report would result in a completed run with some report rows missing a reference.

Solution: The underlying issue causing the missing references was related to case-sensitivity between campaign member ID values and report row handling. We have now resolved this issue. In addition, we have extended logging for generator types where this occurred to ensure missing references are caught should they occur.

Giving Pages

Built-in support for cover fee

Through Giving Pages you can now offer payers the option to add an extra amount to the payment. This extra amount can cover, for example, payment processing costs. The new Transaction Cover Fees setup is part of the Payment Form configuration. You can customize labels, texts, the extra amount percentage, and whether the optional cover fee opt-in is active by default. Payers can always choose to opt-out.

Built-in support for tributes

See above.

Support for optional initial payment for recurring payment

Giving Pages now supports the InitialPaymentonRecurring parameter. This parameter allows you to instantly capture the first installment of a recurring payment, instead of collecting later via a payment schedule. The parameter can be used to add an initial payment for a new recurring payment when this is optional for the given PSP and payment method. The parameter is available as a new toggle on the Configure Payment Methods setup. If the toggle is grayed out, that indicates the initial payment requirement cannot be changed.

For further information about how the initial payment is handled in the payment intent message structure, see How to use the Payment API v2.

Required picklist enforcement

Issue: Picklists on Installment, Recurring Payment, and source objects like Recurring Donation that are required according to the page configuration were not enforced on the published page. This allowed payers to skip the picklist and still proceed with the payment.

Solution: We’ve corrected the underlying validation rules leading to the issue so that picklists marked as required are now enforced.

Default yearly frequency

Issue: The yearly payment frequency on the Payment Form could not be selected when one-time and monthly frequencies are disabled.

Solution: We identified and fixed the bug preventing the yearly frequency from being set as the default frequency.

PayLinks

New custom URL redirect options

With this release, we have added three new custom URL settings for PayLinks. As part of the payment form configuration, you can now define:

  • Thank You page: Select the new Custom option and enter your own page URL in the Thank you URL field to redirect payers to a custom page for successful payment
  • Error page: Select the new Custom option and enter your own page URL in the Error Page URL field to redirect payers to a custom page if the payment fails
  • Webhook URL: Under the advanced settings of the payment form, you can enter a webhook URL. This tells FinDock to send webhook notifications about changes to installment status to other systems or applications to trigger actions, such as sending emails.

If you include __GUID__ in any of the URL’s, FinDock automatically adds the GUID of the given installment to that URL.

Support for Google Analytics and Tag Manager

FinDock PayLinks now integrates with Google Analytics and Google Tag Manager. To use Google Analytics, add your Tracking ID or tag ID from your Google account into the Google Tracking ID field under the Page settings. If you are using Google Tag Manager, use the Google Tag ID field to add your tags.

NPSP

Initial payment with new recurring payment

Issue: If an initial payment is used with a new recurring payment, the installment for the initial payment would be collected but then set back to status New.

Solution: The issue was caused by the order of messages received from the payment processor and FinDock asynchronous processing in NPSP. To ensure message are handled in the expected order, we have introduced new mechanisms to control the timing of certain processes.

Bacs Manual

Limit entries in generated files

We are relaunching support for limiting entries in generated files in this release. The previous implementation was rolled back due to performance issues.

In this release, two target settings for limiting the number of entries in a generated file are available for native Bacs Direct Debit processing (Bacs Manual).

  • DDIs per payer file: Limits the number of mandates (DDIs) in a single payer file generated by mandate schedules
  • Transactions per Collection file: Limits the number of installments (payment instructions) per collection file generated by payment schedules

When the limit is reached, FinDock automatically generates additional files as needed to cover the entire scope of the schedule.

No changes are needed for existing Bacs Manual targets. If you want to introduce file limits, simply update the default values with your new limits.

Credit amount in collection file

Issue: In the Standard 18 collection file generated by FinDock, the Credit Amount in the UTL record was empty.

Solution: We have updated the file generator to fill in the Credit Amount for the UTL record according to the Standard 18 specification.

Stripe

Initial payment with non-default target

Issue: When using the optional initial payment as part of a recurring payment setup, the recurring payment creation would fail if the payment intent message used a Stipe target other than the default. The initial payment succeeded, but no mandate and payment profile were created for the recurring payment.

Solution: The issue was caused by a metadata handling error in an outgoing message from FinDock to Stripe for setting up the recurring payment. This has now been resolved.

Swish

Desktop experience improvement

As part of the beta release of the Swish integration, we have improved the payer experience when using Swish through a browser on the desktop. This change enables a smooth payment flow when the Swish mobile app is not available.

Heroku apps maintenance

As part of ongoing software lifecycle management, we have upgraded PHP-related software components for Notification Gateway and WebHub, as well as the FinDock Installer and new FinDock Setup deployment framework. These upgrades do not require any action from customers.

Was this page helpful?