• Past releases
  • ›
  • 2019

Release Notes - April '19

We're very happy to present you the PaymentHub April '19 Release Notes. In this article we offer an overview of all new features and bug fixes in this release. Please be aware manual actions are required to take advantage of the near real-time queueing mechanism, these three actions can be found under "Near real-time queueing mechanism for PSP callbacks".

Important Dates:

  • Release to Sandboxes: April 6, 2019
  • Release to Production: April 20, 2019

PaymentHub

Near real-time queueing mechanism for PSP callbacks

All PaymentHub internal queueing is now near real-time. This applies to PSP callbacks and all hand-overs to ProcessingHub. Only exception is the manual start generation of a payment schedule, which takes around 3 minutes to start.

For PSP callbacks ProcessingHub queuing is used and the actual processing of the callback is initiated through an API call and counts against the Salesforce API limit. The callback is processed under the PaymentHub integration user. For work hand-overs to ProcessingHub through the Message object Apex queueing is used. Customer actions after release:

  1. The “ProcessingHub Operations” permission set must be assigned to the site guest user and to the users that trigger salesforce jobs (mandate schedule, payment schedule, file upload).
  2. Schedule “Payment Messages Monitor” job to run every hour:
    1. Open developer console
    2. Open Debug > Open Execute Anonymous Window
    3. Copy-paste: System.schedule('PaymentHub Messages Monitor', '0 0 * * * ?', new proh.MessagesCleaner());
    4. Click Execute
    5. Go back to Salesforce and go to Setup > Environments > Jobs > Scheduled Jobs
    6. Validate that you see a scheduled job with name “PaymentHub Messages Monitor”
  3. Delete QueueProcessor and/or QueueProcessorInbound from scheduled jobs:
    1. Go to Setup > Environments > Jobs > Scheduled Jobs
    2. Delete each row with name QueueProcessor or QueueProcessorInbound

Lookup filters on lookups to payment profiles

Relationships on Recurring Payment and Installment to Payment Profile now have an optional lookup filter restricting the options to the payment profiles that have the same Contact or Account as the master record.

Lookup filters on lookups to mandates

Relationships on Recurring Payment and Installment to Mandate now have an optional lookup filter restricting the options to the mandates that have the same Payment Profile as the master record.

Default payment method for manual review

It's now possible to define the default payment method for manual review. If this default is set, this value will be used as default for all transactions in manual review. Having this value set allows the ProcessingHub to automatically set the Payment Processor and Target. We see two uses of this field: 1. Set the default payment method to the most used payment method, e.g. "Direct Debit". Downside of this approach is that some transactions will be wrongly classified. 2. Introduce a custom payment method "Unknown" and use that as default. This approach doesn't take away the need for manual payment method classification, but does allow the ProcessingHub to set the Payment Processor and Target.

Adyen for PaymentHub

PaymentHub now supports Adyen as Payment Service Provider. The following payments methods are supported: creditcard single, creditcard recurring, Ideal, Sofort and Bancontact.

Adyen MOTO

ProcessingHub now supports Adyen MOTO. Customer call center agents can use this to take in creditcard payments (single and recurring) over the telephone. The solution consists of a Lightning Component that exposes the Adyen MOTO functionality. The component can be placed on any page related to an Installment, Opportunity, Recurring Donation, Recurring Payment (PaymentHub) and Agreement (Converse).

ProcessingHub

MT940 NatWest

PaymentHub now supports processing MT940 files that are generated by National Westminster Bank using the Bankline Swift MT940-2012 export functionality.

CODA

PaymentHub now supports processing multiple statement CODA files. CODA is a multiple statement file using in Belgium that contains movements for accounts. Movements will be handled in the following way:

  • If it is a credit transaction for which a outstanding installment is found, the installment is set to collected and a payment is created.
  • If it is a debit transaction and a matching collected installment is found, the installment will be reversed and a negative payment will be created.
  • If no matching installment can be found, the transaction needs to be picked up in manual review. Restrictions:
    • The system assumes that the account numbers always have the format IBAN + BIC
    • Only movement records of type 2 are processed. Details will be skipped.

Prefill target & payment processor on a transaction set

System now pre-fills target & payment processor on a transaction set. This is supported for CAMT.053, CODA, MT940 and N43.

PaymentHub for NPSP

Lookup filters on lookups to payment profiles (NPSP for PaymentHub)

Relationships on Recurring Donation and Opportunity to Payment Profile now have an optional lookup filter restricting the options to the payment profiles that have the same Contact or Account as the master record.

Lookup filters on lookups to mandates (NPSP for PaymentHub)

Relationships on Recurring Donation and Opportunity to Mandate now have an optional lookup filter restricting the options to the mandates that have the same Payment Profile as the master record.

Bug Fixes

PaymentHub

Field Custom Payment Reference too small

Size of Installment Custom_Payment_Reference__c field has been increased from 50 to 255 characters to allow for longer payment references in Germany.

Installment is not created when debit transaction is manual matched in bulk mode

Solved manual review issue that an installment is not created when a debit transaction is manual matched in bulk mode.

ProcessingHub

Pain.002 file processing with reversed installment stops after recognition

Following bug is fixed. Steps to reproduce:

  • Create a recurring payment and run a payment schedule
  • Open the generated pain.008 and adjust attached file so that file and batch ids match
  • Reverse the installment and set to pending recollecting
  • Upload file.

Expected and new result:

File recognized and processed. Error in Chatter and paymentHub file: "installment X does not have status Collected"

Old result:

File recognized as: PAIN.002

PaymentHub for NPSP

NPSPRecurringJob doesn't respect additional SOQL on Payment Schedule

For NPSP customers It is now possible to add an additional SOQL statement to adjust the selection for a payment schedule. This additional SOQL statement will be added to the where clause that filters installments. For example, by adding the clause “and cpm__amount__cc >5”, only installments with amount greater than 5 euro will be added to the payment schedule.

Was this page helpful?