worldpay oracle commerce plugin implementation guide

Corporate Gateway

Worldpay Oracle Commerce Plugin Implementation Guide V11.2.0 January 2017

Use this guide to:

Integrate your Oracle Commerce implementation with the Worldpay Payment Gateway using the

Worldpay plugin

Configure order notifications

Create and test Worldpay orders

Access Worldpay’s Corporate Gateway functionality through one simple integration

Worldpay Oracle Commerce Plugin Implementation Guide > Contents

Contents

Introduction ........................................................................................................... 5

1.1 Who is this guide for? ................................................................................................... 5

1.1.1 Skills and knowledge ...................................................................................................... 5

1.2 More help? ................................................................................................................... 5

1.3 Legal............................................................................................................................. 6

1.4 Version History ............................................................................................................. 7

1.5 Assumptions ................................................................................................................. 7

1.6 Integration Prerequisites .............................................................................................. 7

Overview ............................................................................................................... 9

1.7 Design Diagrams ........................................................................................................... 9

1.7.1 Direct Model - Payment input on Oracle Commerce Store pages ................................ 9

1.7.2 Redirect Model - Payment input on Worldpay pages ................................................. 10

1.8 Plugin Distribution Structure....................................................................................... 10

1.9 Example CSA Installation ............................................................................................ 11

1.10 Installing the core plugin modules .............................................................................. 11

1.11 Installing the CSA example modules ............................................................................ 12

1.12 Fundamental Concepts ............................................................................................... 13

1.13 Hosted Payment Pages ............................................................................................... 14

1.14 Client-Side Encryption ................................................................................................ 14

1.15 Card Tokenisation ....................................................................................................... 14

1.16 Committing an Order in Oracle Commerce .................................................................. 14

1.17 Partial process order pipeline ..................................................................................... 15

1.18 Payment Groups and Processors ................................................................................. 15

1.19 Merchant Code Mapping ............................................................................................ 16

Worldpay Oracle Commerce Plugin Implementation Guide > Contents 3

1.20 Completing An Order .................................................................................................. 17

1.21 User Locale ................................................................................................................. 17

1.22 Worldpay URL Builder................................................................................................. 17

1.23 XML Marshaling.......................................................................................................... 18

Implementation Guide ......................................................................................... 20

1.24 Commerce Site Integration ......................................................................................... 20

1.25 Tokenisation ............................................................................................................... 24

1.25.1 Creating Tokens............................................................................................................ 24

1.25.2 Token Scope ................................................................................................................. 24

1.25.3 Persisting Tokens ......................................................................................................... 24

1.25.4 Paying with Tokens ...................................................................................................... 25

1.25.5 Updating saved tokens ................................................................................................. 25

1.25.6 Deleting saved tokens .................................................................................................. 26

1.26 Customer Service Center Integration ........................................................................... 26

1.26.1 Direct Model ................................................................................................................ 27

1.26.2 Redirect Model ............................................................................................................. 27

1.26.3 Page Alterations ........................................................................................................... 27

1.26.4 Changes Required For Payment Group Availability ..................................................... 27

1.26.5 Returning From Worldpay Redirection ........................................................................ 28

1.26.6 Viewing orders ............................................................................................................. 28

1.26.7 Cancellations ................................................................................................................ 29

1.26.8 Refunds ........................................................................................................................ 29

1.27 Fulfilment ................................................................................................................... 30

1.27.1 Request For Capture .................................................................................................... 30

1.28 Order Notifications ..................................................................................................... 31

1.28.1 Dynamo Messaging System ......................................................................................... 31

1.28.2 Notification Processors ................................................................................................ 34

1.28.3 Authorisation Processor ............................................................................................... 34

1.28.4 Capture Processor ........................................................................................................ 35

1.28.5 Cancelled Processor ..................................................................................................... 35

Worldpay Oracle Commerce Plugin Implementation Guide > Contents 4

1.28.6 Refunded Processor ..................................................................................................... 35

1.28.7 Refused Processor ........................................................................................................ 35

1.28.8 Refund Failed Processor ............................................................................................... 35

1.28.9 Sent For Refund Processor ........................................................................................... 35

1.28.10 Other Functionality ...................................................................................................... 36

1.28.11 Add Back Office Code ................................................................................................... 36

1.28.12 Gateway Proxy Configuration ...................................................................................... 36

1.28.13 Customisation .............................................................................................................. 36

1.29 Further Development ................................................................................................. 38

1.29.1 How To Add An Alternative Payment Type ................................................................. 38

1.30 How To Add A New Payment Type for The Direct Model ............................................. 38

1.30.1 Customisation .............................................................................................................. 40

1.30.2 How to Switch REST Implementations ......................................................................... 40

1.30.3 How to Implement Iframe Checkout ........................................................................... 42

1.30.4 How to Implement Client Side Encryption ................................................................... 42

1.31 Populating the payment group ................................................................................... 44

1.31.1 Taking payment ............................................................................................................ 44

1.31.2 Accessing card details after payment .......................................................................... 44

1.31.3 Existing Module Structure ............................................................................................ 44

1.31.4 Creating a New Implementation .................................................................................. 45

1.31.5 Implementation of the WorldpayGateway .................................................................. 45

1.31.6 Implementation of the WorldpayClientBuilder ........................................................... 45

1.31.7 Amendments to web.xml ............................................................................................. 45

1.31.8 Connection Endpoint Caching ...................................................................................... 47

Appendix A: Software End User License Agreement ......................................... 49

Appendix B: Changes to this Guide ................................................................... 51

Worldpay Oracle Commerce Plugin Implementation Guide > Introduction 5

Introduction

The Worldpay plugin is an Oracle Commerce module providing an interface between the Worldpay Payment Gateway and an Oracle Commerce implementation.

The plugin supports authorisation transactions in both Worldpay's Direct and Redirect models, and Order

Modifications for Request for Capture, Cancellation and Refunds. It also facilitates the update of order

statuses through an Order Notification component.

1.1 Who is this guide for?

This is a technical integration guide, aimed at:

System integrators

Retailers and brands

Other technical roles, including managers who are involved in designing and managing your

integration

1.1.1 Skills and knowledge

To carry out the tasks described in this guide, you will need:

XML programming skills

A knowledge of HTTPS

Some knowledge of how our payment services work

For more information about our products and services, including payment methods, go to our

website at http://www.worldpay.com at the end of this guide.

1.2 More help?

For more information about our products and services, including payment methods:

See our website at http://www.worldpay.com

Talk to your dedicated Relationship Manager or Business Development Manager

For technical guides and developer resources (including our DTD) see:

http://www.worldpay.com/support/gg/

To contact Global Partnerships:

Email: [email protected]

http://www.worldpay.com/

http://www.worldpay.com/support/gg/

mailto:[email protected]


1.3 Legal

©Worldpay 2017. All rights reserved.

This software and documentation is subject to agreement of our end user license agreement ("agreement")

which is between you (both the individual downloading and/or installing the software and any legal entity

for which the individual is acting) ("you" or "your") and worldpay (uk) limited ("worldpay").

Taking any step to set up, download or install the software means that you accept all of the terms of this

license agreement. Permission to download, install and/or use the software is expressly conditioned on you

following these terms. If you do not agree to all of the terms of this agreement, you are not authorised to

use the software and must stop installing it or uninstall it, as applicable.

This software is to be used solely in connection with the third party software and you must satisfy yourself

that this software is suitable for your needs and that your system satisfies the requirements for the use of

this software as set out in the documentation.

Our End User License Agreement can be located within the appendix of this guide.

This document and its content are proprietary to Worldpay and may not be reproduced, published or

resold. The information is provided on an “AS IS” basis for information purposes only and Worldpay makes

no warranties of any kind including in relation to the content or suitability. Terms and Conditions apply to

all our services.

Worldpay (UK) Limited (Company No: 07316500/ FCA No: 530923), Worldpay Limited (Company No:

03424752 / FCA No: 504504), Worldpay AP Limited (Company No: 5593466 / FCA No: 502597). Registered

Office: The Walbrook Building, 25 Walbrook, London EC4N 8AF and authorised by the Financial Conduct

Authority under the Payment Service Regulations 2009 for the provision of payment services. Worldpay

(UK) Limited is authorised and regulated by the Financial Conduct Authority for consumer credit activities.

Worldpay, the logo and any associated brand names are all trade marks of the Worldpay group of

companies.


1.4 Version History

This makes the assumption that the renaming in the codebase has been carried out.

1.5 Assumptions

It is assumed that the reader is familiar with Oracle Commerce platform and the Commerce Store

Accelerator. The implementation guide also assumes knowledge of the Worldpay Corporate Gateway and

the following concepts:

Worldpay XML Direct Integration

Worldpay Redirect Integration

Worldpay Tokenisation

Worldpay Client-side Encryption

Alternative Payment Methods

3D Secure Process

1.6 Integration Prerequisites

The plugin is intended for use on either an Oracle Commerce store or Oracle Commerce Customer Service

Center 11.2 installation.

Minimum Java version: JDK 1.7.

Worldpay Configuration

The following actions should be performed to allow the plugin to interface with Worldpay.

Action Description Actor

Account Set-up A general Worldpay account should be created to house all Merchant

Codes

Worldpay

Merchant

Codes

Should be defined as advised by Worldpay Worldpay

Note all references to WorldPay in this document have been replaced with Worldpay (note the case

difference). This includes references to class/java files.


MAC Code A common shared secret should be entered for each Merchant Code

within Worldpay's admin interface

System

Integrator

Order

Notification

An address should be defined for order notifications from Worldpay

within Worldpay's admin interface

System

Integrator

