Release Notes - July '23

We are happy to present the FinDock July '23 Release!

Important Dates:

• Release to Sandboxes: June 25, 2023
• Release to Production: July 23, 2023

Nordic Payments and Vipps to Beta

Thanks to great cooperation with customers and partners, FinDock is now ready to move the Nordic Payments (AvtaleGiro) and Vipps packages to Beta! All customers are welcome to test our native solution for processing AvtaleGiro direct debit payments and our Vipps mobile payments integration.

The Beta release includes several fixes outlined in the sections below.

Nordic Payments

AvtaleGiro query handling update

Issue: When there are more than 50,000 AvtaleGiro agreements without a KID FinDock, FinDock would run into a query limit during the KID generation process preventing further KID generation.

Solution: We’ve refactored the query logic to avoid hitting this limit.

File transfer after payment schedule when not enabled

Issue: FinDock would attempt to send OCR files generated by payment schedules to the FTP file service of Mastercard Payment Services even if the file transfer option in the Nordic Payments extension settings was not enabled. This resulted in blocked payment schedule processes on ProcessingHub.

Solution: We have implemented the expected settings check to ensure ProcessingHub does not contact MPS if the file transfer option is not enabled.

Guided Matching rule order for AvtaleGiro payments

Issue: The Create Payment Profile rule is too early in the rule execution plan, This can result in orphaned payment profiles and potentially other issues if Payment Profile uniqueness enabled.

Solution: We have updated the rule order so the payment profile creation occurs after all contact matching is completed.

Trigger update for KID creation on Contact

Issue: After Inserting a contact as a standard user, FinDock would require customized application permission to generate a KID-number which is an overly broad permission context for the given trigger.

Solution: We modified the KID generation trigger on Contact to not require the full customized application permission.

Vipps

Error when fetching ledgers

Issue: Receiving ledgers from Vipps could not be completed due to failed incoming API messages.

Solution: The issue was caused by a mapping error between ledger and Salesforce data. This has now been corrected.

Ledger error handling update

Issue: Incoming messages from the Vipps ledger check (GetLedgerTransactions) would be set to Failed if a false-positive duplication error was detected (due to field idempotency key). This prevented FinDock from handling any further messages in the queue. Messages from before the error, however, would continue being processed as inbound reports that kick off the matching process.

Solution: Now when GetLedgerTransactions tries to create messages and runs into errors, FinDock continues depending on the error type:

• Idempotency errors are ignored and the next messages in the queue are further processed as expected.
• If some other error occurs, the entire GetLedgerTransactions run is rolled back.

Ledger date handling update

Issue: When pulling in transactions from the Vipps reporting API, FinDock keeps track of the last ledger date. This date is used for the next run to fetch new data. FinDock sets the date to the last day with known payments. This led to failures because FinDock would include in the next run transactions that have the same date as the last ledger date.

Solution: FinDock sets the last ledger date to the date of the last day with known payments. However, the next run date is now scheduled to be the last ledger date + one day. For example, if FinDock successfully fetched payments on 2023-07-03, the next run only includes transactions from 2023-07-04, rather than trying to fetch any records from July 3rd again.

Giving Pages

NEW - more donation amount presets

We are happy to announce Giving Pages now supports up to 6 preset donation amounts. It has been a popular request among customers to expand the current three presets to support more variation for different needs. To accommodate the additional presets, we have made some design changes to the Give Pages Payment Form layout. This includes changing how pages offer an open “Other” amount. This is no longer a standard preset field but an additional input field that can be enabled if needed, as pictured below.

Due to these cosmetic changes, we have reached out to customers with published donation pages to prepare them for this release.

In addition to the new preset amounts on the payment in configuration options, we have implemented new and updated URL query parameters that can be used to override the configured values on a given page. For further details, please refer to the July '23 version of our Payment Form article.

NEW - donation yearly frequency

In addition to the existing one-time and monthly donation frequency options, you can now offer a yearly frequency for Giving Pages. The new yearly frequency can be enabled under the Amounts & Frequency settings of the Payment Form. The new frequency is available for all Giving Pages webpages.

In addition to the yearly frequency on the payment in configuration options, we have implemented new URL query parameters for the yearly frequency option. For further details, please refer to the July '23 version of our Payment Form article.

Custom fonts not shown in picklists

