On our Setup page we have added an “Activate” button. Pressing this button activates PaymentHub and allows the configuration of PaymentHub using the Setup page. Once PaymentHub is activated statistical usage is shared with StepOrange. The collection of this data is contractually agreed and consists only of the number of positive and negative payments.
Given the importance of security, PaymentHub can now be installed under Salesforce Shield. PaymentHub can now handle Shield platform encryption of standard Salesforce objects.
Users can now configure the behavior if a single transaction in a bank statement matches against multiple Installments. Based on the configuration our engine will match against the Installment with the oldest due date, the latest due date or the transactions requires manual review. For certain customers this will further reduce the number of transactions requiring manual review.
We now support to option to automatically match a “batch” of Installments against a single transaction in a bank statement. Primary use case is when a bundle of checks is paid out in a single transaction by the bank. This feature requires to have the installments grouped before matching is started.
For each Gift Aid claim file sent to HMRC, PaymentHub will upload a copy of the file and the digital receipt received from HMRC is uploaded to Chatter. This allows for improved archiving by the customer. In addition, when set to “Test mode” all interactions, including status requests, with HMRC are uploaded to chatter allowing for easier (UAT) testing.
We have added Stripe as new PSP to support one-off credit card payments via Stripe the Payment API.
We have created two new permission sets called “PaymentHub Operations” and "ProcessingHub Operations". These permission sets are limited to the permissions needed to use:
- Payment Schedules
- Mandate Schedules
- Manual File Exchange
- Manual Review / Review Transactions
Giving users this permission set ensures that users can keep performing their daily operational tasks even when we add new fields to objects without the need to grant everybody the “Payment Hub All FLS” permission set. Please note that permissions on objects in source packages such as Opportunities in NPSP are not part of these permission sets and might still need to be allocated using other permission sets or via the profile for certain tasks to be completed.
Several changes are made to better handle the Lloyds specific implementation of MT940, including concatenating multi-statement messages in a single file into a single Transaction Set.
If a bank statement transaction is for a higher amount than the open amount of the matched Installment, the user can pre-define the automated handling. The available options are to book everything on the Installment, book the remaining amount on the next matching Installment or make the transaction available for manual review.
When generated BACS DDI files or Collection files are uploaded to Chatter, the Chatter message is updated to refer to the payment schedule or mandate schedule from which the file was generated. Allowing users to easily recognize the files that are in the designated chatter group.
In order to be in line with HMRC specifications, the Charity regulator names on a Gift Aid target are validated, allowing only the acronyms of the 3 UK regulators.
Since we do not include “Title” in a Gift Aid claim towards HMRC, we have removed this field from the Gift Aid Declaration page layout.
The BIC code is no longer a mandatory field on Payment Profiles. If a Payment Profile without BIC is used to create a SEPA Direct Debit file the value ”NOTPROVIDED” set in the field specified by the European Payment Council in order to be in line with SEPA regulations.
In some CORS scenarios, the header “api_token” was not recognized as an accepted header value, to this end we have added “api-token” as an alias.
No further action is needed if your current integration works as expected
When we create a payment based from a bank statement we now link it to the Target for which we have processed the statement instead of the Target mentioned on the Installment. As a result, the payment is now linked to the Target where the actual cash flow takes place.
We have updated the mail templates used to communicate user credentials for the setup of ProcessingHub. The new mail template does not only look a lot better, it now also includes the name of the organisation and a link to the log in page. This is especially useful for System Integrators implementing multiple customers.
In the setup page of ProcessingHub we now show if OAUTH has been setup from our engine towards Salesforce. This improvement makes trouble shooting of this common error a lot easier for us, resulting in a faster response to you.
Installments with the same mandate and date are now correctly aggregated into a single collection.
For CAMT messages the reported reason code for reversed transactions is now shown on both Transaction and Installment.
For transaction from CAMT messages Transaction lookup on Payment is now filled with correct data.
When an API request contains an invalid BIC we now return the BIC which failed in the error message to allow for better troubleshooting.
The name of a Recurring Donation can now the set via our API. If no name is set we use “Recurring + Contact.lastname” as a fall back value.
Several spelling errors have been corrected.