Worldpay Oracle Commerce Plugin Implementation Guide > Overview 9

Overview

The Worldpay plugin is an Oracle Commerce module to provide an interface between the Worldpay

Corporate Payment Gateway and an Oracle Commerce implementation. It

supports authorisation transactions in both Worldpay's Direct and Redirect models and Order

Modifications for Request for Capture, Cancellation and Refunds. The plugin also facilitates the update of

order statuses through an Order Notification component.

The plugin is structured into two parts:

1. A Worldpay plugin module which is used for all communication to Worldpay's Gateway.

2. An example Commerce Store Accelerator (CSA) integration which provides a reference to how the

plugin can be integrated with both an Oracle Commerce Store and the Oracle

Commerce Customer Service Centre (CSC). The example CSA integration is supplied with source code so

that a System Integrator can understand the intended usage of the Worldpay plugin module. The CSA

source code should be used alongside the implementation guide to provide a complete understanding.

1.7 Design Diagrams

1.7.1 Direct Model - Payment input on Oracle Commerce Store pages


1.7.2 Redirect Model - Payment input on Worldpay pages

1.8 Plugin Distribution Structure

The plugin is packaged within the Worldpay.zip archive. This contains a README.txt which explains how to

install the plugin.

The following diagram shows the modules provided and their dependencies:


Worldpay - This contains the core plugin functionality and will be used by all implementations of the

plugin

Worldpay-CSA.Base - This contains the common CSA functionality

Worldpay-CSA.Production - This contains the CSA functionality which is specific to the Production Store

server

Worldpay-CSA.Agent - This contains the CSA functionality which is specific to the CSC server

1.9 Example CSA Installation

The zipped release contains multiple folders as detailed:

Worldpay contains the core plugin jars, which can be added to your standard Oracle Commerce installation

Worldpay-CSA contains the extra CSA demo application Oracle Commerce modules, which should be added

to a fresh CIM CSA installation

CommerceAccelerator contains the extra CommerceAccelerator modules for the CSA demo, which need to

be added in place to the CSA installation within the 'CommerceAccelerator' project hierarchy

WPCSAen contains the additions to the english language endeca templates directory in

../CommerceAccelerator/Applications/B2CStore/src/main/eac-templates

1.10 Installing the core plugin modules

The following modules are all located in the Worldpay folder.

Add the following modules to your Oracle Commerce installation:


Worldpay.Base

Worldpay.Notifications

Worldpay.Agent

Worldpay.Fulfillment

You will also need to add the following modules dependant on which versions of RESTeasy/jax-rs you want

to use:

RESTEasy3/jax-rs-2

Worldpay.REST.RESTEasy3

Worldpay.REST.jax-rs-2

RESTEasy2/jax-rs-1

Worldpay.REST.RESTEasy2

Worldpay.REST.jax-rs-1

You will need to include the following on each server:

Production: Worldpay.Notifications and the REST/jax-rs modules

Agent: Worldpay.Notifications, Worldpay.Agent and the REST/jax-rs modules

1. SQL scripts

There are SQL scripts located in Worldpay/Base/sql/install/oracle/ for the management and production

schemas

1.11 Installing the CSA example modules

Core Modules

Add the following modules from the Worldpay-CSA folder:

Worldpay-CSA.Worldpay.Production

Worldpay-CSA.Worldpay.Agent

Worldpay-CSA.Worldpay.Base

You'll need to include the following on each server:

Production: Worldpay-CSA.Production

Agent: Worldpay-CSA.Agent

Commerce Accelerator Modules

The following modules will need to be added to your CommerceAccelerator installation in the

CommerceAccelerator/Plugins directory:


CommerceAccelerator/Plugins/WorldpayAccount

CommerceAccelerator/Plugins/WorldpayCheckout

The following modules will need to be added to your CommerceAccelerator installation in the

CommerceAccelerator/Applications/B2CStore/Plugins directory:

B2CStore/Plugins/WorldPayAccount

B2CStore/Plugins/WorldPayCheckout

They will then need to be added as new modules to the CSA build system by modifying the following:

Adding the modules to 'includedPlugins'

CommerceAccelerator/Applications/B2CStore/gradle.properties

Adding the new modules to require.js, as specified in the included README

Add the new modules to CommerceAccelerator/Applications/B2CStore/src/main/web-

app/bower.json

Endeca template overlay

Overlay the contents of the WPCSAen directory on top of your

CommerceAccelerator/Applications/B2CStore/src/main/eac-templates/CSAen directory

Merchant codes

You will need to add your merchant codes to the MerchantPropertyFinder component

1.12 Fundamental Concepts

The entry point for most interaction with the plugin is through three Oracle

Commerce Components; PaymentService, DirectCommercePaymentService and TokenisedPaymentService.

Their roles are summarised in the following table in addition to other services required to support 3D

Secure.

The DirectCommercePaymentService/TokenisedPaymentService should always be used for all direct

payment authorization interactions with Worldpay because 3D Secure authentication can be turned on or

off from within the Worldpay Merchant Code configuration.

Component Scope Purpose

PaymentService global Used for all interactions with Worldpay except for ones which

require separate handling for 3D Secure. 3D Secure for redirect

and iframe happen on the Worldpay side so their methods are

here. Also there are methods for modifying existing payments


DirectPaymentService request Used for all non-tokenised direct

payment authorization transactions with Worldpay

TokenisedPaymentService request Used for all tokenised direct payment authorization transactions

with Worldpay

ThreeDPaymentService request Used to authorise direct payments after redirecting to 3d secure

ThreeDAuthorisationData session Stores values used by the ThreeDPaymentService

1.13 Hosted Payment Pages

The plugin has been developed to support payment by redirecting to Worldpay Hosted Payment Pages

(HPP). The redirect payment model enables sites to reduce PCI considerations by ensuring card details are

not visible to any aspect of their commerce application. Worldpay hosts the pages which collect the

payment details and then process the payment. All that is required in terms of implementation is to

redirect to the specified Worldpay pages at the correct point within the checkout flow and handle the

authorisation response returned.

Full page redirects and iframes hosting the Worldpay HPPs are supported by the plugin.

1.14 Client-Side Encryption

Client-side encryption is a way of capturing the payment details of a customer and sending encrypted to

Oracle Commerce to pass through Direct XML integration to Worldpay. The payment details are encrypted

in the client browser using the Worldpay CSE encryption JavaScript library.

1.15 Card Tokenisation

Worldpay enables their clients to tokenise cards of customers so that the same payment method can be

reused for subsequent orders. Customers can then checkout with a previously used card details if the token

has been retained against their profile.

Creation of the token can be done during checkout for the direct model. It can also be done separately

from peforming checkout, for example in an Account section which updates the user profile. Tokens can be

used in subsequent purchases for the Direct model. They can also be used for processing refunds.

1.16 Committing an Order in Oracle Commerce

Oracle Commerce's commit order process is designed to handle the authorization of a payment in a

synchronous transaction. Due to the nature of some of the payment types offered by Worldpay and the

introduction of 3D Secure, it isn't always possible to receive an authorization for an order synchronously. A

Service Integrator would typically use Oracle Commerce's CommitOrderFormHandler to commit an order


upon completion of a checkout flow, however, this will attempt to authorize a payment synchronously. As

detailed in later sections of this guide, the extension of the CommitOrderFormHandler is advised to allow a

payment to be authorized asynchronously. Due to the generally asynchronous nature of payment

transactions within Worldpay, a two stage approach has been developed. Firstly a partial pipeline is

invoked by the Worldpay plugin to simulate invoking the part of the process order pipeline up to the

payment authorization component. Once payment authorization has been achieved with Worldpay the

process order pipeline is called in its entirety.

1.17 Partial process order pipeline

The partial process order pipeline is used when authorizing a payment with Worldpay. It is performed so

that an order can be validated prior to attempting authorization. This method protects against validation

failure occurring after authorization which may lead to the need to cancel or re-authorize a payment. The

partial process order pipeline is executed whenever performing an asynchronous authorization through the

Worldpay plugin module.

Note - When executing a direct authorization within CSC, the partial pipeline is not invoked, this is due to a

CSC direct authorizations being invoked through the normal process order pipeline.

1.18 Payment Groups and Processors

Worldpay facilitates two payment models (Direct and Redirect) which do not align with the out-of-the-box

Oracle Commerce Payment Groups or associated Payment Group processors. To provide better support to

both payment models and the different varieties of direct checkout the plugin introduces four new

Payment Groups. The new Payment Groups follow the Oracle Commerce pattern for Payment Group

creation, the following table details their associated Processors and Pipelines.

Payment Group Payment Group

Processor

Payment Group

Info Pipeline

Processor

Payment

Group

Pipeline

Processor

Pipeline Chain

WPDirectPaymentGro

up

WPDirectProces

sor

CreateWPDirectIn

fo

ProcessWPDir

ect

wpDirectProcessorCh

ain

WPRedirectPayment

Group

WPRedirectProc

essor

CreateWPRedirect

Info

ProcessWPRed

irect

wpRedirectProcessor

Chain


WPTokenisedPaymen

tGroup

WPDirectProces

sor

CreateWPDirectIn

fo

ProcessWPDir

ect

wpDirectProcessorCh

ain

WPEncryptedPaymen

tGroup

WPDirectProces

sor

CreateWPEncrypt

edInfo

ProcessWPDir

ect

wpEncryptedProcess

orChain

1.19 Merchant Code Mapping

The plugin provides a facility to abstract the merchant codes required to interact with Worldpay away from

the business or presentation layers of an Oracle Commerce implementation. The merchant code mapping

allows a System Integrator to provide properties relating to the context of their site into the plugin, the