Issue: Custom fonts added to a page were not rendered correctly in picklists on the published page.

Solution: We identified and fixed the bug causing the issue so that custom fonts are now rendered as expected.

Delay when unpublishing pages

Issue: Unpublishing a page did not result in an immediate removal of the cached page. The cached page could remain for up to 24 hours, during which time other Giving Pages actions may not work as expected.

Solution: We modified cache handling to ensure pages are cleared as soon as they are unpublished.

Empty fields lead to failed inbound reports

Issue: When a payer completes a payment through Giving Pages, FinDock generates an inbound report from the resulting payment handling actions. The inbound report is used for reconciliation to update the related installment. If the payment form uses additional fields which are left empty, the inbound report would fail unexpectedly.

Solution: The issue was caused by how the form field data is handled in API calls. We’ve updated how the messages are populated to ensure inbound reports can be processed even if payers leave fields empty.

Missing validation for checkbox field

Issue: If a checkbox field is marked as required in the Page Builder, a payer could by-pass the checkbox (not click the box) and still complete the payment.

Solution: The payment form validation rules have been updated to ensure checkbox fields are correctly handled when required.

State and Country picklists rendered as text

Issue: If State and Country picklists are enabled in an org and used in additional address input fields, these were incorrectly rendered as text fields on Giving Pages. Incorrect values entered into these fields would result in an inbound report failure.

Solution: FinDock now renders the Country field as a picklist when used as an additional address input field. If Country is enabled in the address field, State is hidden by default. State can be added as a separate input field, but it will show all picklist values.

Requirement indicators missing for checkboxes

Issue: If a payment form includes a required checkbox, the page did not show the expected indicator (asterisk) or show the requirement error message if skipped.

Solution: We have now added the indicator and error message to required checkboxes.

Unable to restore after lost WebHub connection in production orgs

Issue: When trying to re-establish a WebHub connection in production orgs (e.g. integration user unexpectedly deactivated), FinDock would indicate that it cannot restore existing Giving Pages webpages.

Solution: The error message would appear because FinDock was looking for the wrong URL structure to locate production webpages. This has now been fixed so reconnecting WebHub can proceed as expected.

Guided Matching

NEW - expanded overpaid handling

For matched incoming payments, FinDock automatically handles overpaid amounts based on your preferred settings. This logic has now been extended to new incoming payments using the Process Installment rule in Guided Matching. This rule has a new Leave Remainder on Transaction / Inbound Report for the Overpaid Installment Handling setting.

In addition, the following fields are added to the Transaction object:

• Use Open Amount (True | False)
• Processed Installments (Ids of installments updated by overpaid handling)

On Inbound Report, the new fields are:

• Open Amount
• Use Open Amount
• Processed Installments

When installments are overpaid, the Leave Remainder on Transaction / Inbound Report allows you to keep the unallocated amount on the record and allocate to an installment later. If the record has an open amount after Guided Matching, the record status is now set to Partially Matched.

EXAMPLE

Transaction amount = 100
Installment Amount = 25

After first execution:

• Transaction Status = Partially Matched
• Transaction Use Open Amount: True
• Transaction Open Amount: 75
• Installment Status: Collected

At this point the record is Partially Matched (end state of Guided Matching Execution Plan). You can put these records to Guided Review, or re-run Guided Matching later. For instance, after a second installment is created for 75 and Guided Matching is executed a second time on the same transaction:

• Transaction Status = Matched
• Transaction Use Open Amount: True
• Transaction Open Amount: 0
• Second Installment Status: Collected

Create Record rule update

Issue: The target of the Upsert Field is not taken into consideration during rule execution for the Create Record rule. For example, when creating a Payment Profile record, the Upsert Field searches Transaction Payment Profile.

Solution: We identified the bug causing the unexpected Upsert Field behavior and corrected it so that the target object is searched as expected.

FinDock Payment API

Optional initial payment for recurring payments

We've added a new parameter for supporting PSPs that offer a variety of options regarding initial payment when setting up a new recurring payment. For further details, see below.

Notification Gateway

Improved account management

We are re-engineering access management for WebHub and Notification Gateway to improve security and maintainability. This work is now completed for Notification Gateway and will be extended to WebHub in the next release.

ProcessingHub

Euro dependency in multi-currency orgs

