Skip to main content

Release Notes - April '20

We are happy to present the FinDock April ’20 Release.

Important Dates:

  • Release to Sandboxes: March 29, 2020
  • Release webinar: April 3, 2020
  • Release to Production: April 19, 2020

In this release, we have many new features, as well as important enhancements and bug fixes.

New features:

  • FinDock for the Italian market
    • Bollettino Postale processing
    • SEDA for SEPA payment extension
    • Axerve for FinDock payment extension
  • Significant improvements to the FinDock Payment API
    • Improved API error handling
    • Improved Payment API Performance
    • New Payment API support documentation
    • Webhook on Installment (Payment) status change in Payment API
    • Default Source Connector for API calls
    • Added Locale and iDEAL issuer parameters for Mollie
    • Fix: API token does not behave as expected
    • Fix: Origin and CampaignId field not properly mapped in API calls
    • Fix: Several issues with Account / Contact in the API
  • Real-time generation of Payment Schedules
  • Switzerland: Processing of PostFinanz CAMT.053 with payment slips

Enhancements and bug fixes:

  • Fix: Due Date on Installment and Close Date of Opportunity always the same
  • Fix: CAMT files not deduplicated across targets
  • Fix: Creating a Recurring Donation with Acceptgiro clears all Installment payment reference fields when 'Generate on Recurring Level' option is checked
  • Fix: Guided Matching job does not retry on locked row errors
  • Fix: Negative transaction booked as positive
  • Fix: Recurring Payment Schedule creates Payment Schedules with wrong status

FinDock for the Italian market​

FinDock now offers major new features for the Italian market:

  • Bolletino Postale (Postal Giro) processing
  • SEDA mandate management
  • Axerve as a PSP payment extension

Bollettino Postale (Postal Giro) processing​

It is now possible to generate Postal Giros (Bollettino Postale) for the Italian market with FinDock. FinDock generates a payment reference conforming official Italian standards. Pay slips payment references generated by FinDock can be easily reconciled through Guided Matching.

FinDock can also process Bollettino Postale reports downloaded from the Poste Italiane website. Files are downloaded in a ZIP file containing a CSV with a list of collected Postal Giro slips and, for certain report types, scans of the original Postal Giro pay slips. When upload to Chatter, FinDock parses the files and create Inbound Reports which can be reconciled through FinDock Guided Matching. Images are attached to the Inbound Reports.

To support reconciliation of Bollettino Postale reports downloaded from the Poste Italiano, we have created a specific set of Guided Matching rules. These rules help you automatically match or create new Salesforce and FinDock objects, as well as manually match records, for example, based on the attached scan of the original Bollettino Postale pay slip. You can also configure your own Guided Matching rules.

For further information, please see Bollettino Postale processing.

Axerve payment extension​

Axerve for FinDock is a new payment extension adding Axerve as a supported Payment Service Provider (PSP) in Italy. Axerve can be used for one-time and recurring payments with credit cards. For further information, including configuration instructions, see Axerve for FinDock.

FinDock also supports Multi-Merchant for Axerve for the Italian market. This means you can use more than one Axerve account with FinDock. For more information about Multi-Merchant, see Multi-Merchant accounts for PSPs.

SEDA for SEPA payment extension​

FinDock now supports the SEDA services. SEDA stands for SEPA-compliant Electronic Database Alignment. SEDA is an additional optional service (AOS) on top of SEPA, specifically used in the Italian market. The purpose of SEDA is to exchange the mandate-related information between the bank of the creditor (called the Alignment Bank in SEDA) and the bank of the debtor prior to the first debit collection. These exchanges are done via structured files, pain.009, pain.010, pain.011, pain.012. With FinDock we now fully support the SEDA services for both the incoming and the outgoing files. For more information, please see SEDA for SEPA payment extension.

Significant improvements to the FinDock Payment API​

In this release we have significantly improved our Payment API, aiming to expand its functionality, improve current functionality and make it easier to understand and use. We would like to thank all our customers and partners that provided feedback on the API for their input!

New Payment API support documentation​

To help you use the FinDock Payment API, we have created new support documentation, including:

  • Details about resources, objects, parameters and messages in our new API reference guide based on a OpenAPI specification file.
  • A new getting started article to give you a clear overview of the steps needed to start using the API
  • A how-to article that shows you some of the basic use-cases with example messages
  • A troubleshooting guide covering common issues and helpful tools for debugging