properties are then used to resolve the correct merchant code and password pair to be used for the

transaction. The MerchantPropertyFinder and ReAuthMerchantPropertyFinder contain the merchant

code definitions for standard and re-authorization transactions respectively.

An example MerchantPropertyFinder definition:

Within the above example, the key representing the merchant codes has been defined to contain a Country

Code and a Site Type. For each Merchant Code listed it is keyed with a combination of these two

keyOrder=countryCode_siteType

keyOrderDelimiter=_

keyDelimiter=.

resolvingMapProperty=\

US.B2C.merchantCode=USMerchantCode,\

US.B2C.merchantCodePassword=password,\

DE.B2C.merchantCode=DEMerchantCode,\

DE.B2C.merchantCodePassword=password,\

US.EMP.merchantCode=USMerchantCode2,\

US.EMP.merchantCodePassword=password,\

DE.EMP.merchantCode=DEMerchantCode2,\

DE.EMP.merchantCodePassword=password,\

DE.B2B.merchantCode=DEMerchantCode3,\

DE.B2B.merchantCodePassword=password


properties. This allows a developer to define a LinkedHashMap containg these properties when creating a

transaction with the Worldpay plugin:

1.20 Completing An Order

The OrderCompleteListener is used by the Worldpay plugin to complete an order in the same way as

the CommitOrderFormHandler. It first updates an order with an authorization status and then executes the

process order pipeline. The process order pipeline will only be invoked if the order is in one of two states,

INCOMPLETE or PENDING_PAYMENT_CONFIRMATION which protects against duplicating an authorization

status for the same authorization transaction.The CompleteOrderListener will also check that the

authorization amount matches the amount defined within the Payment Group for the order (this

is performed within the preAuthorizeWorldpayPaymentGroup). During execution of the process order

pipeline, any pipeline errors will cause the transaction to be rolled back.

1.21 User Locale

It is common practice to supply the users locale inside the process map used by the process order pipeline.

The plugin supports this during the partial process order pipeline and within the full process order pipeline

post authorisation. Because it is possible for the plugin to process an order

after receiving an asynchronous authorisation message it is necessary to persist the users locale before

authorisation takes place. This is because the asynchronous authorization message is received outside the

context of a user. The plugin persists the user locale on the order using a WPOrder interface, this requires

the SI to implement the WPOrder interface within their Order implementation. The plugin will only accept

orders of WPOrder type. An example of this implementation is provided within

the reference implementation provided with the plugin.

1.22 Worldpay URL Builder

The WorldpayUrlBuilder is used for the construction of all URLs used for page redirection. This includes

scenarios such as Redirect Model authorization, 3D Secure identification and Alternative Payment

Type redirection. The WorldpayUrlBuilder is a utility for building the URL used for redirection but is also

designed to maintain the Oracle Commerce MultiSite Site Context between leaving the Oracle

Commerce web-site and returning. This is achieved through a combination of parameterising the Oracle

Commerce Site identifier on the redirection URL and retrieving it within the ReceiverServlet.

The ReceiverServlet will then push the Oracle Commerce Site context before rendering the appropriate

page.

LinkedHashMap<String, String> merchantCodeKeyMap = new LinkedHashMap<String, String>();

merchantCodeKeyMap.put("countryCode", "US");

merchantCodeKeyMap.put("siteType", "B2C");


1.23 XML Marshaling

Messages between Worldpay and the Plugin are largely constructed using XML. The format of the XML is

defined by Worldpay's payment service Document Type Definition (DTD). The plugin uses value objects

generated through the XJC utility with the Worldpay DTD as the schema. The resulting value objects

represent all the elements required for communication with Worldpay and are annotated

for marshalling with JAXB.

Unique Order IDs

Worldpay requires a unique Order ID for each authorisation transaction created on its servers. Out-of-the-

box Oracle Commerce will create a new Order ID for each order which can either be session scoped or

persisted. This can cause an error to be thrown from Worldpay if a user attempts to re-authorise an order

in the event that the first authorisation fails. For this reason the plugin generates a unique identifier and

appends it on the end of the provided Oracle Commerce Order ID. The plugin uses Java's UUID utility

to guarantee uniqueness to a high level of confidence.

To override the unique ID generated, extend the UniqueOrderSuffixGenerator which out-of-the-box will

generate with UUID and set it in the Payment Group as the UniqueOrderSuffix.

Note:- Worldpay accepts Order IDs longer than 25 characters, however a number of credit card issuers and

banks only accept Order IDs up to 25 characters. This does not mean that an order will be rejected because

the credit card issuer will truncate the ID. The problem will occur when a reconciliation between an order in

Oracle Commerce and an order with a credit card issuer is attempted.

Addresses

Billing

If the billing address is populated on the supplied Payment Group for an order; the plugin will pass it to

Worldpay. Within a Redirect model, the user can also provide flags to set a billing address to be either read-

only or hidden. The flags are defined as fixContact and hideContact within

the AdditionalOrderData supplied to the plugin.

Shipping

The plugin supports the passing of a shipping address to Worldpay. Because only one shipping address is

supported by Worldpay the plugin uses the shipping address of the first shipping group on an order.

Asynchronous Billing Detail Update

Within the Redirect model some data is entered outside the Oracle Commerce system so is initially

unavailable for display. A similar situation exists with CSE (encrypted) payments where the card details are

encrypted before they get to the Oracle Commerce instance.

This information is available on, and extracted from the authorisation notification that follows shortly after

successful payment. The extra billing information passed back from Worldpay is:

Payment Method (e.g. VISA-SSL)

Credit Card Type (e.g. credit)


Credit Card Number (masked)

Credit card expiry date.

Authorisation Id

The plugin places this information into the associated WPRedirectPaymentGroup.

Worldpay Oracle Commerce Plugin Implementation Guide > Implementation Guide 20

Implementation Guide

This section will detail how a System Integrator would use the Worldpay plugin to perform an integration

between Worldpay's Payment Gateway and an Oracle Commerce Site. This includes Direct, Redirect

and Alternative Payment models supported by Worldpay. It also includes guidance on a 3D Secure

implementation within the Direct payment model.

1.24 Commerce Site Integration

Direct Model

The Worldpay Direct model allows an SI to integrate with Worldpay without the need to redirect

to remotely hosted pages. This model requires the payment details to be entered within the Oracle

Commerce Site, the payment is authorized using calls from the Worldpay plugin module to Worldpay.

Out-of-the-box Oracle Commerce authorization of a payment would use the process order pipeline and

the associated payment group. Due to the asynchronous nature of an authorization transaction with

Worldpay the authorization needs to occur outside the process order pipeline (explained further in

section: Committing an Order in Oracle Commerce). To avoid the invocation of the process order pipeline

before authorization occurs, it is advised that the PurchaseProcessFormHandler is extended to in

a similar way to the example WPSinglePageCheckoutFormHandler provided with the reference

implementation. The WPSinglePageCheckoutFormHandler overrides the commitOrder to handle the

authorization in a different way if the Payment Group is configured to be

an instance of WPDirectPaymentGroup.

Authorize Flow

To perform an authorization in the direct model a reference to the DirectCommercePaymentService is

required. Before the createDirectPayment method can be invoked several pieces of information are

required; this includes properties to retrieve the merchant code (see section: Merchant Code Mapping),

browser data relating to the users browser and content data such as the order description. Upon invocation

of the createDirectPayment method a DirectPaymentData POJO is returned which contains information

relating to 3D Secure. Except from when a 3D Secure transaction is required, if an authorization is

not successful an exception will be thrown.

If Worldpay authorization is successful then the OrderCompleteListener will be used to process the order

(see section: Completing An Order), this will result in the order being passed to fulfillment.

3D Secure Authorization Flow

If the DirectPaymentData returned to the calling FormHandler reveals that a 3D Secure identification is

required the 3D Secure URL will be supplied. The user will then have to be redirected to this page with the

provided data supplied as a parameter in accordance with Worldpay's guide to 3D Secure transactions. The

redirection needs to be executed as a HTTP post which usually means a form post is required.

The WorldpayURLBuilder (see section: Worldpay URL Builder) should be used to construct the 3D Secure

URL before redirection. Upon completion of 3D secure identity the users browser will be redirected to

the ReceiverServlet imbued with the ThreeDSecureResponseProcessor.

The ThreeDSecureResponseProcessor will perform a authorization call to Worldpay

with information supplied by the 3D Secure provider.

https://confluence.e2x.co.uk/#WorldpayPluginImplementationGuide-CommittinganOrderinOracleCommerce

https://confluence.e2x.co.uk/#WorldpayPluginImplementationGuide-MerchantCodeMapping

https://confluence.e2x.co.uk/#WorldpayPluginImplementationGuide-CompletingAnOrder

https://confluence.e2x.co.uk/#WorldpayPluginImplementationGuide-WorldPayURLBuilder


Following a successful authorization response form Worldpay the ThreeDSecureResponseProcessor will

complete the order in the same way as the DirectCommercePaymentService in a non-3D Secure payment

and redirect the user to an appropriate page.

Redirect Model

The Worldpay Redirect model allows an SI to integrate with Worldpay using remotely hosted pages. This

model requires the payment details to be entered on Worldpay's remotely hosted pages following a page

redirect away from the Oracle Commerce site. Implementation of the redirect model will typically start at

the billing selection stage of a checkout flow. It is at this point within the checkout flow that

the BillingInfoFormHandler is used in CSA, or typically, the PaymentGroupFormHandler is used outside of

CSA (both extend the PurchaseProcessFormHandler).

Authorization Flow

To achieve authorization through redirection it is expected that