Issue: If you are using a multi-currency org without EUR enabled, FinDock could encounter a currency error when running a mandate schedule. Instead of completing, the process would end with Currency ISO CODE: invalid currency code: EUR.

Solution: The issue was caused by how FinDock handles updates to PaymentHub File records. We’ve fixed this now to remove the unnecessary Euro dependency. This is a re-work of the implementation introduced in the March 23 release.

Camt.053 enhanced handling of remittance information

As part of the May '23 release, we introduced a trimming mechanism for long remittance information entries in camt.053 files. With this release, we are improving how this information is handled by modifying the trimming and adding a new field.

The existing field, Remittance Information (cpm__Remittance_Information__c), is now trimmed to 252 characters with an ellipsis (…) at the end and has a new help text to indicate that the information is not complete. In addition, we have added a new field, Remittance Information Long (cpm__Remittance_Information_Long__c), where the complete set of remittance information entries is stored for reference.

Because the Payment Reference field may also contain remittance information, the trimming has also been updated for that field to use an ellipsis if the information is too long.

Parsing correction for camt.053

Issue: When both Dbtr and UltmtDbtr tags are present in a camt.053 file, FinDock incorrectly extracted account holder information. The data would be pulled from UltmtDbtr instead of Dbtr.

Solution: We have corrected the parsing rules to correctly handle this type of camt.053. The data is now pulled from the Dbtr tag as expected.

Adyen

Collected installments incorrectly set to failed

Issue: If a payer makes a mistake with the credit card number or CVC, Adyen sends a notification indicating the payment authorization failed. However, the same notification with different payload is used when the card information is corrected and the payment is processed successfully. If FinDock processed the latter notification first, then received the authorization failure, the collected installment would be incorrectly set to Failed. This would also lead to NPSP Opportunities being written off though the installment was collected.

Solution: If an installment is successfully collected, FinDock will now ignore a follow up inbound report indicating authorization failure. Non-final status failure messages for open installments will result in Pending status for installments. As an additional final failure status confirmation, FinDock will wait for the OFFER_CLOSE notification to permanently fail payments that are not completed in the allotted time.

Recurring payment setup error

Issue: During internal testing, we discovered that recurring payments could not be set up over the API integration with Adyen. The payment intent message from FinDock would lead to an error response from Adyen.

Solution: As part of the FinDock Sept. ‘22 release, we updated FinDock to use version 69 of the Adyen Checkout API. This new version included parameter changes that rendered the existing FinDock message structure incorrect. We’ve now updated the message structure to use the latest parameter specifications from Adyen. This issue did not impact current FinDock customers as none were using Adyen for recurring payments during this period.

Bacs DD with FinDock

First installment transaction code

Issue: For Bacs DD recurring payments, the first collection should use the transaction code 01. Though supported, the code was not being set correctly for the first installment.

Solution: A couple of issues in underlying logic prevented FinDock from adding the first collection code to the first payment as expected. This has now been resolved. The 01 transaction code is used if the Last Used date on the Mandate record for the recurring payment is empty, or if the Use first next run field on the mandate is true (checkbox is marked).

The solution includes a change in how the Last Used field on Mandate is updated. Prior to this release, it was set during the Generate step of a payment schedule. After this release, the field is updated in the Close step of the schedule (when installments are set to Collected).

Too many SOQL queries on upload of Bacs report to ProcessingHub

Issue: When, for instance, through an import of Bacs reports like ADDACS, many payment profiles were updated at once, ProcessingHub would show the error CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY: MDS_INBOUNDREPORTTRIGGER: SYSTEM.LIMITEXCEPTION: PAYBACS: TOO MANY SOQL QUERIES: 201.

Solution: The issue was caused by an inefficient SOQL query which has now been optimized to be able to handle a large number of updates & creates of Payment Profiles.

Buckaroo

Notification error due to long strings

Issue: If a Buckaroo notification includes very long string values, FinDock could not store them, leading to undelivered notifications to Notification Gateway.

Solution: FinDock now truncates long strings to allow for storage. The customer impact was minimal, with a small number of delayed notifications used to update Salesforce data. The payments themselves are still collected.

GoCardless

Disconnecting in sandboxes

Issue: Disconnecting the connection to GoCardless in a full-copy sandbox of a production org impacts the production org as well. This was due to the common connection settings and authorization, creating connection issues in both orgs.