Please do not hesitate to let us know if you are unable to find an answer to a question you have or would like our help developing on the Payment API.

Improved API error handling​

To make debugging easier, we have improved error handling in the Payment API. In addition to small improvements to error handling and error messages in the FinDock code, we have:

  • Expanded the response of the API when ‘verbose = true’ is set in the request header with the original stack trace. This enables you to narrow down the origin of the error to a package (e.g. FinDock, NPSP, standard Salesforce, Custom Apex), class and line. This gives you more details you can provide to our support team for root cause analysis.
  • Added a API troubleshooting article with tips & tooling to our knowledge base.

Example response message with ‘verbose = true’:

    {
        "ResponseCode": "999",
        "IsSuccess": false,
        "Error": {
            "error_message": "Invalid request. Please read the documentation or contact support.",
            "error_code": "999",
            "typeName": "API_Request_Base.ApiException",
            "stackTraceString": "Class.API_Payment_POST_V1_0.determinePaymentMethodAndEnrichRequestIfRequired: line 113, column 1\nClass.API_Payment_POST_V1_0.getPaymentMethodNameForPSP: line 37, column 1\nClass.API_Payment_POST_V1_0.validateRequestParameters: line 572, column 1\nClass.API_Payment_POST_V1_0.prepareData: line 246, column 1\nClass.API_Payment_V1_0.postPayment: line 69, column 1",
            "lineNumber": 113
        }
    }

For more information on error handling in the API, please visit our new API reference guide.

Webhook on Installment (Payment) status change in Payment API​

To further aid integration with the FinDock API, we added a new webhook implementation, which fully replaces the old webhook functionality. If you include a URL in the WebhookURL parameter of the RequestBody, you receive a notification when the status of the Installment created with this request is updated, with the below message body. The message includes actual Payments made on the Installment, so the full history of the payment request can be followed. 

    {
        "Url": "/services/data/v36.0/sobjects/Installment__c/a083E00000AG04mQAD",
        "Type": "Installment__c",
        "Id": "a083E00000AG04mQAD",
        "Target": "Target Name 1",
        "Status": "Collected",
        "Payments": [
            {
                "Url": "/services/data/v36.0/sobjects/Payment__c/a0R3E000008WvL9UAK",
                "Type": "Payment__c",
                "Id": "a0R3E000008WvL9UAK",
                "Target": "Target Name 1",
                "PaymentProcessor": "Mollie-for-PaymentHub",
                "PaymentMethod": "ideal",
                "CollectionDate": "2020-03-26",
                "Amount": 100
            }
        ],
        "PaymentProcessor": Mollie-for-PaymentHub",
        "PaymentMethod": "ideal",
        "Amount": 100
    }

For more information on the webhook, please visit our new API reference guide.

Default Source Connector for API calls​

If you have more than one Source Connector in use with FinDock in your org, you can now define which one should be use as the default source for API calls. If no source is defined in a Payment API request, the default Source Connector is used to process the payment. Define the Default Source Connector in the FinDock PaymentHub Setup.

note

This setting is currently only used by the API.

Default Source Connector setting

Locale and iDEAL issuer parameters for Mollie​

We have added two additional parameters to the API for the Mollie payment extension:

  • locale : sets the language of the payment page hosted by Mollie
  • issuer : deep-links the user into the specified banking website for iDEAL payments, skipping the selection screen

These parameters can be added to the ParameterMap object when performing a payment through the API with Mollie as processor. For more information on the purpose and use of the parameters, please refer to the Mollie API documentation.

Fix: API token does not behave as expected​

Problem: We fixed two API token bugs: one allowed a revoked API token in GET requests, and another caused an API token check to be insensitive. Solution: We identified and fixed the reasons for these to API token behaviors. But please note: Salesforce is limiting the capabilities of this authentication method. We strongly recommend changing your API authentication to the Oauth2 flow as described in our API Reference Guide.

Fix: Origin and CampaignId field not properly mapped in API calls​

Problem: The Origin field in an API request, used to indicate a origin of the payment like web form or campaign, was incorrectly populated. Solution: The Origin filed is now correctly populated with the desired value. In addition, we mapped CampaignId in the API request to the Originating Campaign field on Installment:

  • Origin → Installment c.Origin c
  • CampaignId → installment c.Originating_Campaign c