the BillingInfoFormHandler or PaymentGroupFormHandler will be extended and a handle method for

Worldpay redirection created. This method will eventually call the

original handleBillingWithSavedAddressAndNewCard in the case of CSA. The handle method should add an

instance of a WPRedirectPaymentGroup to the order with the payment

group's defaultPaymentGroupName set to the same value as the traditionalRedirectPaymentMethod in

the WorldpayMapper (default: wpRedirect). It should also define the properties for merchant

code retrieval (see section: Merchant Code Mapping) and setup additional order data required by

Worldpay. The additional order data includes information such as content to be displayed within the

redirected pages and browser data required by Worldpay to ensure compatibility.

The PaymentService is then used to call the createRedirectPayment (or createIframePayment) method to

initiate the redirection.

Assuming no connection errors, the returned RedirectPaymentData will contain the URL required for

browser redirection which can be set on the FormHandler using

the setMoveToConfirmSuccessURL method. This will allow the FormHandler to use the

standard checkFormRedirect to control the browser redirection.

public RedirectPaymentData createRedirectPayment(WPOrder order,

WPRedirectPaymentGroup paymentGroup, Profile profile, Map<String, String>

merchantPropertyMap, AdditionalOrderData additionalOrderData) throws

NoMerchantFoundException, WorldpayException, CommerceException { ... }

public RedirectPaymentData createIframePayment(WPOrder order,


merchantPropertyMap, AdditionalOrderData additionalOrderData) throws


https://confluence.e2x.co.uk/#WorldpayPluginImplementationGuide-MerchantCodeMapping


Once the user has completed the authorization process on the remotely hosted payment pages they will be

redirected back into the plugin via the ReceiverServlet setup to use the RedirectModeResponseProcessor.

The RedirectModeResponseProcessor will perform integrity and authentication checks on the response

from Worldpay and ascertain the outcome from the authorization. If Worldpay authorization

is successful then the OrderCompleteListener will be used to process the order (see section: Completing An

Order), this will result in the order being passed to fulfillment. In the event of a problem authorizing the

user will be redirected to a defined error page, otherwise they will be redirect to the defined success page

(see section: WorldPayURLBuilder).

Setting the MAC Code

Worldpay uses a MAC code (Message Authentication code) to verify communication between Worldpay

and Oracle Commerce in Redirect mode. You can set your shared MAC code on the

component /Worldpay/config/WorldpayConfiguration with the property macSecret; all Merchant Codes

share the same MAC code.

Preferred Payment Type

The AdditionalOrderData object that gets passed to the PaymentService contains a

preferredPaymentMethod, which will then be appended to the redirect URL on full page redirects. This will

cause the provided payment method to be pre-selected, for example setting this to "PAYPAL-EXPRESS" will

cause the redirect to appear to go straight to PayPal, without the Worldpay selection page beforehand.

IFrame Checkout

The Worldpay Redirect model also allows the SI to inegrate with Worldpay using remotely hosted pages via

an iframe. The capture of the customer's credit card details is then the responsibility of Worldpay while the

look and feel of the site is retained around the iframe. The SimpleResponseProcessor handles this type of

checkout as opposed to the RedirectModeResponseProcessor which handles full page redirects to the

HPPs. Note that the HPP can forward onto 3D Secure according to the rules set up within the Worldpay

console. Orders created through this type of checkout require authorisation via a Worldpay notification.

IFrame checkouts currently only support credit card payment types, and the iframe will need to be

integrated in the frontend as per the Worldpay iframe instructions, see section: How To Implement IFrame

Checkout

Token creation

The PaymentService component has alternative methods you can use if you desire tokens to be created for

a redirect checkout, they are createRedirectPaymentWithTokenRequest and

createIframePaymentWithTokenRequest. When using these methods creation of a token will be requested

when setting up the redirect payment, and if the payment type used by the user supports tokenisation the

details of the token will be reported back in the authorisation notification.

public RedirectPaymentData createRedirectPayment(WPOrder order,




https://confluence.e2x.co.uk/#WorldpayPluginImplementationGuide-WorldPayURLBuilder

https://confluence.e2x.co.uk/#WorldpayPluginImplementationGuide-HowtoImplementIframeCheckout

https://confluence.e2x.co.uk/#WorldpayPluginImplementationGuide-HowtoImplementIframeCheckout


They each take an extra parameter to indicate the type of token you want created.

Alternative Payment Types

The Alternative Payment Types are categorized under Worldpay's Direct model despite requiring a page

redirection to remotely a hosted page. However like an authorization within the Redirect Model it is

expected that the redirection will occur within the BillingInfoFormHandler or PaymentGroupFormHandler.

For this reason the WPRedirectPaymentGroup should be used for 'direct' Alternative Payment Type

transactions. The plugin currently supports two Alternative Payment Methods, PayPal and iDeal, see

section: How To Add An Alternative Payment Type to understand how to add more.

Authorization Flow

The same authorization flow for the Redirect Model should be followed with two notable exceptions. Firstly

the defaultPaymentGroupName on the WPRedirectPaymentGroup payment group definition should be

different to the traditionalRedirectPaymentMethod in the WorldpayMapper (default: wpRedirect). The

value for the defaultPaymentGroupName should correspond to the Alternative Payment Type being used

and also exist in the onlineTypeToClassMap of the WorldpayPaymentTypeMapper (defaults -

PayPal: wpPayPal, iDeal: wpIdeal). The second change to the Redirect Model authorization flow is the usage

of the SimpleResponseProcessor instead of the RedirectModeResponseProcessor. This is because there is

no functionality supplied by Worldpay to authenticate the senders identity or verify the integrity of the

sender data. For this reason the SimpleResponseProcessor does not complete the order and will leave the

order within the PENDING_PAYMENT_CONFIRMATION state. The plugin relies on the Worldpay Order

Notification authorize message to complete the order (see section: Order Notifications).

The SimpleResponseProcessor will switch the shopping cart on the OrderHolder to ensure the

user receives a new shopping cart when the payment transaction finishes.

Configurable Risk Guardian Attributes

The Worldpay interface provides a facility to pass information to its Risk Guardian product. The plugin

provides a means to pass key/value pairs through the initial authorisation for the Redirect and Direct

models. The AdditionalOrderData contains a map labelled additionalRiskData which provides a pass-

through for any additional Risk Guardian data. This requires further configuration within the Worldpay/Risk

Guradian management console.

merchantPropertyMap, AdditionalOrderData additionalOrderData, TokenScope

requestedTokenType) throws NoMerchantFoundException, WorldpayException,

CommerceException { ... }

public RedirectPaymentData createIframePayment(WPOrder order,


merchantPropertyMap, AdditionalOrderData additionalOrderData, TokenScope

requestedTokenType) throws NoMerchantFoundException, WorldpayException,


https://confluence.e2x.co.uk/#WorldpayPluginImplementationGuide-HowToAddAnAlternativePaymentType

https://confluence.e2x.co.uk/#WorldpayPluginImplementationGuide-OrderNotifications


1.25 Tokenisation

The tokenisation of credit card details by Worldpay is managed through the

component TokenisedPaymentService. This provides methods to create tokens and also to perform

tokenised payments. Additionally tokens can be persisted against a users' profile.

1.25.1 Creating Tokens

Card details including the billing address can be sent using the WPCardDetailsTokenRequest object or can

be sent encrypted (via client side encryption, see CSE documentation) using

the WPEncryptedDetailsTokenRequest object.

The CardTokenRequest should be passed to TokenisedPaymentService.createPaymentToken, along with

with the customer's Profile and a map containing the Merchant Code. The TokenisedPaymentService will

send the createToken message to Worldpay, and if successful return a

populated TokenisedPaymentData bean representing the new token.

All of the information in the TokenisedPaymentData bean is based on the response from

Worldpay. The TokenisedPaymentData bean also includes the original Billing Address when specified.

1.25.2 Token Scope

The tokenScope field on WPCardDetailsTokenRequest can be set to either SHOPPER or MERCHANT

depending on the type of token desired. When creating shopper tokens the billing address must be

specified. For creation of merchant tokens the billing address is optional, but if it is not specified then the

card holder name is mandatory.

1.25.3 Persisting Tokens

The Worldpay plugin extends the ProfileAdapterRepository to allow the persisting of tokens against

profiles. The information stored within the TokenisedPaymentData bean can be persisted using a new item

descriptor called wpTokenData RepositoryItem, but will not be by default. The Worldpay plugin extends

the ProfileAdpaterRepository to include two new properties, shopperTokens and merchantTokens, on

the user repository item so that tokens may be saved against the profiles of registered users.

The property savedTokens is a map and uses a nickname to uniquely identify the many tokens the user

might have. This mirrors the existing CSA credit cards functionality.

public TokenisedPaymentData createPaymentToken(

WPCardTokenRequest wpCardTokenRequest, Profile profile, Map<String, String>

merchantPropertyMap)

throws NoMerchantFoundException, WorldpayException, CommerceException,

RepositoryException { ... }


To save a token against a user profile, either the TokenisedPaymentDataPersister or

MerchantTokenisedPaymentDataPersister (depending on the token scope) should be used.

1.25.4 Paying with Tokens

Checkout with a token is possible once the TokenisedPaymentData bean is populated, either via the plugin

or retrieved from a user profile.

Initially a WPTokenisedPaymentGroup should be created. Subsequently

the TokenisedPaymentGroupMapper should be used to populate it with data from

the TokenisedPaymentData bean.

Note that the Billing Address used on the Payment Group should also be set from

the TokenisedPaymentData bean.

Once the new PaymentGroup has been set against the order, and the standard checkout validation has

been called succesfully, the order can be submitted for payment using the TokenisedPaymentService.