Solution: We have enhanced the disconnect flow so that the connection settings in the sandbox org are cleared without impacting the production org.

Redsys

NEW - support for Bizum (BETA)

We are happy to announce the addition of Bizum, a Spanish mobile payment method, to the Redsys payment extension. For further information about the Bizum option at Redsys, please visit their website.

We are launching Bizum support in beta for open testing.

Target validation in ProcessingHub

Issue: FinDock required a target to be defined in ProcessingHub for Redsys, although this processor does not use a target with ProcessingHub.

Solution: We updated the target validation in ProcessingHub to exclude Redsys.

ProcessingHub update for payments initiated through payment schedules

Issue: Outgoing payment instructions to Redsys generated by PaymentHub could be rejected in certain scenarios.

Solution: The rejections were caused by missing or incorrect parameters in the message payload. We’ve now updated ProcessingHub to ensure the required parameters are included for the given payment method.

SEPA DD with FinDock

First installment code for recurring payments

Issue: For SEPA DD recurring payments, the first collection should use a specific code, FRST. This code, though supported, was not being set correctly for the first installment.

Solution: A couple of issues in underlying logic prevented FinDock from adding the first collection code to the first payment as expected. This has now been resolved. The FRST code is used if the Last Used date on the Mandate record for the recurring payment is empty, or if the Use first next run field on the mandate is true (checkbox is marked).

The solution includes a change in how the Last Used field on Mandate is updated. Prior to this release, it was set during the Generate step of a payment schedule. After this release, the field is updated in the Close step of the schedule (when installments are set to Collected).

Stripe

Support for initial payment in recurring payment setup

For recurring credit card payments, Stripe has an option to immediately collect an initial amount when setting up the new recurring payment. FinDock now supports this option through the FinDock Payment API with an additional payment method parameter, InitialPaymentonRecurring. This is at the moment only available for custom API integrations, not FinDock Giving Pages or PayLinks.

The new parameter is returned by the GET PaymentMethods endpoint. The returned options are:

• Required: The recurring payment setup must include a one-time payment block.
• Optional: The recurring payment setup may include a one-time payment block.
• No: The recurring payment setup must not include a one-time payment block.

This is a new generic parameter. However, currently Stripe is the only PSP among the supported payment processors that returns the Optional value.

Below is an example of an API callout (POST) message is InitialPaymentonRecurring required.

    {
      "Recurring": {
        "Amount": 10,
        "Frequency": "Monthly",
        "StartDate": "2023-01-01",
        "EndDate": "2024-01-01"
      },
      "OneTime": {
        "Amount": 10
      },
      "SuccessURL": "https://www.example.com/success",
      "FailureURL": "https://www.example.com/failure",
      "Payer": {
        "Contact": {
          "SalesforceFields": {
            "FirstName": "First",
            "LastName": "Last",
            "Email": "first.last@email.address",
          }
        }
      },
      "PaymentMethod": {
        "Name": "CreditCard"
      }
    }

With the introduction of the new parameter, we are deprecating the use of RecurringRequiresInitialPayment. This parameter will continue to work, but we encourage using the new parameter.

Installment status when payer enters incorrect card info

Issue: When paying with a credit card through Stripe, if the payer enters an incorrect number (and then corrects it), FinDock would set the installment to Failed even though the payment eventually is successful. This resulted in a failed installment with two inbound reports, one failed and one successfully matched to the installment.

Solution: This issue was caused by how FinDock handles the initial payment failure notification that is triggered when the incorrect information is entered in the Stripe Hosted Payment Page form. FinDock set the installment status to Failed, so the record could not be updated when the successful charge notification arrived. With this update, FinDock does not update the installment status based on the initial failure message, instead waiting for the final expiry notification before failing the installment (if no success message arrives in the meantime).

Disconnecting in sandboxes

Issue: Disconnecting the connection to Stripe in a full-copy sandbox of a production org impacts the production org as well. This was due to the common connection settings and authorization, creating connection issues in both orgs.

Solution: We have enhanced the disconnect flow so that the connection settings in the sandbox org are cleared without impacting the production org.

Heroku maintenance upgrades

Due to software lifecycle management requirements, we upgraded the REDIS component for FinDock apps on Heroku to ensure continued performance and support.