Release 2.1.0

Payment Gatway Service Integrations

A high level sequence flow between the systems are below

In some cases, the Worldpay CheckPayment response is not being received by the DTT infrastructure, some reasons for this could be

• a) User has closed the browser
• b) User’s network connection was lost
• c) User’s browser session timed out
• d) There is an error in the response or processing of the check payment response which we cannot see.

In the case of the scenarios above, there is no client for the response to return to, therefore subsequent processing is prevented.

The business have raised a concern that in sone of these cases, as the customer does not know the outcome of the payment transaction, duplicate transactions are created. Changes that have been made to mitigate the risk of duplicate transactions these are

Note

Its is important to note that in the majority of the scenarios above, there is no active secure client for Worldpay to return the response to, therefore there is no way that the Payment Gateway service to capture and manage this response through to the success or failure urls configured.Therefore only Worldpay knows and can communicate the status of the payment at this stage.

Configure Worldpay to send a payment outcome email to the user

The Payment Gateway service and api has been updated to optionally accept a shopper email in the initpayment call. This email is passed onto Worldpay.

Note

Consumers of the Payment Gateway service API may have to update their code to pass the shopper email if they require this feature

If Worldpay merchant configuration has been updated, Worldpay will send a payment receipt email to the shopper email supplied for the merchant channel events configured

• The Email field in configuration can optionally be used for a business area mailbox to recieve a copy of the receipts sent to the customer
• The Shopper email field in configuration should be set to Yes if the shopper email is being passed to the Payment Gateway service
• The Merchant Channel Events shopper email configuration should be set to enable the shopper email for status updates eg - Authorised and Refused

Improved Status History

The Status history for a payment transaction can now be seen on the Payment transaction details page as below

For the vast majority of payments the status movements will be as above. The payment above has been updated by the CheckPayment method called successfully from the client on the Worldpay response.

Update Status Web Job

In some cases, for the reasons discussed above, Worldpay has not been able to respond successfully to the client and the CheckPayment method has not been able to update the status of the payment and redirect the user to the configured success/failure payment pages.

A Web Job has been implemented to poll Worldpay for status updates on payments every 10 minutes. The Job will pick up the latest 10 Pending Authorization Payment transactions older than 30 minutes (to give users time to complete the payment) but not more than 1 hour. These parameters are configurable and can be adjusted if required.

Admin can identify a transaction which has been updated this way from within the payment transaction, these transactions will have an action of UpdatePendingAuthorization rather than CheckPayment:

Abandoned Payment transactions, where the user has dropped out at the Payment Page, will stay at a status of PendingAuthorization.

Reconciliation Reports

Reports have been provisioned on the Payment Gateway service to enable admin to quickly identify Payments that have been updated by the WebJob rather than the CheckPayment

Timezone Dates

Worldpay only process payment dates in GMT. The Payment Gateway has been updated to reflect the timezone changes on Payment dates

Performance

Performance updates have been made to ensure Payment transaction lists return to the client including:

• Server side paging
• SQL tuning
• Batch processing