Once this call has been made, the rest of the checkout process should continue in the same way as a Direct

checkout, including checking for 3D secure support.

1.25.5 Updating saved tokens

The TokenisedPaymentService is able to update the expiry date and billing address for a saved token.

Changing the card number is not supported - a new token should be created instead.

public void saveToken(Profile profile, TokenisedPaymentData tokenisedPaymentData, String

nickName) throws RepositoryException { ... }

public DirectPaymentData authTokenisedPayment(

WPOrder order, WPTokenisedPaymentGroup paymentGroup, Profile profile, Map<String,

String> merchantPropertyMap, AdditionalOrderData additionalOrderData)

throws NoMerchantFoundException, WorldpayException, CommerceException { ... }

public boolean updatePaymentToken(TokenisedPaymentData tokenisedPaymentData,

WPCardDetailsTokenRequest wpCardTokenRequest, TokenScope tokenScope, Map<String,

String> merchantPropertyMap) throws NoMerchantFoundException, WorldpayException,


Calling this will update the token data in Worldpay and return a boolean to indicate if the update was

successful. This will not update the details saved against the profile, so on a successful response that should

be done via the TokenisedPaymentDataPersister

1.25.6 Deleting saved tokens

The TokenisedPaymentService is able to delete a saved token.

Calling this will delete the token data in Worldpay and return a boolean to indicate if the update was

successful. This will not delete the details saved against the profile, so on a successful response that should

be done via the TokenisedPaymentDataPersister

public void removeToken(RepositoryItem profile, String tokenNickname) throws

RepositoryException, TokenNotFoundException { ... }

1.26 Customer Service Center Integration

The Customer Service Center (CSC) is an out-of-the-box service desk application part of the Oracle

Commerce platform. It provides access to orders and allows a service desk representative to process

payments, refunds and cancellations. CSC's front-end is not built using the same technology as the

Commerce Store Accelerator implementation which means the is a separate reference implementation for

CSC.


public void updateToken(Profile profile, TokenisedPaymentData tokenisedPaymentData)

throws RepositoryException { ... }

public boolean deletePaymentToken(TokenisedPaymentData tokenisedPaymentData,

TokenScope tokenScope, Map<String, String> merchantPropertyMap) throws



1.26.1 Direct Model

The Worldpay Direct model allows an SI to integrate with Worldpay without the need to redirect

to remotely hosted pages. This model requires the payment details to be entered within the Oracle

Commerce Site, the payment is authorized using calls from the Worldpay plugin module to Worldpay. The

CSC Direct model integration attempts to make as few changes as possible to CSC and does not support 3D

Secure identification. For this reason it has been aligned with the base credit card payment pages which

already exist in CSC.

The override to align the CreditCard Payment Group to a WPDirectPaymentGroup Payment Group is

defined within the OrderTools component. To facilitate this override an

empty WPCreditCardPaymentGroup has been defined to extend the WPDirectPaymentGroup class, this

allows two definitions of the same Payment Group within OrderTools.

1.26.2 Redirect Model

The Worldpay Redirect model allows an SI to integrate with Worldpay using remotely hosted pages. This

model requires the payment details to be entered on Worldpay's remotely hosted pages following a page

redirect away from the Oracle Commerce web-site.

1.26.3 Page Alterations

To introduce the Redirect Payment Group to CSC, changes need to be made to the billing page to make it

available. This can be achieved by replacing the JSP that produces the buttons on the final order review

page in the checkout. The /panels/order/complete.jsp and JSPs included within it have been copied and

altered, to use the new version of the complete.jsp the otherContext property of

the cmcCompleteOrderP panel is changed to the context of the new web application housing the altered

JSPs (see svc_framework.xml).

Within finishOrderButtons.jsp there is a modification that checks to see if there is

a WPRedirectPaymentGroup payment group on the order. If there is, then the javascript invoked by the

submit button is changed to some that it does a direct form submission of the BillingFormHandler rather

than an ajax call. The direct form submission will result in a page redirect to Worldpay's remotely hosted

payment pages.

1.26.4 Changes Required For Payment Group Availability

To make the WPRedirectPaymentGroup available for selection in CSC there are a number of steps:

1. Configure /atg/commerce/custsvc/order/PaymentGroupDroplet to add an

entry paymentGroupInitializers map. For Example:

wpRedirect=/atg/commerce/order/purchase/WorldpayRedirectInitializer


2. Create the WorldpayRedirectInitializer component. The class for this

implements PaymentGroupInitializer and PaymentGroupMatcher however there is no need to go

beyond an empty implementation

3. Removed /atg/commerce/custsvc/ui/CreditCardConfiguration from paymentGroupTypeConfiguratio

ns in /atg/commerce/custsvc/util/CSRConfigurator

4. Added /com/rbs/Worldpay/custsvc/ui/WorldpayRedirectConfiguration to paymentGroupTypeConfig

urations in /atg/commerce/custsvc/util/CSRConfigurator

5. Added wpRedirect

to paymentGroupTypesToBeInitialized in /atg/commerce/custsvc/util/CSRConfigurator

6. WorldpayRedirectConfiguration is used to configure the JSP fragments to be used for creating,

displaying and modifying the Payment Group. There are only those for selecting and displaying as it

isn't possible to edit the details on a redirect payment group, these are gathered after redirecting.

1.26.5 Returning From Worldpay Redirection

Under normal circumstances when using CSC the content of main.jsp is loaded once via a GET, every action

from then on results in replacement of parts of the content via ajax. For this reason Oracle

Commerce assumes that any GET request for main.jsp is a new session or tab and allocates a new window

scope for the request. Unfortunately on redirecting back from Worldpay (which is done as a GET) it must

come back through the main.jsp in order to re-load all of the CSC furniture, which by default gives us a new

window scope each time. Unfortunately Oracle Commerce buries this window scope test in the bowels of a

pipeline servlet that cannot be overridden in a sensible way. To get around this problem it is possible to

extend the servlet (see WPStateHolderPipelineServlet), in the case where it is detected that a request is

coming from Worldpay the request can be wrapped with one that pretends to be a POST. The only override

required is the getMethod(), for example:

1.26.6 Viewing orders

To display data from the new payment group types CSC must be customised as follows

Add an entry to CSRConfigurator.paymentGroupTypeConfigurations pointing to a

PaymentGroupTypeConfiguration for the payment group type to display

The type property should match the type of the payment group

@Override

public String getMethod() {

return "POST";

}


The displayPageFragment property should be defined and point to a new PageFragment component

Other properties are not required

Add the PageFragment component which has 2 properties

A relative URL to a jsp to display the payment group

The context root for the web app hosting the jsp

Add the jsp, which can be created based don displayCreditCard.jsp

1.26.7 Cancellations

Cancellations within CSC allow an order to be cancelled from an Oracle Commerce perspective, however

they do not attempt to cancel the authorisation of a Payment Group. An extension to

the CSRCancelOrderFormHandler allows the invocation of a Cancel to also trigger a Cancel in Worldpay

(see: WPCSRCancelOrderFormHandler). It is advised that the CancelOrderService's cancelOrder is not called

until the asynchronous message is received from Worldpay (see section: Order Notifications).

Note:- The cancellation option is only available in CSC before an order has been marked for shipment.

1.26.8 Refunds

Refunds within CSC provide a service representative to start a refund process and complete it once items

from within an order are marked as returned. The CSC refund functionality is extendable out-of-the-box,

the steps to perform an extension are detailed within the "Commerce Service Center Installation and

Programming Guide" under the section "Customizing Refund Methods". The reference implementation

supplied with the plugin follows this guide.

This results in the creation of WorldPayRefundMethod and WPCreditCardRefundMethod RefundMethod's

and a WPReturnManager. This allows refunds for Worldpay Payment Groups to be processed using the

standard CSC return pages and forms. The Worldpay Payment Groups are set-up to execute the refund

through Worldpay and create the Credit Payment Group Status. An SI needs to be aware that the refund

should only be considered as completed once the asynchronous Refunded message is received from

Worldpay, this will mark the orderNotificationReceived flag on the Payment Group Credit Status to true

(see section: Order Notifications).

Notes

Most CSC customisations require a copy of a JSP out of DCS-CSR into your own web application. If you're

lucky any dsp:includes will already have an otherContext on them that points back to DCS-CSR.




1.27 Fulfilment

The Worldpay plugin has been designed around Oracle Commerce's standard Fulfillment module and

unmodified Fulfillment pipelines. To simulate the shipment of an order the Fulfillment pages within the

Commerce Administration area of the Dynamo Admin can be used. Out-of-the-box Oracle

Commerce fulfillment process will attempt to settle the payment of an order once an order has been

marked for shipment.

There is a module that handles fulfilment where the location is Worldpay/Fulfillment.

1.27.1 Request For Capture

The Payment Group Processors defined for both the Direct and Redirect Payment Groups (see

section: Payment Groups and Processors) both inherit the same debit and credit definitions. The debit

function is used to debit a payment by the OrderFulfiller once the Shipping Group has been marked as

shipped. Within the Plugin, Oracle Commerce's concept of Settlement has logically been mapped to

Worldpay's concept of Captured. For this reason, a 'Request For Capture' is issued to Worldpay when

Oracle Commerce attempts to Settle a payment. See below:

When attempting to settle a Payment Group Oracle Commerce expects to receive a synchronous answer to

the request for capture request. However, Worldpay do not currently support this type of call and as a

result an interim status has been introduced. Settle Requested bridges the time between a Request For

Capture call being made and a Captured Order Notification message being received. The reason that an

interim state is required is because of the Order Modifications applicable to an order when either in a

