Skip to main content

Release Notes - July '19

We are happy to present you the PaymentHub July ’19 Release Notes. This release mainly contains bug fixes and minor enhancements. There are no manual actions required to enable features in this new release.

Important Dates:

  • Release to Sandboxes: June 30, 2019
  • Release to Production: July 13, 2019

Enhanced processing of Customer Payment Status Report - Pain.002​

In a “Customer Payment Status Report” (pain.002) a bank informs his customer about the status (e.g. rejection, acceptance) of initiated credit transfers or direct debits. The usage and availability of pain.002 is subject to individual agreement between the account holder and his bank. With Paymenthub we already supported the processing of pain.002 files but we made three upgrades to the existing functionality:

  1. Create negative payment on rejection
  2. Storing of the reported information in inbound reports
  3. Update ‘Last Reversal Date’ on installment when transaction is rejected

How to enable

No actions needed. These processes are working as described above automatically when a pain.002 file gets uploaded to Chatter. You can monitor the detailed steps and processes via the ProcessingHub Manager.

Create negative payment on rejection​

When a transaction is reported as rejected in the pain.002 file then instead of deleting the original payment we now create a (second) negative payment attached to the same installment to account for the rejection. This behaviour is consistent to how we already handle reported reversals from the bank statement files. The existing functionality around the installment status and reason code is still the same.

Storing of the reported information in inbound reports​

Inbound reports are used to store the information from the reports into structured, separate records in Salesforce. When the pain.002 file is uploaded to Chatter first the file is parsed from the file into inbound reports. Then we run our pain.002 logic over these records and update the inbound reports and possibly installments and payments accordingly. When the process is done on the ProcessingHub you can find the inbound reports in Salesforce. The status of the inbound report records will give insight into the processing that has been done. Inbound reports are Salesforce data and give you the ability to extent our pain.002 processing with custom business logic.

Update ‘Last Reversal Date’ on installment when transaction is rejected​

When an installment is set to ‘rejected’ via a pain.002 rejection then we update the ‘Last Reversal Date’ on the installment and leave the “Last Collection Date” as is.

Initiating Party available in SEPA Target definition​

When generating the SEPA Direct Debit pain.008 file we use the SEPA target information to create the correct header. In the groupheader the ‘InitgPty’ tag is mandatory by ISO 20022 & SEPA and currently we fill ‘InitGPty / Nm’ with the reported name on the SEPA target. Per bank there could be additional requirements on top of the SEPA xsd. In order to comply with these requirements we added two new attributes to our SEPA target:

  • GroupHeader - Initiating Party - OrgId (text field)
  • GroupHeader - Initiating Party - SchemeName (picklist ‘CORE’ | ‘CUST’)

When these attributes on the target are empty then we generate the header exactly as we do now. But when both of these are given a value then we take those into account during generation and we add those correctly to the Initiating Party tag inside the groupheader.

SEPA target settings

How to enable

No actions needed.

Redsys​

Redsys for PaymentHub is now available as a new package. This package supports recurring credit card payments as a payment method.

How to enable

No actions needed.

Create installment on insert of closed-won opportunities with PaymentHub-for-NPSP​

We updated our PaymentHub-for-NPSP connector to create an installment and a payment when a closed-won opportunity is created. The open amount on the installment will be ‘0’. We take into account the excluded record types as we already do for open opportunities. This is can be needed when e.g. a gift in cash is coming in and is registered by creating a closed/won opportunity with the payment method ‘cash’ in the system. When this gift would be Gift Aid collectible then there also needs to be the attached installment for the Gift Aid functionality to operate correctly.

Closed won Opportunity

How to enable

This feature can be enabled or disabled via a setting in your Payment-for-NPSP setup page. To avoid unexpected new behaviour with current implementations, current customers need to opt-in into this setting. On new installs this setting is automatically turned on. It can be turned on or off anytime via the setup page.

Payment API - connect payment and recurring​

When a new recurring credit card is processed through the PaymentHub API, many payment service providers require an immediate payment as authentication in the same API call. We now link this initial payment to the recurring payment in Salesforce. This gives the complete overview on the recurring payment. This behaviour is consistent regardless the source connector on top of PaymentHub.

How to enable

No actions needed.

Enhancements​

Pain.008 generated with UTF-8 encoding​

Description: Our pain.008 generator didn’t cast the Salesforce to UTF-8 as required.

Solution: When the pain.008 file is generated non UTF-8 characters are cast into their UTF-8 equivalent.

N43 mapping update​

Description: We didn’t map the bank & branch code from the N43 header to the transaction set.

Solution: A new field is added to the transaction set: cpm__BIC_Code__c. The N43 mapping is updated to fill this field with a concatenated string of bank code + branch code.

C72: MandateUpdate added as picklist value in field 'Report Type' on Inbound Report​

Description: Processing a C-72 fails because the value ‘MandateUpdate’ was put into the restricted picklist ‘Report Type’ on the inbound report object that didn’t allow this value.

Solution: The value ‘MandateUpdate’ is added to the field ‘Report Type’ on the inbound report including the correct dependencies to the dependent picklist field ‘Report SubType’.

Default custom payment method during manual review​

Description: When in the manual matching setup a custom payment method was chosen as the default payment method for manual matching then this could fail during the manual review process.

Solution: Instead of the api name we now set the label name of the payment method on the transaction set. This makes sure the default values will also work on any custom payment method during manual review.

Improved processing order of the ARUDD report​

Description: When processing an ARUDD report we first insert the negative payment and then we update the status of the installment. This leads to issues with the installment trigger in NPSP. The installment is flagged on open amount update and therefore will not update the status on the opportunities when that is processed.

Solution: By changing around the order of the processing of the payment and the installment all the correct processes are triggered and will be run in good order.