This removes the need to add Originating_Campaign__c to the CustomFields section of the API request body.

Fix: Several issues with Account / Contact in the API​

Problem: There were several issues with the way Account and Contact were handled in the API with regards to:

  • creation of new records
  • updating existing records
  • linking/relating accounts & contacts to each other
  • linking/relating accounts and/or contacts to other records

Solution:

  • Resolved certain cases of double accounts when NPSP is source and Account object is included in the API request
  • No longer create new account when both a new contact and an account object are included in the API request with Source NPSP. Previously, the Payment API would create an account based on the details in the request and NPSP would create an account based on the new Contact, leading to two accounts.
  • Resolved cases of relating both Contact and Account to Installment even though PrimaryRelation was set only to Account

For more information on the behavior of the Account & Contact objects in the API, please visit our new API reference guide

Real-time generation of Payment Schedules​

FinDock now starts generating of payment schedules in real-time, instead of after three minutes as previously. This means you can immediately see whether your run was started successfully after clicking the Start Generation button. Since the generation now starts instantly, you no longer see the intermediate ‘Success’ page with the 3-minute notification if you use Salesforce Lightning. You can instead view the status of your run in the Payment Schedule Path at the top of the record.

note

To prevent conflicts, it is not possible to run a Payment Schedule when another schedule is in the Generating phase.

Switzerland: Processing of PostFinanz CAMT.053 with payment slips​

FinDock now processes CAMT.053 with payment slips from PostFinanz in the same way it processes CAMT.054 files with payment slips for Switzerland. For more information on reconciling CAMT statements with payment slips, please see this article.

Real-time generation of Payment Schedules​

FinDock now starts generating of payment schedules in real-time, instead of after three minutes as previously. This means you can immediately see whether your run was started successfully after clicking the Start Generation button. Since the generation now starts instantly, you no longer see the intermediate ‘Success’ page with the 3-minute notification if you use Salesforce Lightning. You can instead view the status of your run in the Payment Schedule Path at the top of the record.

note

To prevent conflicts, it is not possible to run a Payment Schedule when another schedule is in the Generating phase.

Enhancements and bug fixes​

Fix: Due Date on Installment and Close Date of Opportunity always the same​

Issue: Fixed a bug where the Due Date of the Installment and the Close Date of the Opportunity were always synced to the same value by FinDock.

Solution: When the Opportunity is open the Opportunity Close Date is synced to the Due Date on the Installment. When the Opportunity is closed, Close Date and Due Date will not be synced anymore.

Fix: CAMT files not deduplicated across targets​

Issue: Fixed a bug where CAMT files were not deduplicated when they were linked to different targets

Solution: CAMT files now have the same message ID across different targets, and will thus be deduplicated automatically by FinDock.

Fix: Creating a Recurring Donation with Acceptgiro clears all Installment payment reference fields​

Issue: Fixed an issue where all Payment reference fields on Installments related to a Recurring Donation were cleared when the option Generate on Installment Level was set for Acceptgiro.

Solution:

  • Added new field on Installment ‘Recurring Payment Reference’ which stores the payment reference from the Recurring Donation.
  • Changed formula ‘Final Payment Reference’ to also take ‘Recurring Payment Reference’.

Fix: Guided Matching job does not retry on locked row errors​

Issue: Guided Matching did not initiate a retry when a locked row exception was thrown.

Solution: FinDock now keeps retrying until the job no longer throws locked row exceptions. On Sandboxes , the maximum of number of retries is limited to five. After five unsuccessful retries, Salesforce responds with error “Maximum stack depth has been reached”.

Fix: Negative transaction booked as positive​

Issue: Negative transaction amounts could result in positive Opportunities in NPSP.

Solution: The source of this bug was identified and fixed so that negative amounts remain negative.

Fix: Recurring Payment Schedule creates Payment Schedules with wrong status​

Issue: Recurring Payment Schedule created Payment Schedules with status 'new' instead of 'scheduled'.

Solution: This bug caused Payment Schedules to be ignored by the PaymentScheduleSchedule Apex job, but it has been fixed now so created schedules have the correct status.