Worldpay Authorised or Captured state. If an order is in a Worldpay Authorised state it can be Cancelled

https://confluence.e2x.co.uk/#WorldpayPluginImplementationGuide-PaymentGroupsandProcessors


but not Refunded, however if an order is in a Worldpay Captured state it can be Refunded but not

Cancelled. To accommodate for the new Payment Group status an extension to

the OrderFulfillmentTools has been made. The WPOrderFulfillmentTools overrides

the hasOrderSettled method to stop settling an order unless the captured Order Notification message has

been received (see section: Order Notifications). This change only effects Payment Groups of a type

of WPPaymentGroup.

1.28 Order Notifications

Worldpay provides an asynchronous facility to update the Merchant about every status change made to an

order. The functionality built into the Plugin to support Order Notifications is designed to work with

notifications delivered via a HTTP POST using an XML encoded body (this needs to be configured on each

Merchant Code within the Worldpay admin interface).

A Java Servlet is used to handle notification messages sent from Worldpay, the OrderNotificationServlet is

defined as a RESTEasy (see section: RESTEasy) HttpServletDispatcher to allow RESTEasy to marshal

the XML. The OrderNotificationServlet servlet-mapping is defined to accept all messages with the URL

matching /order_notification/*. Once the message has

been marshalled the OrderNotificationServlet (backed by the OrderNotificationEndPoint) will place the

message onto a SQL backed DMS (Dynamo Messaging System) queue before sending an OK message back

to Worldpay. A Sink will pick a message containing the Order Notification from the DMS queue and decide

upon a processor to handle the outcome of the notification.

Currently 'Order Notifications' is separated out into it's module called '/Worldpay/Notifications'. This

contains Notifications Processors components.

1.28.1 Dynamo Messaging System

The plugin makes use of Oracle Commerce's DMS to ensure the atomic receipt of an Order Notification

message. DMS is an Oracle Commerce implementation of the Java standard, JMS. Once an Order

Notification is received from Worldpay the OrderNotificationEndPoint ensures safe delivery of the message

onto the DMS queue before sending Worldpay the required OK response. If Worldpay does not receive the

OK response it will attempt to resend the message until it does. The default Source for the DMS queue

which handles the Order Notifications is the OrderNotificationDMSSource, the default Sink to read the

messages from the DMS queue is the OrderNotificationDMSSink. The default queue name for the Order

Notifications is sqldms:/Worldpay/OrderNotificationUpdates.

The default configuration for OrderNotificationDMSSink is to not attempt reprocessing of messages when a

Notification Processor fails. Any messages that fail processing are placed immediately on the

Fulfillment DeadMessageQueue. This configuration is suitable for development use, but in other

environments should be replaced with something more appropriate that attempts some number of

redeliveries to handle transient errors.


https://confluence.e2x.co.uk/#WorldpayPluginImplementationGuide-RESTEasy


<?xml version="1.0" ?>

<dynamo-message-system>

<patchbay>

<message-sink>

<nucleus-name>

/Worldpay/order/notification/dms/OrderNotificationDMSSink

</nucleus-name>

<input-port>

<port-name>

DEFAULT

</port-name>

<input-destination>

<provider-name>

sqldms

</provider-name>

<destination-name>

sqldms:/Worldpay/OrderNotificationUpdates

</destination-name>

<destination-type>

Queue

</destination-type>

<redelivery>

<max-attempts>1</max-attempts>

<delay>60000</delay>

<failure-output-port>OrderNotificationUpdatesError</failure-output-port>

</redelivery>

</input-destination>

</input-port>

<redelivery-port>


To enable reprocessing the max-attempts value should be set to some value greater than 1. The default

delay value is 1 minute (specified in milliseconds) - this should be set large enough that transient issues will

clear, but not so large that order processing is significantly delayed.

Multiple output-destination nodes can be configured for the redelivery-port. For example you may want

one destination that will log and/or send an alert, while another destination could be a dead message

queue so that messages are preserved for analysis.

<port-name>OrderNotificationUpdatesError</port-name>

<output-destination>

<destination-name>patchbay:/Fulfillment/DeadMessageQueue</destination-

name>

<destination-type>Queue</destination-type>

</output-destination>

</redelivery-port>

</message-sink>

</patchbay>

</dynamo-message-system>


1.28.2 Notification Processors

The processor chosen within the OrderNotificationDMSSink to handle an Order Notification message is

driven by the LastEvent element within the Order Notification message. A map defined on

the OrderNotificationDMSSink (orderNotificationProcessorMap) provides a mapping between

the LastEvent element and the component used to handle the notification. The following table provides

information about which order states are mapped to which handling components. As long as the

Order Notification status match, any missing processors for notification statuses can be added to this map

and will be invoked automatically.

LastEvent Component Path

AUTHORISED /Worldpay/order/notification/AuthorisationProcessor

CAPTURED /Worldpay/order/notification/CaptureProcessor

CANCELLED /Worldpay/order/notification/CancelledProcessor

REFUNDED /Worldpay/order/notification/RefundedProcessor

REFUND_FAILED /Worldpay/order/notification/RefundFailedProcessor

REFUSED /Worldpay/order/notification/RefusedProcessor

SENT_FOR_REFUND /Worldpay/order/notification/SentForRefundProcessor

1.28.3 Authorisation Processor

The AuthorisationProcessor is used to set-up the authorisation status for the payment group of an order. It

requires that an order has been persisted and uses the same OrderNotificationListener used by the Direct

and Redirect Model.

This processor is unlikely to be used in most payment authorisation scenarios because a standard flow of

execution would result in the authorisation status being generated within the Direct or Redirect Model. It is

however used when authorising a payment during an Alternative Payment Type transaction. It is also used

when the users browser fails to reach the Orcale Commerce store after redirecting to a remotely hosted

billing page within the Redirect Model.

If token creation has been requested for a redirect payment and the data is present in the authorisation

notification then this processor will persist it to the user's profile. By default the token name is generated


from the payment type and card suffix. This behaviour can be modified by overriding the tokenName

method

1.28.4 Capture Processor

The CaptureProcessor is designed to handle the asynchronous Captured message from Worldpay. Due to

the way Oracle Commerce wants to capture a payment in a synchronous manner

the CaptureProcessor makes use of an unimplemented pipeline called

PaymentGroupUpdateModification to update an order through Fulfillment. To achieve this

the CaptureProcessor creates a debit status and updates the payment group status to Settled, it then

invokes the PaymentGroupUpdateModification by defining and using

the ModifyOrderNotificationSender to deliver the change to the order.

The ProcPaymentGroupUpdateModification pipeline processor is responsible for making the update to the

order.

1.28.5 Cancelled Processor

The CancelledProcessor performs the cancellation of an order by using the CancelOrderService.

1.28.6 Refunded Processor

The RefundedProcessor is used to update an order once Worldpay reports that a Refund for an Order has

been successful. CSC will automatically update an order to the state of Refunded through its returns

process, for this reason the plugin defines a Notification Received flag on the Order Status. Once a

Refunded Order Notification message is received from Worldpay the Notification Received flag will be set

to true on the Credit Order Status object on the Payment Group, this will indicate that the order has been

refunded.

1.28.7 Refused Processor

The RefusedProcessor is not implemented but provided as an extension point.

1.28.8 Refund Failed Processor

The RefundFailedProcessor is not implemented but provided as an extension point.

1.28.9 Sent For Refund Processor

The SentForRefundProcessor is largely unimplemented, however it contains a flag to allow

the RefundedProcessor to be invoked once a SentForRefundProcessor is received. This is useful in

development to test the refund flow. By default the useRefundedProcessorForTest flag is set to false.

protected String tokenName(WPOrder order, TokenisedPaymentData tokenisedPaymentData)


1.28.10 Other Functionality

1.28.11 Add Back Office Code

Adding a Back Office Code to an existing order within Worldpay can be invoked from the PaymentService.

This action does not effect the status of an order.

1.28.12 Gateway Proxy Configuration

Communication with Worldpay can be directed through a proxy by configuring

the hostname and port number of the proxy provider within

the /Worldpay/config/WorldpayConfiguration component's properties.

For example:

1.28.13 Customisation

The plugin allows customisation of the proxy set up, for example to add proxy credentials

jax-rs-1

Customisations can be added to the WorldpayGateway implementation via the configureProxyCredentials

method.

To use username/password credentials set the following property on WorldpayGateway.properties

Although not supported, the following is an example of how you would implement NT credentials:

proxyHostname=clients.google.com

proxyPort=443

proxyCredentials=\

hostname=username:password


This would use the following properties file:

jax-rs-2

Customisation can be added to the implementation of WorldpayClientBuilder (e.g.

WorldpayResteasyClientBuilder.configureProxy)

private Map<String, String> proxyCredentials = new HashMap<String, String>();

@Override

protected void configureProxyCredentials(DefaultHttpClient httpClient) {

for (Entry<String, String> credential : getProxyCredentials().entrySet()) {

Credentials credentials = new NTCredentials(credential.getValue());

AuthScope authScope = new AuthScope(credential.getKey(), AuthScope.ANY_PORT);

httpClient.getCredentialsProvider().setCredentials(authScope, credentials);

}

}

public Map<String, String> getProxyCredentials() {

return proxyCredentials;

}

public void setProxyCredentials(Map<String, String> proxyCredentials) {

this.proxyCredentials = proxyCredentials;

}

proxyCredentials=\

hostname=domain/username:password


1.29 Further Development

1.29.1 How To Add An Alternative Payment Type

The component WorldpayPaymentTypeMapper uses Dozer to map alternative payment types to Worldpay

value object classes that are used to generate the XML to send to Worldpay. The Dozer mapping can be

changed to define new payment types or to alter how existing ones are mapped.

The mapOnlineType method of the WorldpayPaymentTypeMapper currently sets the following properties:

Success URL

Cancel URL

Failure URL

Shopper Bank Code

Steps to add new type:

1. Add a mapping similar to the one below to dozer.worldpay.payment.types.xml

2. Add Payment Type to paymentTypeClassMap on OrderTools which which uses

a WPRedirectPaymentGroup (key should map to that used in WorldpayPaymentTypeMapper)

3. Select new Payment Group type from BillingInfoFormHandler

1.30 How To Add A New Payment Type for The Direct Model

The component WorldpayPaymentTypeMapper uses Dozer to map payment types (credit cards) to

Worldpay value object classes that are used to generate the XML to send to Worldpay. The Dozer mapping

(dozer.worldpay.payment.types.xml ) can be changed to define new payment types or to alter how existing

ones are mapped.

The mapper determines the type of value object to be created, and then inspects the object to determine

what properties it holds. Each property that the mapper knows how to map will be populated from the

payment group. Currently there is support for populating the following properties

Card number

Card verification number (CCV)

<mapping map-id="wpPayPal">

<class-a>com.worldpay.model.vo.internal.OnlinePaymentVO</class-a>

<class-b>com.worldpay.model.vo.external.PAYPALEXPRESS</class-b>

</mapping>


Card holder name

Card holder address

Start date

Expiry date

Issue number


1.30.1 Customisation

The following additional opportunities to customise the mapping exist:

Called after all the out-of-the-box supported properties are mapped. Default implementation is blank, so

exists just as an extension point to add custom property mapping

Methods to map each of these properties. Can be overridden if default implementation is not sufficient.

1.30.2 How to Switch REST Implementations

The Worldpay plugin uses the open source library RESTEasy to handle HTTP communication and

XML marshalling. Both the WorldpayEndPoint and the OrderNotificationEndPoint are annotated for use

with RESTEasy. The WorldpayEndPoint is used for all outgoing communication and is generally used in

conjunction with the PaymentService and DirectCommercePaymentService.

The OrderNotificationEndPoint is used for incoming communication from Worldpay in the form of

Order Notification messages.

RESTEasy: www.jboss.org/resteasy

Worldpay DTD: dtd.Worldpay.com/v1

protected void mapAdditionalProperties(WPDirectPaymentGroup paymentGroup, Object card)

throws WorldpayException;

protected void mapIssueNumber(WPDirectPaymentGroup paymentGroup, Object card) throws

IllegalAccessException, InvocationTargetException, NoSuchMethodException;

protected void mapCardAddress(WPDirectPaymentGroup paymentGroup, Object card) throws


protected void mapStartDate(WPDirectPaymentGroup paymentGroup, Object card) throws


protected void mapExpiryDate(WPDirectPaymentGroup paymentGroup, Object card) throws


protected void mapCardNumber(WPDirectPaymentGroup paymentGroup, Object card) throws


protected void mapCardHolderName(WPDirectPaymentGroup paymentGroup, Object card)

throws IllegalAccessException, InvocationTargetException, NoSuchMethodException;

http://www.jboss.org/resteasy/

http://dtd.worldpay.com/v1/


1.30.3 How to Implement Iframe Checkout

Worldpay provide a javascript library for embedding HPP pages. Details of this and the integration steps

required can be found in the Embedded integration guide. Note that the helper.html from Worldpay

is provided within the plugin, but can be placed elsewhere on your site if required. The plugin provides the

data to pass to the library, but any other front end changes will be implementation specific.

Configuration

As iframe checkout uses hosted payment pages (HPP) it is necessary to provide an id for your HPP

installation. This should be set in the IframePaymentService component configuration.

Initiating an Iframe checkout

The IframePaymentService is used to initiate the iframe payment.

The initiateRedirectPayment method should be passed the path info of the page hosting the iframe.

This returns an IframeRedirectPaymentData bean which contains the data the front end will need in order

to render the iframe. The property names in this bean correspond to the properties on the custom options

object for the WorldPay embedded HPP library. This data will need to be passed to your front end in an

appropriate way so that it can be passed to the embedded HPP library.

Checkout process

Once the payment is submitted from within the iframe, the checkout process should continue as a regular

redirect payment. The only difference from this is that the response from Worldpay does not include an

authorised amount. So authorisation must be determined via a Worldpay authorisation notification. For

this reason the order state after performing an Iframe checkout will initially be

PENDING_PAYMENT_CONFIRMATION.

1.30.4 How to Implement Client Side Encryption

To implement payments using CSE the WPEncryptedPaymentGroup payment group type should be

used. An instance should be created for the order. After processing, the rest of the checkout / order

processing is the same as any other Direct checkout.

Configuration

The configuration settings are stored in /worldpay/config/EncryptionSettings. This is a simple bean that can

be used to store the URL to the Worldpay library and your public key. However, delivering these values to

the FE is implementation specific.

public IframeRedirectPaymentData initiateRedirectPayment(String currentPath) throws

CommerceException, NoMerchantFoundException, WorldPayException { ... }

http://support.worldpay.com/support/kb/gg/pdf/hpp-embedded.pdf


1.31 Populating the payment group

Other than the billing address, WPEncryptedPaymentGroup has just one property that needs to be

populated to make a payment - encryptedData. This is a string value that needs to be set to the value

obtained via the Worldpay javascript library

1.31.1 Taking payment

Payment is initiated in the same way as unencrypted direct payments, using

the DirectCommercePaymentService

1.31.2 Accessing card details after payment

The card type, expiry date and masked card number will be available on the payment group after an

authorisation notification has been received.

Notifications need to be enabled in Worldpay to support this. Also the expiry date is not sent by default,

but can be switched on by Worldpay

How to Switch the JAX-RS Implementation

The app server in use may be using a different JAX-RS implementation than the RESTEasy default provided

by the plugin. This can however, be swapped to a different implementation.

1.31.3 Existing Module Structure

Module Description

Worldpay.REST.RESTEasy3 Extends Worldpay.REST.jax-rs-2 with RESTEasy 3 specific additions

Worldpay.REST.RESTEasy2 Provides a jax-rs 1.1 RESTEasy 2 implementation of WorldpayGateway and

supporting code

public DirectPaymentData createDirectPayment(

WPOrder order, WPPaymentGroup paymentGroup, Profile profile, Map<String, String>

merchantPropertyMap, AdditionalOrderData additionalOrderData)

throws NoMerchantFoundException, WorldPayException, CommerceException { ... }

https://jax-rs-spec.java.net/


Worldpay.REST.jax-rs-1 Provides jax-rs 1.1 API jar. Currently no code or config

Worldpay.REST.jax-rs-2 Provides jax-rs 2.0 API jar and common generic jax-rs 2.0 code and config

To switch implementations ensure that the correct base jax-rs module and corresponding implementation

specific modules are used within the project.

1.31.4 Creating a New Implementation

To create a new implementation specific module (for example, for Jersey) you will need to create a module

following the approach for RESTEasy. The module should depend on whether Worldpay.REST.jax-rs-

1 or Worldpay.REST.jax.-rs-2. It should contain the following:

Jars for the implementation

An Implementation of WorldpayGateway

WorldpayGateway.properties

1.31.5 Implementation of the WorldpayGateway

This class is extended to customise the entity provider for mapping the request XML so that

the DOCTYPE header is added. Please refer to the entity() method in RESTEasy3WorldpayGateway for an

example.

1.31.6 Implementation of the WorldpayClientBuilder

The WorldpayClientBuilder is subclassed to provide configuration of HTTP proxy aqnd connection timeout

settings. Again, refer to WorldpayResteasyClientBuilder for an example.

1.31.7 Amendments to web.xml

RESTeasy is implemented as a ServletContextListener and a Servlet and deployed within

a WAR file. Therefore, depending on your implementation you may need to amend the web.xml to map

the OrderNotificationEndpoint.

For RESTeasy the following is added. It will differ for other implementations.


<context-param>

<param-name>resteasy.servlet.mapping.prefix</param-name>

<param-value>/order_notification</param-value>

</context-param>

...

<servlet>

<servlet-name>OrderNotificationServlet</servlet-name>

<servlet-class>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher</servlet-class>

</servlet>

...

<servlet-mapping>

<servlet-name>OrderNotificationServlet</servlet-name>

<url-pattern>/order_notification/*</url-pattern>

</servlet-mapping>


1.31.8 Connection Endpoint Caching

The plugin employs lightweight caching of the connection endpoints used to connect to Worldpay.

Endpoints are stored keyed upon merchant code per instance, which means that

connection provisioning speed is improved once a connection to Worldpay has been established. Because

the endpoint contains credential information this means that a change to a merchant code's password will

require the cache to be cleared. This can be achieved in two ways:

Call doStartService() on the /Worldpay/service/gateway/WorldpayGateway component from dyn

admin

Restart instance

Message Logging

In order to view xml messages sent to and from Worldpay via the gateway and via asynchronous Worldpay

notifications, enable loggingDebug in the following components within dyn admin:

/worldpay/util/WorldPayLogger

/worldpay/service/gateway/WorldPayGateway

/worldpay/order/notification/dms/OrderNotificationDMSSink

jax-rs 1.0

To enable logging for the max-rs 1.0 implementation, enable logging for the org.apache.http package

in your logging implementation provider.

For example when using Log4j use the following addition to your XML definition (please ensure your

appender is configured correctly for the given priority level):

<category name="org.apache.http">

<priority value="DEBUG"/>

</category>

To enable logging and output of the message conversation with Worldpay in Weblogic we needed to switch

to log4j logging. To do that:

1. In the WL Admin console go to your server's Logging tab, then click on Advance. In the logging

implementation select Log4j

2. Copy the log4j jar file (attached to this page) and ${WL_HOME}/server/lib/wllog4j.jar to the

server classpath (for instance to your domain's lib folder)

3. Copy your log4j.xml to the domain's home directory. An example is attached to this page.

4. Restart your server


jax-rs 2.0

To enable logging for the jax-rs 2.0 implementation, the message conversation with Worldpay can be

logged simply by enabling loggingDebug on the WorldpayGateway component as mentioned above. Actual

logging is performed by the EntityLoggingFilter class and it will log request headers in addition to

the XML body..

protected String tokenName(WPOrder order, TokenisedPaymentData tokenisedPaymentData) {

Worldpay Oracle Commerce Plugin Implementation Guide > Appendix A: Software End User License Agreement 49

Appendix A: Software End User License Agreement

www.worldpay.com Software End User License Agreement 1.

This Software End User License Agreement ("Agreement") is between you (both the individual

downloading and/or installing the Software and any legal entity for which the individual is acting)

("You" or "Your") and WORLDPAY (UK) LIMITED ("Worldpay").

TAKING ANY STEP TO SET UP, DOWNLOAD OR INSTALL THE SOFTWARE MEANS THAT

YOU ACCEPT ALL OF THE TERMS OF THIS LICENSE AGREEMENT. PERMISSION TO

DOWNLOAD, INSTALL AND/OR USE THE SOFTWARE IS EXPRESSLY CONDITIONED ON

YOU FOLLOWING THESE TERMS. IF YOU DO NOT AGREE TO ALL OF THE TERMS OF THIS

AGREEMENT, YOU ARE NOT AUTHORISED TO USE THE SOFTWARE AND MUST STOP

INSTALLING IT OR UNINSTALL IT, AS APPLICABLE.

THIS SOFTWARE IS TO BE USED SOLELY IN CONNECTION WITH THE THIRD PARTY

SOFTWARE AND YOU MUST SATISFY YOURSELF THAT THIS SOFTWARE IS SUITABLE

FOR YOUR NEEDS AND THAT YOUR SYSTEM SATISFIES THE REQUIREMENTS FOR THE

USE OF THIS SOFTWARE AS SET OUT IN THE DOCUMENTATION.

1. DEFINITIONS 1.1 "Documentation" means written documentation, specifications and help

content made generally available by WorldPay to aid in installing and using the Software, or

otherwise provided by WorldPay to you in connection with the Software. 1.2 "Software" means

Oracle Commerce plugin, the data supplied with such software and the associated media and any

upgrades or updates of such software provided by WorldPay to you.

1.3 “Third Party Software” means the third party software with which the Software is designed to

be used, as described in the Documentation.

2. SOFTWARE LICENSE 2.1 Limited License. Subject to this Agreement's restrictions, WorldPay

grants to You a limited, revocable, non-exclusive, non-transferable, royalty-free license (without the

right to sublicense): (a) to install a single copy of the Software on the equipment containing the

Third Party Software, solely for the purpose of using the Software in connection with the Third

Party Software and WorldPay’s own products, as described in the Documentation ("Authorised

Use"); (b) to use the Documentation in support of Your Authorised Use; and (c) to make one copy

of the Software solely for backup purposes, provided that all titles and trademark, copyright and

restricted rights notices are reproduced on the copy. 2.2 Ownership. WorldPay or its licensor

retains all right, title and interest in and to all patent, copyright, trademark, trade secret and other

intellectual property rights in the Software and Documentation, and any derivative works thereof.

You do not acquire any other rights, express or implied, beyond the limited license set forth in this

Agreement. 2.3 No Support. WorldPay has no obligation to provide support, maintenance,

upgrades, modifications or new releases for the Software or Documentation under this Agreement.

www.worldpay.com Software End User License Agreement 2.

Worldpay Oracle Commerce Plugin Implementation Guide > Appendix A: Software End User License Agreement 50

3. RESTRICTIONS

3.1 You undertake not to:

(a) rent, lease, sub-license, loan, translate, merge, adapt, vary or modify the Software or

Documentation;

(b) make alterations to, or modifications of, the whole or any part of the Software, nor permit the

Software or any part of it to be combined with, or become incorporated in, any other software other

than the Third Party Software as described in the Documentation;

(c) disassemble, decompile, reverse-engineer or create derivative works based on the whole or

any part of the Software nor attempt to do any such thing;

(d) provide or otherwise make available the Software in whole or in part (including but not limited to

program listings, object and source program listings, object code and source code), in any form to

any person other than your employees without the prior written consent of WorldPay.

4. WARRANTY DISCLAIMER THE SOFTWARE AND DOCUMENTATION ARE PROVIDED "AS

IS" WITHOUT ANY REPRESENTATIONS OR WARRANTIES, AND YOU AGREE TO USE THEM

AT YOUR SOLE RISK. TO THE FULLEST EXTENT PERMISSIBLE BY LAW, WORLDPAY

EXPRESSLY DISCLAIMS ALL WARRANTIES OF ANY KIND WITH RESPECT TO THE

SOFTWARE AND DOCUMENTATION, WHETHER EXPRESS, IMPLIED OR STATUTORY,

INCLUDING ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR

PURPOSE, SATISFACTORY QUALITY, ACCURACY, TITLE OR NON-INFRINGEMENT OF

THIRD PARTY RIGHTS.

5. LIMITATION OF LIABILITY

IN NO EVENT WILL WORLDPAY OR ITS AFFILIATES BE LIABLE IN CONNECTION WITH THIS

AGREEMENT OR ITS SUBJECT MATTER, UNDER ANY THEORY OF LIABILITY, FOR ANY

INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL OR PUNITIVE DAMAGES, OR

DAMAGES FOR LOST PROFITS, REVENUE, BUSINESS, SAVINGS, DATA, USE, OR COST OF

SUBSTITUTE PROCUREMENT, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH

DAMAGES OR IF SUCH DAMAGES ARE FORESEEABLE. IN NO EVENT WILL WORLDPAY’S

LIABILITY FOR ALL DAMAGES EXCEED THE AMOUNTS ACTUALLY PAID BY YOU TO

WORLDPAY FOR THE SOFTWARE. THE PARTIES ACKNOWLEDGE THAT THE LIABILITY

LIMITS AND RISK ALLOCATION IN THIS AGREEMENT ARE REFLECTED IN THE SOFTWARE

PRICE AND ARE ESSENTIAL ELEMENTS OF THE BARGAIN BETWEEN THE PARTIES,

WITHOUT WHICH WORLDPAY WOULD NOT HAVE PROVIDED THE SOFTWARE OR

ENTERED INTO THIS AGREEMENT.

6. TERMINATION This Agreement is effective until terminated. WorldPay may terminate this

Agreement at any time upon Your breach of any provision. If this Agreement is terminated, You will

stop using the Software, permanently delete it from the equipment where it resides, and destroy all

copies of the Software and Documentation in Your possession, confirming to WorldPay in writing

that You have done so. Sections 2.2, 2.3, 3, 4, 5 and 7 will continue in effect after this Agreement's

termination.

Worldpay Oracle Commerce Plugin Implementation Guide > Appendix B: Changes to this Guide 51

7. GENERAL TERMS 7.1 Law. This Agreement and all matters arising out of it are governed by

the laws of England and Wales, and the parties irrevocably consent to the exclusive jurisdiction of

the courts of England. Application of the United Nations Convention on Contracts for the

International Sales of Goods is expressly excluded. 7.2 Severability and Waiver. If any provision of

this Agreement is held to be illegal, invalid or otherwise unenforceable, www.worldpay.com

Software End User License Agreement 3.

that provision will be enforced to the extent possible or, if incapable of enforcement, deemed to be

severed and deleted from this Agreement, and the remainder will continue in full force and effect. The

waiver by either party of any default or breach of this Agreement will not waive any other or subsequent

default or breach. 7.3 No Assignment. You may not assign, sell, transfer, delegate or otherwise dispose

of this Agreement or any rights or obligations under it, whether voluntarily or involuntarily, by operation of

law or otherwise, without WorldPay’s prior written consent. Any purported assignment, transfer or

delegation by You will be null and void. Subject to the foregoing, this Agreement will be binding upon and

will inure to the benefit of the parties and their respective successors and assigns. You agree, represent

and warrant that You will not export the Software or any underlying technology in contravention of any

applicable U.S. or foreign export laws and regulations. 7.4 Entire Agreement. This Agreement constitutes

the entire agreement between the parties and supersedes all prior or contemporaneous agreements or

representations, whether written or oral, concerning its subject matter. This Agreement may not be

modified or amended without WorldPay’s prior and express written consent, and no other act, document,

usage or custom will be deemed to amend or modify this Agreement.

Appendix B: Changes to this Guide

Revision Release

date Changes

2.0 May 2015 Guide rebranded and reformatted.

1.10 19th Feb

2015

Added details on queue redelivery configuration.

1.09 17th Feb

2015

Worldpay Payment options for the checkout, updated information about

notification module.

1.08 20th May

2014

Added details on configuring MAC Code shared secret.

Table 1: Changes to the guide

Worldpay Oracle Commerce Plugin Implementation Guide > Contact us 52

Corporate support: +44 (0)1268 500612

Email: [email protected]

Worldpay Support Centre: http://www.worldpay.com/support/gg

© Worldpay 2017. All rights reserved.

Worldpay, the logo and any associated brand names are all trademarks of the Worldpay group of companies.

1.

worldpay oracle commerce plugin implementation guide

Documents