Wave2 Finance NonEBS ePay AID V1.4

8/3/2019 Wave2 Finance NonEBS ePay AID V1.4

http://slidepdf.com/reader/full/wave2-finance-nonebs-epay-aid-v14 1/52

Application Information Document (AID)

MAINTENANCE & DEVELOPMENT SERVICES

Elsevier ePay Application Information Document

Wave2_Finance_NonEBS_ePay_AID_V1.3 1




Project name CBS Modernisation

Document title ePay Application Information Document (ePay AID)

Version 1.4

Created date 22-Apr-2010Created by Infosys

Location To be updated later

References

Copies to

Changes History

Version Date Author Commentary

1.0 26-Mar-2010 Infosys First version sent for review

1.1 31-Mar-2010 Infosys Enhance the document with review comments

1.2 12-Apr-2010 Infosys

Addition of individual flow diagrams and modifications in the technical

flow of Batch Processor

1.3 14-Apr-2010 Infosys

Incorporated the suggested changes from Reverse KT session and AID

review comments

1.4 22-May-2010 Infosys Incorporated the SS activities, support and configuration information.

Sign off:

Business Area Sign off Role Date





CONTENTS

1. .INTRODUCTION TO THE APPLICATION INFORMATION DOCUMENT ................................................. .5

1.1 AUDIENCE..............................................................................................................................................................5

1.2 R ECOMMENDED USE................................................................................................................................................5

1.3 TEXT CONVENTIONS & ACRONYMS............................................................................................................................51.4 FLOW DIAGRAM CONVENTIONS.................................................................................................................................6

1. EXECUTIVE SUMMARY ............................................................................................................................. ......7

1.1 DESCRIPTION OF THE APPLICATION.............................................................................................................................7

1.2 APPLICATION CONTEXT DIAGRAM..............................................................................................................................7

1.3 BUSINESS (PROCESS) OVERVIEW................................................................................................................................8

1.4 FUNCTIONAL FLOW:.................................................................................................................................................9

1.5 SYSTEM OVERVIEW................................................................................................................................................11

1.6 PCI COMPLIANCE:................................................................................................................................................11

1.7 FUTURE EPAYMENT SOLUTION:................................................................................................................................12

1.8 VERSION I NFORMATION...........................................................................................................................................12

2. OPERATING ENVIRONMENT ................................................................................................................. .......13

2.1 HARDWARE CONFIGURATION (PRODUCTION)..............................................................................................................13

2.2 SOFTWARE CONFIGURATION....................................................................................................................................13

2.3 E NVIRONMENT DETAILS..........................................................................................................................................13

3. DATABASE OBJECTS: ....................................................................................................................... ........ ......17

3.1 E-R DIAGRAM......................................................................................................................................................17

3.2 K EY TABLES.........................................................................................................................................................17

4. TECHNICAL OVERVIEW ...................................................................................................................... ........ ..17

4.1 LUHN ALGORITHM.................................................................................................................................................17

4.2 PROPERTIES FILES:.................................................................................................................................................18

4.3 ELS TOKEN SERVICE............................................................................................................................................194.4 TOKEN TRANSFORMER :...........................................................................................................................................26

4.5 PAYMENT SERVICE ................................................................................................................................................29

4.6 EPAYMENT CARD TOKENISER ..................................................................................................................................34

4.7 BATCH PAYMENT PROCESSOR ..................................................................................................................................38

4.8 R ELEASE PROCESS.................................................................................................................................................40

6. TICKET R ESOLUTION PROCESS AND R EPORTING...........................................................................................................41

7. CONFIGURATION MANAGEMENT PROCEDURE/TOOL......................................................................................................46

7.1 DATABASE ADMINISTRATION PROCEDURE (BACKUPS & R ECOVERY)............................................................................46

7.2 JOB SCHEDULING/SEQUENCING OF BATCH JOBS........................................................................................................47

7.3 APPLICATION STABILITY........................................................................................................................................49

8 ERROR AND LOG HANDLING ....................................................................................................................................50

9.0 ISSUES & SUGGESTIONS (FOR ENHANCEMENTS) ............................................................................. ..50

9.1 ISSUES.................................................................................................................................................................50

9.2 SUGGESTIONS.......................................................................................................................................................50

10. APPLICATION SUPPORT AND MAINTENANCE .......................................................................... .........50

10.1 COMMON PROBLEMS...........................................................................................................................................50

10.2 CRITICAL PROBLEMS...........................................................................................................................................50

11. GLOSSARY OF BUSINESS TERMS .............................................................................................................50

1. ABBREVIATIONS ............................................................................................................................... ........ ......50

2. REFERENCES ....................................................................................................................................................50

3. CONTACT INFORMATION ............................................................................................................................ ..50





4. APPLICATION ARTEFACTS (INVENTORY) .................................................................................................51

5. SETTING UP THE DEVELOPMENT ENVIRONMENT OFFSHORE ........................................... ......... ....52

6. ESCALATION AND NOTIFICATION PROCESS ............................................................................................52

7. PROCEDURE TO REQUEST ACCESS TO APPLICATION ............................................................... ........ ...52





1. .Introduction to the Application Information Document

The purpose of this document is to capture the knowledge that is transitioned to Infosys during Knowledge

Transfer Sessions. It covers the basic functional overview and technical details of ePay application.

1.1 Audience

The audience for this document are SMEs and Infosys support team.

1.2 Recommended Use

This document is intended to provide detailed understanding of the application and would cover the topics

discussed in the KT sessions. This is not intended to provide detailed design of the application. For such

reference, appropriate artefacts from the knowledge repository would have to be referenced.

SMEs are expected to review the updates to the AID based on knowledge transfer sessions. This would providefeedback to the SMEs on transition progress and readiness of the Infosys support team to move over to Shadow

Support phase. This would provide a ready reference to the Infosys support team to consult on application

specific areas during Steady Support phase.

1.3 Text Conventions & Acronyms

Acronym Definition

XML Extensible Markup Language

ST ELS Short Token

CC Payment Card

LN Lexis Nexis

PCI Payment Card Industry

GCML Global Collect Merchant Link





1.4 Flow Diagram Conventions

Symbol Name

Process

Decision

Document

Terminator

Manual Operation





1. Executive Summary

This document describes the basic functional overview of ePay application along with different ePay technical

components, release processes and error monitoring.

1.1 Description of the Application

Elsevier’s ePay application is centrally managed system to authorise & process the payment cards from the

different fulfilment systems where delta and erenewals are current users for payments cards and ARGI, COPS

use eToken. It supports both online transactions processing as well batch processing of transactions. Once the

validations are done ePay will communicate the payment card details along transaction amount to 3rd party

payment processor (Global Collect). Payment processor is responsible for the collection of funds from the

customers. This application is PCI Compliant.

1.2 Application Context Diagram

Following is a diagram depicting the ePay application overview

Note:

This architecture diagram is specific to Delta fulfilment application. For other applications it may differ.This architecture diagram is taken from the Elsevier reference materials

(Documentation for Infosys\ePay Documentation for Infosys/ ePayEnhancedArchitecture.ppt)





1.3 Business (Process) Overview

ePay application is a system-to-system interface for fulfilment systems like Delta and Online applications which

provides following functionalities,

• Online or Batch processing of Payment Cards

• Payment card number validation

• ST/GUID/CC number transformation.

• Supports 24/7 card process (excluding planned outages) and it does not require interrupting the card

process even if new configuration is added to the ePay application.

CC: Payment card number length can be range from 12 to 19 digits, depending upon the type of card

Example: visa, master etc.,

GUID: This is alpha numeric code of length 36, supplied by LN Middleware for a given Payment card number.

ST: ELS Short token is alpha numeric code of length 16, derived by ePay application and used by fulfilment

applications instead of GUID or CC. It can be identified by first two digit should be alpha and next four digitshould be a number.

ePayment enterprise application is collection of web services and web applications which provides different

functionality related to payment card processing. Such as

1. ELS Token Service: This is a web service which allows fulfillment application to transform from

GUID/CC/ST to GUID/CC/ST tokens.

2. Payment Service: Fulfilment applications sends the payment card details to payment service, which in

turn validates the CC details and passes the CC details to configured payment processor.

3. Batch Payment: Process the payments from Drop Zone.

4. Card Tokeniser: This is web applications that enables the fulfiment application users to generate the ST

for valid Payment Card number.5. Test Card Tokeniser: This is web application that enables with the list of test payment card for different

source which is captured in TestCardForSystems.xml.and generate the ELS token for the given card

number. This will point to test environment of LN Middleware applciation

LN Middleware: This middleware application resides in Lexis Nexis purple secure network (US) to manage the

Payment card information. It is a central repository for the applications to store and get the Payment card

information. It has mapping for payment card number with GUID, encrypted ID and expiry date of GUID. This

application is PCI compliant.

GlobalCollect: This is the world's premier Payment Service Provider of local online payment solutions for

international Customer. This is a single web-enabled interface; GCML online payment platform offers the largest

range of preferred local payment methods in over 200 countries and for 170 currencies, including:

• International and national payment cards

• Direct debits

• Real-time bank transfers

• Bank transfers

• Cash payment and bill payments

• eWallets

• Prepaid methods

• Checks

Currently Elsevier uses only the “International and national payment cards payment method”.





1.4 Functional Flow:

1) Payment through Delta Customer Service: This flow diagram will explain about the order capture

through customer care service and the payment card process.

Delta Customer Service

ePayment Enterprise Applicaiton

Card Tokenizer (Web Application)

ELS Tokenisation Service

Order Capture

Customer by Call

Delta UI(Vista Client App)

6 EID

LN Middle1 CC

8 ST

4 CC

5 EID

7 ST2 CC 3 CC

Inventory CheckOrder Quantity < Inventory

Quantity

No

Drop Zone

Online Payment Service(Sevice)

YesPmtAuth(ST)

Global Collect(Payment Proces

PmtAutCC

ePayment Batch Processor for

Delta(Integration Component)

ST

PmtAuth (ST)

9 ST

10 EID

11 CC

12 CC

ePayment

Response

Response

Note : In scopeComplianc

Back Order

Cut & Paste the ST from CardTokenizer Application to Delta

UI instead of CC Number

ST

Response

Delta(fulfillment system)





2) Payment through Web Order Capture Solutions: This flow diagram will explain Web Order capture

and the payment card process

Web Order Capture Solutions

(eCommerce web sites)

Web Orders Integration for Delta

(Integration Component)

LN Middleware

Global Collect(Payment Processor)

Drop Zone

Drop Zone

New Order (GUID)

New Order (ST)

Note : In scope of PCICompliance

1 CC

2 GUID



Online Payment Service(Sevice)

3 GUID

6 ST

4 GUID 5 EID

ePayment Batch Processor for

Delta(Integra tion Component)

PmtAuth (CC)

PmtAuth (ST)

PmtAuth (ST)

7 ST

8 EID

9 CC

10 CC

ePayment DB

Response

Response

Delta(fulfillment system)

3) Payment through Web Apps: This flow diagram will explain Web Apps order capture and the

payment card process for the authorised GUID.

Web Apps

Note : In scope of Compliance

LN Middleware


Online Payment Service(Sevice )

Drop Zone

PayAuth GUID

2 CC & EID

1 GUID

Global Collect

(Payment Processor )

PayAuth CC

ePayment DB


3 EID 4 ST

Delta

(fulfillment system )

Response





1.5 System Overview

There are clear business and operational benefits in having a centrally managed service for payment processing

across the organisation. They are as follows.

• One centrally managed system

• One set of simple, standard payment transactions.

• One hardware/Software infrastructure

• One audit solution

• One security infrastructure

• Can use multiple 3rd Party payment processors

• Easy to integrate with new order handling systems.

1.6 PCI Compliance:

The Payment Card Industry Data Security Standard (PCI DSS) is a worldwide information security standard

defined by the Payment Card Industry Security Standards Council. The standard was created to help

organizations that process card payments prevent payment card fraud through increased controls around data andits exposure to compromise. The standard applies to all organizations which hold, process, or exchange

cardholder information from any card branded with the logo of one of the card brands.

As per PCI Compliance, if any application handles the Payment Card information those applications should

come under PCI compliance audit. This is very expensive to do audit for all fulfilment applications. In order to

overcome this issue, Elsevier has updated ePay to handle ST and GUIDS utilising LNMW service. Invoicing

systems may now use either LNMW directly to store CC and get GUID or manually use ePay wToken web

application to get ST. Tokens (GUID/ST are now stored in invoicing systems thus removing the costly

implications of PCI audits. Only ePay applications and LNMW are in scope for PCI audits. LN has developed

LN Middleware application which manages the Payment Card information on behalf of Fulfilment application in

turn it gives GUID and Encrypt Data ID to identify the records. The length of GUID is 36. But Elsevier

fulfilment applications cannot hold GUID instead of CC number due to size restriction on CC number.

ePay team has come up with ST concept which is equivalent to GUID and whose length is 16.

Note: Transformation of ST to Encrypt ID and vice versa has been explained in detail in the following sections.


http://en.wikipedia.org/wiki/Information_security

http://en.wikipedia.org/wiki/Information_security




1.7 Future ePayment solution:

This architecture diagram is taken from the Elsevier reference materials (Documentation for Infosys\ePay Documentation for Infosys/ ePaymentService Overview.ppt)

1.8 Version Information

Production:

Component VersionePayment V2.0

ePay V3.2

ELSToken 1.2

WebToken 1.2

Note: The above information is as on 19th Mar 2010.





2. Operating Environment

2.1 Hardware Configuration (Production)

Application server : IBM Websphere 6

Data Base : Oracle 10g

2.2 Software Configuration

Java, J2EE, XML, XSLT, SQL, PL/SQL

2.3 Environment Details

2.3.1 Development

Name URL

Websphere Admin (ePay) http://elsoxfappd006.science.regn.net:9061/ibm/console

ePayment Web Service http://elsoxfappd006:9081/ePay/services/PaymentService

ELS Token Web Service http://elsoxfappd006:9081/eToken/services/PaymentService

Test Card Tokeniser Web

Application mode =TEST

http://elsoxfappd006:9081/wToken/servlet/TestCardTokeni

ser?action=displayCardList&system=PeopleSoft

Card Tokeniser Web Application

mode =PROD

http://elsoxfappd006:9081/wToken/servlet/CardTokeniser

Name Database

Database Server DEPAY

2.3.2 Acceptance

Server 001

Name URL

Websphere Admin (ePay) http://elsoxfappt001.science.regn.net:9061/ibm/console

ePayment Web Service https://eservices-

test1.elsevier.com:9446/ePay/services/PaymentService

ELS Token Web Service https://eservices-

test1.elsevier.com:9446/eToken/services/ELSTokenService

http://elsoxfappt001:9081/eToken/services/ELSTokenService

Card Tokeniser Web

Application

https://eservices-

test1.elsevier.com:9446/wToken/servlet/CardTokeniser

Card Tokeniser Web

Application(all) mode

=TEST

https://eservices-

test1.elsevier.com:9446/wToken/servlet/TestCardTokeniser?

action=displayCardList


http://elsoxfappd006.science.regn.net:9061/ibm/console

http://elsoxfappd006:9081/ePay/services/PaymentService

http://elsoxfappd006:9081/eToken/services/PaymentService

http://elsoxfappd006:9081/wToken/servlet/TestCardTokeniser?action=displayCardList&system=PeopleSoft



http://elsoxfappt001.science.regn.net:9061/ibm/console

https://eservices-test1.elsevier.com:9446/ePay/services/PaymentService


https://eservices-test1.elsevier.com:9446/eToken/services/ELSTokenService



https://eservices-test1.elsevier.com:9446/wToken/servlet/CardTokeniser


https://eservices-test1.elsevier.com:9446/wToken/servlet/TestCardTokeniser?action=displayCardList



http://elsoxfappd006.science.regn.net:9061/ibm/console


http://elsoxfappd006:9081/eToken/services/PaymentService


















Server 002

Name URL


ePayment Web Service https://eservices-test2.elsevier.com:9446/ePay/services/PaymentService




Card Tokeniser Web

Application

https://eservices-


Card Tokeniser Web


=TEST

https://eservices-



Server 003

Name URL







Card Tokeniser Web

Application

https://eservices-


Card Tokeniser Web


=TEST

https://eservices-



Server 004

Name URL







Card Tokeniser Web

Application

https://eservices-


Card Tokeniser Web


=TEST

https://eservices-



Name Database

Database Server AEPAY







































































2.3.3 Production

Server 016

Name URL

Websphere Admin (ePay) server 016 http://elsoxfappp016.science.regn.net:9061/ibm/console

ePayment Web Service (PCI) https://eservices.elsevier.com:9444/ePay/services/Payme

ntService

ELS Token Web Service https://eservices.elsevier.com:9446/eToken/services/EL

STokenService

Card Tokeniser Web Application mode= PROD

https://eservices.elsevier.com:9446/wToken/servlet/CardTokeniser

Server 017

Name URL



ntService


STokenService

Card Tokeniser Web Application mode

= PROD

https://eservices.elsevier.com:9446/wToken/servlet/Card

Tokeniser

Server 018

Name URL



ntService


STokenServiceCard Tokeniser Web Application mode

= PROD

https://eservices.elsevier.com:9446/wToken/servlet/Card

Tokeniser

Server 019

Name URL



ntService


STokenServiceCard Tokeniser Web Application mode https://eservices.elsevier.com:9446/wToken/servlet/Card


http://elsoxfappp016.science.regn.net:9061/ibm/console

https://eservices.elsevier.com:9446/ePay/services/PaymentService


https://eservices.elsevier.com:9446/eToken/services/ELSTokenService


























































= PROD Tokeniser

Name Database

Database Server PEPAY

ePayment Individual Production Servers:

https://elsoxfappp016:9444/ePayment/services/PaymentService




LN Middleware Production Environment

https://prodwaswin.lexisnexis.com:59217/mwareWeb/services/MwWebserviceSecure

LN Middleware Test Environment

https://certwaswin.lexisnexis.com:59217/mwareWeb/services/MwWebserviceSecure

Source: //elsoxfdatp29va/ePayment/environment_info/ePay%20Project%20Environment

%20Information.htm



















3. Database Objects:

3.1 E-R Diagram

EPAY_SENDER_TBL

PK EPAY_SENDER_ID

EPAY_SENDER_NAME

EPAY_SENDER_AUTH_CODE

EPAY_ORD_SYS_ID

GEN_ID

MOD_ID

GEN_DATE

MOD_DATE

EPAY_TRA_TYPE_TBL

PK EPAY_TRA_TYPE_ID

EPAY_TRA_NAME

EPAY_TRA_VERSION

XML_SCHEMA_URL

GEN_ID

MOD_ID

GEN_DATE

MOD_DATE

PAYMENT_PROCESSOR_TBL

PK PROCESSOR_ID

PROCESSOR_CLASS

DESCRIPTION

EPAY_SEN DERS_TRA_TBL

EPAY_SEND ERS_TRA_ID

EPAY_SENDER_ID

EPAY_TRA_TYPE_ID

PROCESSOR_ID

3.2 Key Tables

Tables

EPAY_SENDER_TBLEPAY_SENDERS_TRA_TBLEPAY_TRA_TBLEPAY_TRA_TYPE_TBLEPAY_ORDERING_SYSTEM_TBL

GCML_CARD_PROD_MAP_TBLGCML_CARD_PROD_TBLGCML_ENTITLEMENT_TBLGCML_ORDER_TRA_TBLPAYMENT_PROCESSOR_TBL

4. Technical Overview

4.1 Luhn Algorithm





In 1954, Hans Luhn of IBM proposed an algorithm to be used as a validity criterion for a given set of

numbers. Almost all payment card numbers are generated following this validity criterion…also called as

the Luhn check or the Mod 10 check. It goes without saying that the Luhn check is also used to verify a

given existing card number. If a payment card number does not satisfy this check, it is not a valid number.

For a 16 digit payment card number, the

Luhn check can be described as follows:

1. Starting with the check digit, double the value of every second digit (never double the check digit). For

example, in a 16 digit payment card number, double the 15th, 13th, 11th, 9th…digits (digits in odd

places). In all, you will need to double eight digits.

2. If doubling of a number results in a two digit number, add up the digits to get a single digit number.

This will result in eight single digit numbers.

3. Now, replace the digits in the odd places (in the original payment card number) with these new single

digit numbers to get a new 16 digit number.

4. Add up all the digits in this new number. If the final total is perfectly divisible by 10, then the payment

card number is valid (Luhn check is satisfied), else it is invalid.

5. Example :

Card number: 4552 7204 1234 5678

Reference of above picture is taken from World Wide Web

4.2 Properties Files:

Transform.properties: Mapping of card number is maintained with card prefix, card type and card length. This is

used for validation of card and to generate the short token and encrypt id.





Config.properties: This property file configures the details of ePayment. Information like

GCML URL, IP address.

GCML Error mapping to ePayment Error Types

ePayment Error code

ePayment Error Types

ePayment error message

ePayment error Messages related to payment processor errors

Exception codes for ePayment Service

Error Codes from ELSTokenService

Error Messages from ELSTokenService

LN Middleware Configuration Details

4.3 ELS Token Service

This is a web service used by fulfilment applications to do conversion of different numbers such GUID/ST/CC

to GUID/ST/CC.

GUID, this is LN Middleware identification number.

ST also called as Short Token/ELS Token. This number used by fulfilment application instead of CC

number while creating the transactions, since long guid cannot be used by the fulfilment systems so

need to use short token instead. This short token is derived from the payment card number using token

transformation.

CC: Payment Card Number. LN Middleware: This web service residing in Lexis Nexis purple secure network in US to manage the

CC information. LN Middleware is a central repository for managing the CC information for Elsevier

and LN. This application is PCI complaint. Each record in LN middleware is the combination of GUID,

CC, Encrypt ID and expiry date of GUID

Configuration for senders held in sender_entitlements.xml. This file is used to retrieve response value

or return value for each set of sender that is predefined in this xml file.

4.3.1 Technical Flow:

• This web service invokes the “makePaymentCardEntry” method in

com.elsevier.webservices.token.ELSTokenService class• Log the host details and raise exception if does not find.

• Loads the config.properties and transform.properties property files if it is not loaded already.

o Config.properties : This property file contains

Error messages and codes

Lexis Nexis LN Middleware web service configuration details.

o transform.properties: This property file contains

CC number validation details.

Min and Max values, these values used in CC validation and ST generation.

Valid Length for known card types.

• Load sender entitlements details (GenericConfig) if it is not loaded already.

o Sender’s entitlement is combination of Sender Auth Code, Sender Name, System ID and return

value.o Sender_Entitlements.xml file contains all valid sender entitlements.





• Validate the sender’s entitlement

o Return the Return Type (CC/GUID/ST) as per sender entitlement

o Raise error message if sender’s entitlement does not match with any of the configuration.

• Validate the input request data (getCardType)

o If request data is null then raise error message

o If request data length is 36 then return “GUID”

o If request data length is 16 and first two letters are alpha return “ST”

o Otherwise verify whether requestdata is a CC number

o (TokenTransformer.validateCardLengthForType): This method return boolean

Length of payment card according to the type using transform.properties.

Card validation using Luhn Algorithm

• Derive the “Return Type” using Request Data.( generateTokenByCardType)

o If Input is CC/ST/GUID and Return type is CC (getCC)

If input is CC

• Peform CC validations (validateCardLengthForType – discussed above)

If input is ST

• Derive the encrpt ID (TokenTransformer.getEncryptDataIdForShortToken)

o

Derive the card type using first two characterso Next four characters(2-6) is last four charcters of CC

o Convert remaining numbers (6-last characters) 32 base to 10 base

o Exclude the last number from the conversion number and store the

value in a variable (shortToken)

o Calculate the check digit for the remainder of shortToken using

luhn Algorithm

o Validate the check digit and last digit obtained from “shortToken”

o If not equal then raise error.

o Get the first digit from “shortToken” as variant

o Derive card prefix using “card type” and “variant”

o Raise error if card prefix is not derived.

o Return encryptDataId, cardPrefix + last4Digits + shortToken

• Pass the “encryptDataId” to LN Middleware and get the CC number.

• Raise error if response is null.

• Validate the retrived CC number (validateCardLengthForType – discussed

above)

• Raise error message if it is invalid CC.

• Otherwise return the CC number.

If input is GUID

• Pass the “encryptDataId” to LN Middleware and get the CC number.


• Validate the retrived CC number (validateCardLengthForType – discussed

above)

• Raise error message if it is invalid CC.

• Otherwise return the CC number.

o If Input is CC/ST/GUID and Return type is ST (getST)

If input is CC

• Validate the CC number (validateCardLengthForType – discussed above).

• Pass the CC to LN Middleware and get the GUID and encrypt ids.


• Derive the ST using CC and GUID

(TokenTransformer.getShortTokenForEncryptDataId).

o Derive the card type using CC number.

o Raise error if card type is not derived.

o Get the last four digit of CC (last4Digits)

o Add card variant to encrypt id excluding first 6 digits

o Derive the check digit for variant + encrypt id excluding first 6

digits using Lunh algorithm.





o Convert derived number (variant + encrypt id excluding first 6

digits + check digit) to 32 base number

o Return the ST, card type +last 4 digits of CC + 32 base number

If input is GUID

• Pass the GUID to to LN Middleware and get the CC number and encrypt id.


• Derive the ST using CC and GUID

(TokenTransformer.getShortTokenForEncryptDataId – discussed above)

• Return the ST.

If input is ST

• If input ST is not null then return the ST

o If Input is CC/ST/GUID and Return type is GUID (getGUID)

If input is CC

• Validate the CC number (validateCardLengthForType -- discussed above)

• Pass the CC number to LN Middleware and validate the response.

• Raise error message if response is null.

• Return the GUID.

If input is GUID

• If input GUID is not null then return GUID.

If input is ST

• Derive the GUID using ST

(TokenTransformer.getEncryptDataIdForShortToken – discussed above)


• Pass the GUID to LN Middleware and validate the response.

• Raise error if response is null

• Return the GUID





4.3.2 ELS Token Service Technical Flow:

Start

ConfigurationCache

Loaded

Not Load

Load the config,transform, senders

entitlements

ValidateSenders

Entitlement

No MatchRaise Error

Process the inputrequestdata

If length is 36

If length is 16 and firsttwo letters are chars

Yes

Yes

CC Validation

Input: GUID

Input: ST

Input: CC

A

C

B

R e t ur nE n t i t l e

V al u e

Derive the

Output typeusing Sender’s

entitlementmapping

GUID

CC

ST





Flow A:

AGUID

Input: ST Input: CC

Input: GUID

R ai s eE r r or

Fail

Pass the CC to LNMiddleware

Response Null

Return the GUID

Input length > 0 Fail

R ai s eE r r or

Fail

Pass the ID to LNMiddleware

Response Null

Card typeValidation

Validate the CC

Card type LengthRange Validation

Default LengthValidation

Validate CCNumber using

Luhn Algorithm

Derive Encrypt ID

Derive the CC type

Get the 2-6 charsof ST

Convert the ST (7-16 digits) 32 base

to 10 base number

Validate the check

digit (last digit)using LunhAlgorithm

Validate the Card

Type for two charsof ST and Variant

cardPrefix+last4Digits

+ shortToken





Flow B:

BCC

Input: GUID

Input: CCInput: ST

Card typeValidation

Validate the CC


Default LengthValidation


Luhn Algorithm

Fail

R ai s eE r r or

Pass the GUID toLN Middlware

CC

Return the CC

Derive Encrypt ID

Derive the CC type

Get the 2-6 charsof ST

Convert the ST (7-

16 digits) 32 baseto 10 base number

Validate the checkdigit (last digit)

using LunhAlgorithm

Validate the Card

Type for two charsof ST and Variant

cardPrefix+last4Digits

+ shortToken

Fail

Pass the Encrypt

ID to LNMiddlware

Response Null

CC

R ai s eE r r or

Response Null





Flow C:

C

STInput : ST Input : CC

Input : GUIDCard type

Validation

Validate the CC

Card typeLength Range

Validation

Default Length

Validation

Validate CC

Number usingLuhn Algorithm

R ai s eEr r or

Pass the CC to

LN Middlware

Encrypt ID

Pass the GUIDto LN

Middlware

Response

Null

Encrypt ID

If ST length

>0

R ai s eEr r or

Fail

Return ST

Derive the Card Typeusing transform

properties

Derive ST using GUID and CC

R ai s eEr r or

Fail

Get the last 4 digits

CC Variant + Encrypt ID(Excluding first 6 digits )

Derive the Check Digitusing Lunh Algorithm

Convert to 32 Base Number variant + encrypt id excluding first 6 digits + check digit

Return the STtype +last 4 digits of CC + 32 base number

ResponseNull

4.3.3 Methods

Method Name Description

makePaymentCardEntry() This method generates the token for the request Data element in the Request as

per sender entitlement in the request XML.

generateTokenByCardType(

)

This method generates the token as per the configuration defined for the sender

information in the request XML.

getCardType() This method returns the card type for the token passed in the request Data.

getShortToken() This method returns the ELS generated token for the data passed in the request

Data.

getGUID() This method returns the LN Middleware GUID for the data sent in the request

Data

getCC() This method returns the card number for the data in the request Data.







Step 11) Calculate the check digit using Luhn algorithm using calculateCardNumber(), this method return a

number. The IN parameter is the concatenation of converted ASCII Number from Step 9, Last four digits of

card numbers from Step 4 and derived value from Step 7.

Step 12) Compare the check digit from Step 10 to Last digit from Step 8. If both are same than proceed else

throw exception with error message “Invalid_Short_Token_Message”

Step 13) Get the First digit from the derived value from Step 7. This is called variant. Variant is the number from the card type; this will be the 3 rd character of card type.

Step 14) Remove the first digit from the Step 13.

Step 15) Concatenate the card type from Step 2 with variant from Step 13

Step 16) Get the card prefix from card type from Step 15 using transform.properties.

Last Step 12) Encrypted ID is the derived from Concatenation of card prefix Step from 16, Last four digits

of card numbers from Step 4 and derived value from Step 14.

4.4.3 getShortTokenForCC()

Step 1) Get the Payment Card(CC)

Step 2) Get the Card Type from CC using transform.properties.

Step 3) Get the last four digits of Payment Card

Step 4) Validate for card type IS Null and length of CC greater than zero. If validation succeeds then

proceed further else throw exception with error message ” Card_Type_Unknown_Message”

Step 5) Get the first two characters of card type from Step 2.

Last Step 6) Short Token is the derived from Concatenation of card type from Step 5, last four digits of

CC from Step 3 converted into a number of base 32 and "XXXXXXXXXX".

4.4.4 validateCardLengthForType()

This method validates and return Boolean.

1) Length of Payment card according to the type using transform.properties.

2) Card validation using Luhn Algorithm

getCardType(): This method is used to get the card prefix Get the first 6 digits of card number and check for

card prefix match in transform.properties. Reduce the last digit one by one minimum of 2 until get the

match. Maximum length = 6 and Minimum length = 2 are predefined in transform.properties.

getCardDescription(): This method is used to get the card description. Get the card type and check for

mapping using transform.properties.

validateCardNumber():This method implements the Luhn algorithm to validate the card number

calculateCardNumber(): This method uses Luhn algorithm to get the check digits. It will consider the given

as card number as valid and calculate the check digits.

fromDecimalToOtherBase():This method converts the number from decimal base to 32 base

fromOtherBaseToDecimal():This method converts the 32-base number to decimal base

checkAlphaChar():This method checks if first two characters in text are alphabets

getAsciiFromChar():This method returns the Ascii equivalent for the alphabets

checkDigits():This method checks for the digits in the text string

getCardPrefix():This method returns the card prefix for the card variant

4.4.5 Methods


getShortToken() This method transforms the encryptDataId to ELS token using shorttoken Instance.





getShortTokenForEncryptDataId(

)

This method transforms the encryptDataId to ELS token.

getEncryptDataIdForShortToken(

)

This method transforms the ELS token to encryptDataId.

getShortTokenForCC() This method transforms the card number to ELS token. (i.e. ELSToken

=CardTypeAcronym+Last Four Digits of CC converted to base 32

+XXXXXXXXXX)getCardType() This method returns the card type from the type lookup table

getCardDescription() This method returns the type of the card.

validateCardNumber() This method implements the Luhn algorithm to validate the card number.

calculateCardNumber() This method implements the Luhn algorithm, and calculates the check

digit for number.

fromDecimalToOtherBase() This method converts the number from decimal base to 32 base.

fromOtherBaseToDecimal() This method converts the 32-base number to decimal base.

checkAlphaChar() This method checks if first two characters in text are alphabets.

getAsciiFromChar() This method returns the Ascii equivalent for the alphabets.

checkDigits() This method checks for the digits in the text string.

getCardPrefix() This method returns the card prefix for the card variant.

validateCardLengthForType() This method validates the card - a) for the length according to the type of card, where type is determined through the first 2 digits b) as per Lung

Algorithm

4.4.6 Technical Flowchart





TokenTransformer.java

Encrypted IDTo

Short TokengetShortTokenForEncryptDataId()

Credit Card to Short Token

getShortTokenForCC()

Short Token to Encrypted ID

getEncryptDataIdForShortToken()

getCardType()

IFCard Type IS not

Null and Card Type

length > 0

get the next four digits

of the encrypt ID usingsubstring and this will

be the last four digits of Credit Card

Get the Variant, Thisis the number from the

card type; this will bethe 3rd character of

card type

Concatenate thevariant with rest of all

character fromencrypt id leaving the

first 6 character

calculateCardNumber()Get Check Digit and

concatenate with the endof derived valuefromabove step

Yes

getAsciiFromChar()

fromDecimalToOtherBase()

Convert the above numbers from decimalbase to 32 base

No

get the first twocharacter of the card

type using substring

Get Short TokenConcatenate

1 + 2 + 3

2

3

getCardType()

get the last four digits of

the CC using substring

IF

Card Type IS notNull and Card Type

length > 0

get the first two digits

of the card type using

substring

No

Get Short TokenConcatenate

1 + 2 +

‘XXXXXXXXXX’

Yes

1

2

STATIC Methods

get the first two digitsof the card type using

substring

get the next four digits

of the short token usingsubstring and this will

be the last four digits of Credit Card

IS AlphacheckAlphaCh

ar()

IS Number

checkDigits( )

No

Get the rest of all character from

ST leaving the first 6 Characters

and convert to 32 basefromOtherBaseToDecimal()

Yes yes

Get the last digitusing substring

Remove the last digitusing substring

calculateCardNum

ber() return checkDigits

getAsciiFromChar()Card Type

If 1 = 2

1

2

Get the first digit

using substring

Remove the last digitusing substring

True

1

Concatenate

1 + 2, This is theValid Card Type

2

1

getCardPrefix()

IS Number

checkDigits( )

No

Get Encrypted ID

Concatenate1 + 2 + 3

Yes

1

2

3

4.5 Payment Service





Payment Service is web service, processes the transaction requests which are sent from fulfilment

systems. Transaction request contains payment details along with sender information. Payment Service

validates the CC details and derives necessary information for payment processor such as derivation of

CC number for a given GUID/ST number. Once transaction details are validated then Payment Service

forwards CC payment details to configured Payment Gateway.

Currently ePay supports only one payment gateway which is Global Collect Merchant Link (GCML).But ePay payment service can be configured to support any number of payment gateways.

This architecture diagram is taken from the Elsevier reference materials

(Documentation for Infosys\ePay Documentation for Infosys/ ePaymentService Overview.ppt)

4.5.1 Technical Flow

Step 1: Load the configuration File SystemProperties()

Step 2: Get the XSLT in Cache object

Step 3: Get the Generic config object GenericConfig(). These configurations are done using config.properties

files, which is explained in session 4.2

Step 4: Get the request in to Hashtable.

Encrypt and store the EPAY_SENDER_AUTH_CODE

Step 5: Call getCardNumber().This method is used to find the original request identifier i.e., GUID, ST or CCand retrieve Secure CC and ST information.

Step 6: Get the Maintenance mode of system using the system properties. If maintenance is ‘Y’ log error

”System runs in maintenance mode” and throw exception else proceed further.

Step 7: This method TransactionValidator() validate the sender information and return keysenderconfiguraion

details after validation. The validations are

1) Check for Sender authentication code has been registered with ELS Token webservice

2) Valid configuration for senderAutCode, senderName and systemId.

Step 8: This method is used to find the payment processor PaymentProcessorFactory.java from the database

using the input request data.

EPAY_SENDER_TBL

PK EPAY_SENDER_ID

EPAY_SENDER_NAME

EPAY_SENDER_AUTH_CODE

EPAY_ORD_SYS_ID

GEN_ID

MOD_ID

GEN_DATE

MOD_DATE

EPAY_TRA_TYPE_TBL

PK EPAY_TRA_TYPE_ID

EPAY_TRA_NAME

EPAY_TRA_VERSION

XML_SCHEMA_URL

GEN_ID

MOD_ID

GEN_DATE

MOD_DATE

PAYMENT_PROCESSOR_TBL

PK PROCESSOR_ID

PROCESSOR_CLASS

DESCRIPTION

EPAY_SENDER S_TRA_TBL

EPA Y_SE ND ERS_TRA_ID

EPAY_SENDER_ID

EPAY_TRA_TYPE_ID

PROC ESSOR_ID





Step 9: The above method calls according to the processor. If Processor is GCML then calls

GCML_PaymentProcessor() and if it is BIBIT then calls BIBIT_PaymentProcessor(). Currently we are using

only GCML processor.

Step 10: GCML_PaymentProcessor.processRequest prepare the XML request to Global gateway merchant link.

It will post the request and get the response back.

Get the request and load into a hashtable

Get the GCML_TRA_TYPE_ID FROM the key EPAY_SENDERS_TRA_ID

Get the merchant Id from the Senders_entitlement.xml

Get the GCML_CARD_PROD_CODE, EPAY_ORD_SYS_ID, SYS_PROD_ID,

TRA_NAME, GCML_CARD_PROD_COD

Collect all information and transform as per the GCML input XML format using

DocumentTransformer()

The request is passed to GCML server,

Calculate the time difference between the request and response from GCML.

Transform the DOM response object and record into Database table

Transformed DOM response for client.

Step 11: If response is not null them message “Response received for the request and returning it to the Client"

Step 12: Update the column EPAY_TRA_STATE in EPAY_TRA_TBL table to "Transaction_Completed"

Step 13: Return Transaction Reponses.





4.5.2 Technical Flowchart

Payment ServicePayment Transaction

Get the local host machine

and request transactiondocument

Get the timestamp of request

Load the system

configuration fileSystemProperties()

Get the request

XSLT cache

Get the generic

configuration object

Convert the request data

into Hashtable

Call getCardNumber()

This method is used to find the original

request identifier i .e. GUID, ST or CCand retrieve Secure CC and ST

information

Check for server

maintenance mode

Log error message

and throwexception

Yes

End

TransactionVali

dator()

Check for sender

authentication code has

been registered with ELS

token web service

Valid configuration

for SenderAuthcode,

SenderName and

systemid

PaymentProcessFactory()

This method is used to compar

payment processor from the reparameter in the database wit

value in the method

GCML_PaymentProcessor

Transform the data intoGCML xml format usingDocumentTransformer()

Pass the request to GCM

server

No

If response isnot null

Update the column

EPAY_TRA_STATE inEPAY_TRA_TBL table to

“Transaction Completed”

Return Transaction Response and log

a message “Response received for therequest and returning to the client”

Yes

No





4.5.3 Methods

getCardNumber()

This method is used to find the original request identifier i.e., GUID, ST or CC and retrieve Secure CC and ST

information.

Step 1: Check Original request is Not NULL, then trim and find the length of request.

Step 2: If length is greater than zero than

1) If length = 36 then the original request id GUID, Pass the GUID in getCCForGUID(). In turn

returns secure Payment card and short token.

2) If length = 16 and first two characters are alpha then the original request id Short Token, Pass the

ST in getCCForShortToken(). In turn returns secure Payment card and short token.

3) Else it is a Payment card, then pass the number in getCCForCC(). In turn returns secure Payment

card and short token.

Step 3) Validate the Payment card using Token Transformer validateCardLengthForType(). It return Boolean. If

it is true then proceed else throw exception “Invalid_Card_Number_Message"

Step 3: Return secure data

getCCForCC()

Step 1: Validate the Payment card using Token Transformer validateCardLengthForType(). It return Boolean. If

it is true then proceed else throw exception “Invalid_Card_Number_Message"

Step 2: Get the short token for the Payment card using Token Transformer getShortTokenForCC(). It return

short token in this format “first2Charof CC(Card \type)+last4Digits of CC+ rest with “XXXXXXXXXX”

Step 3: set the CC and short token in the secure data

getCCForGUID()

Step 1: Send request to LN Middleware with GUID and in which response to secure data(Payment Card

Information).

Step 2: Check for secure data is not NULL then message “Card Number retrieved from LN Middleware with

retrieved Card Number” and set the ELS TOKEN in the secure data else throw LNMWExceptionStep 3: Get the CC and Encrypt ID from Secure Data

Step 4: Check for Encrypt Id is not NULL, If validate successfully then transform the encrypt Id to ELS token

using Token Transformer and set the ELS TOKEN in the secure data.

Step 5: Return secure data.

getCCForShortToken():Method to retrieve Card Number for given ELS Token

Step 1: Transform the ELS token to encrypt Id using Token Transformer

Step 2: Check for encrypt Id is not NULL and length > 0, If validate successfully then proceed else raise

exception with error message “EncryptDataId_Unknown_Message”

Step 3: Send request to LN Middleware with valid encrypt id and in which response to secure data(Payment

Card Information).

Step 4: Check for secure data is not NULL then message “Card Number retrieved from LN Middleware with

retrieved Card Number” and set the ELS TOKEN in the secure data else throw LNMWExceptionStep 5: Return secure data.


processTransaction () Performs card payment authorization with Global Collect.

getCardNumber() Method to retrieve card number for the given LN Middleware GUID or

ELSShortToken or Card Number

getCCForCC() Method to retrieve Card Number for given Card Number

getCCForGUID() Method to retrieve Card Number for given LN Middleware GUID

getCCForShortToken() Method to retrieve Card Number for given ELS Token





4.6 ePayment Card Tokeniser

This is web application that enables user to generate ELS Short Token for a given Payment Card

Number. This application has 2 operation modes

If the system is in production mode (Mode = PROD), the screen is shown as below, users can enter CC and get

returned ST.

4.6.1.1 Technical Flow:

• This application calls the CardTokeniser class.

• Log the host details and raise exception if does not find.

• Loads the config.properties and transform.properties property files if it is not loaded already.

o Config.properties : This property file contains

Error message name and text Lexis Nexis LN Middleware webservice details.

o transform.properties: This property file contains

Mapping of card number is maintained with card prefix, card type and card length.

Min and Max values, these values used in CC validation and ST transformation.

• If action is equal to getToken,

o Derive the Short Token for the given Payment card number

Validate the Card Number

• Find the card type using first two-six characters

• Raise error if it is not valid card type

• Validate the request data length with card type range

• No match found then validate the request data length with default range

• No match found then raise error.• Validate the request data using Luhn Algorithm.

• Raise error message if fails.

Pass the CC information to LN Middleware and get the response.

Raise error message if response is null.

• Derive the ST using CC and GUID (TokenTransformer. getShortToken).

o Derive the card type using CC number.

o Raise error if card type is not derived.

o Get the last four digit of CC (last4Digits)

o Add card variant to encrypt id excluding first 6 digits

o Derive the check digit for variant + encrypt id excluding first 6

digits using Lunh algorithm.

o Convert derived number (variant + encrypt id excluding first 6digits + check digit) to 32 base number

o Return the ST, card type +last 4 digits of CC + 32 base number





4.6.1.2 Technical Flowchart

Card type

Validation

Validate the CC


Default Length

Validation


Lunh Alogerithm

Di s pl a y E r r or

Pass the C

Middlw

Encrypt ID

Derive the Card Type using

transform properties

Derive ST using Encrypt ID

D

i s pl a y E r r or

Fail

Get the last 4 digits

CC Variant + Encrypt ID(Excluding first 6 digits)

Derive the Check Digit using Lunh

Algorithm

Convert to 32 Base Number

variant + encrypt id excluding first 6 d igits + check d igit

Return the ST

type +last 4 digits o f CC + 32 base number

Start

Get the CC

Display Short Token





4.6.2 Test Card Tokenizer:

Mode = TEST,.This web application are used to get the predefined card details in two form 1) specific to system

or 2) for all system, where system like ARGI, COPS, DELTA and PEOPLESOFT. Users can get ST only for

predefined cards, this list is held in file TestCardsForSystems.xml (this mode only available in test/acceptance)

4.6.2.1 Technical Flow:

TestCardTokeniser ()

Step 1: Get the Payment card number as IN parameter

Step 2: Get the local machine IP address

Step 3: Load the properties files

Step 4: if action of button id processCardEntry

Step 5: call getShortToken() method to get the short tokens

Step 6: If action from button displayCardList

Step 7: call getCardDisplayList()

getCardDisplayList()

If system is not null then call getTestCardsForSystem() else call geTestCardsForAllSystems() to display the list

of Paymentcard number and types from TestCardForSystems.xml

getTestCardsForSystem()

Get the list of card details from TestCardForSystems.xml for a specific system like ARGI, COPS, DELTA and

PEOPLESOFT

Specific to system: Delta





getTestCardsForAllSystems():

Get the list of card details from TestCardForSystems.xml for all systems.

Specific to All System

getShortToken():Method to retrieve ELS token for the given card number

step 1: Get Payment Card as IN parameter

step 2: If Payment card length is zero or IS NULL then error with “Invalid Card Number”step 3: Validate the card with Luhn algorithum. If return false then error with “Invalid Card Number”

step 4: If true then pass the Payment card to LN middleware to get the encrypt ID

step 5: Call the token transformer method TokenTransformer.getShortToken to transform the encrypt ID to

short token(ST)

step 6: return ST





4.7 Batch Payment Processor

This is a scheduled job run once every 4 hours. It performs the payment card requests to payment service from

the drop zone.

Get the Sender information, Drop Zone details, Mail configuration details, server configuration details

and error message, error code and exception for the batch processor are maintained in config.properties.

Read all the files from the Drop Zone request path and process one by one file for the payment process.

If there is an exception, then detailed mail will be sent. The mail id and mail format details are available

in config.properties.

In turn response will be send to the Drop Zone response path.

The configuration details are maintained in config.properties. The details are

1) Sender Details

2) Drop Zone Details

3) Mail Configuration settings

4) Date Format

5) Server configuration details

6) Mail Settings

7) Error code and message for batch processor

8) Exception for batch processor and

9) Condition check constant

4.7.1.1 Technical Flowchart





Batch Processor

Check for Filename

already e xists

eMail the detailed error message

Yes

Load the configurationfile from

config.properites

Get the Mail info, Drop

Zone path details.

Read all the file from

the Drop Zone Requestpath and process one

by one

Rename the file and

eMail the detailed error message

No

Parsing Exception

Parse this file to read

all the request and Getthe request and requestid

in the form of array

Sender Information are inserted into

the XMLprocessRequest.sendDataToEp aym

ent()

success

Payment Service

Rename the

processed file andmove to the processed

directory path

Exception are co

with list of exce

config file and e

detailed error m

Payment serviceException

success

In turn response will besend to the Drop Zone

response path

4.7.1.2 Methods

Method Name DescriptionGetDropZoneDetails () Get the drop zone path like request path, response path, request file

extension and response file extension

processRequest.sendDataToEpayment(

)

Sender information are inserted into XML and set the server IP and

port details.





4.8 Release Process

ePay team does two types of releases,

Informal Release: The code will be deployed by the developer in development instance and informal email will

be send to ePay team and update the same in Mantis as shown below. ePay team will test and approve the same.

Formal Release: Once ePay AM(Currently Fiona) verifies changes in the development environment and asks

development to processed with formal release. All approval communications happens through eMails and Mantis

updates.

Points to Remember:

CVS is the source repository for ePay source code.

Few configurations setups are different for Acceptance and Production releases. Hence formal release

version sequence is different for Acceptance and Production environment.

Verification Process

o Development Environment – Informal Release

o Acceptance Environment – Once changes are verified and approved in the Development

environment then changes will be deployed in the acceptance environment.

o Production Environment -- Once changes are verified and approved in the Acceptance

environment then changes will be deployed in the Production environment.

4.8.1 Source Code check-in and release

Verify the code modification against previous version.

o CVS Synchronize lists the modified files along changes.

o Right click the file in IBM RAD Team Synchronize withRepository

Once verification check in the modification in CVS.

o CVS Commit, checks in the file in source repository.

o Enter mantis issues description while check in the code in the CVS.

Update the Version in the main source file and re check in the source code.

Tag the modified package with next version.

o As mentioned above version labelling is different for acceptance and production for

each component.

Components Dependency of folder combination

ELSToken ELSToken & ePayPCIEAR

ePayPCI ePayPCI & ePayPCIEAR WebToken webToken & ePayPCIEAR

Generate EAR file and copy the new EAR file in the ePay release folder

o Generate and Export modified EAR into ePay release folder.

o Development team informs the appropriate persons/team once EAR file copied in the

release folder.

For acceptance TS (currently Tony Moss) does the EAR file deployment

For production RFC will be sent to change management team.

o Update the Mantis appropriately.

o Network folder location:

\\elsoxfdatp29va\ePayment\ePay_Software_Library\release


http://smb//elsoxfdatp29va/ePayment/ePay_Software_Library/release

http://smb//elsoxfdatp29va/ePayment/ePay_Software_Library/release




4.8.2 Configuration changes for Production deployment.

HTTP SSL Configuration

o Modify the web.xml file to change the LN Middleware SSL certificates.

o web.xml -> WS Binding Tab -> Port Qualified Name Binding Details head

elsoxfappp016Node02/LNMWClientRepertoire elsoxfappp017Node02/LNMWClientRepertoire

elsoxfappp018Node02/LNMWClientRepertoire

elsoxfappp019Node02/LNMWClientRepertoire

LN Middleware URL

o Update the mwServiceURL in config.properties file


Port Number

o Update the ePayment server details as follows,

EPaymentServer=localhost:9081/ePay

ServerNameForXSL=localhost:9081

Change Global Collect configuration

o

Update these details in config. Properties Global_Collect_Merchant_IP=145.36.232.1

GCML_URL=https://ps.gcsip.com/wdl/wdl

6. Ticket Resolution Process and Reporting

Secondary Support Task

1) Setup new OACS system in ePayment to process Visa card 2993

Steps to Create new Ordering System in MS Access:

1) Create New Ordering System Click (Add/ Modify Ordering System)

2) Create New Sender information and mapped to ordering system id Click

(Add/Modify Senders)







3) Create New Sender Transaction ID and mapped to sender information, card

payment type and payment processor. Click (Add/Modify Sender’s

Transactions)

4) Create New Entitlement ID and mapped to merchant id, Transaction type

and sender information Click (Add/Modify Global Collect Entitlements)







5) Use ST for transaction on Dev

Payment service Dev URL: http://elsoxfappd006:9081/ePay/services/PaymentService in Jmeter

Request:

TestSTRequest.txt

Response:

TestSTResponse.tx

6) Setup ELSToken Config to provide GUID from ST

Remote connect to elsoxfappd006

Go the below path:

D:\WebSphere\AppServer\profiles\ePay\installedApps\elsoxfappd006Node02Cell\ePayPCIEAR.ear\ELSToken.war\config\xml

PFA the updated sender entitlements file which return GUID or ST for any input tokens

<sender>

<senderAutCode>pOu0439</senderAutCode>

<senderName>OACS_TEST</senderName>

<systemId>OACS_ST</systemId>

<returnVal>ST</returnVal>

</sender>

<sender>

<senderAutCode>pOu0439</senderAutCode>

<senderName>OACS_TEST</senderName>

<systemId>OACS_GUID</systemId>

<returnVal>GUID</returnVal></sender>

Sender_Entitlement.txt

Once updated in the server, we need to refresh the cache:

Remove Cache Dev URL: http://elsoxfappd006:9081/eToken/services/ConfigManagement in Jmeter

Request:

Remove Cache froServer Request.txt

Response:

Remove Cache froServer Response.tx

Use ELSToken service to get GUID from ST.

ELSToken service Dev URL: http://elsoxfappd006:9081/eToken/services/ELSTokenService in Jmeter

Request:




http://elsoxfappd006:9081/eToken/services/ConfigManagement

http://elsoxfappd006:9081/eToken/services/ELSTokenService









TestELSSTRequest.xt

Response:

TestELSSTResponsGUID.txt

7) Use GUID for transaction on Dev:

Payment service Dev URL: http://elsoxfappd006:9081/ePay/services/PaymentService in Jmeter

Request:

TestGUIDRequest.tt

Response:

TestGUIDResponse.xt

8) Show transaction details on log file:

Remote connect to elsoxfappd006

Go the below path:

D:\epaylogs

We can able to see the entire transaction log message in the epay.log file in the above directory.

9) Add new test CC to test cards

Remote connect to elsoxfappd006 Go the below path:

D:\WebSphere\AppServer\profiles\ePay\installedApps\elsoxfappd006Node02Cell\ePayPCIEAR.ear\WebToken.

war\config\xml

Insert the new card details in the TestCardsForSystems.xml file in the above directory.

TestCardsForSystes.txt

Once updated in the server, we need to refresh the cache:

Remove Cache Dev URL: http://elsoxfappd006:9081/eToken/services/ConfigManagement in Jmeter

Request:

Remove Cache froServer Request.txt

Response:










Remove Cache froServer Response.tx

7. Configuration Management Procedure/ToolTo be updated

7.1 Database Administration Procedure (Backups & Recovery)

Daily database backups





7.2 Job Scheduling/Sequencing of Batch Jobs

Schedule Task:





Steps to create a New Batch Processor for fulfilment system:

Step 1: Copy the existing batch directory to new batch_processor_ESME_Test.

Step 2: Changed the config.properties file (Sender Details,Drop Zone and BP_SUBJECT)

Step 3: Changed the log4j.properties (File Path)

Step 4: Created a new schedule task for every 4 hours(ePaybatchProcessor_ESME_Test)


Task Transfer log file from production servers(16,17,18 & 19) to test( Elsoxfappt005)server

Server Elsoxfappt005(Windows)

Batch File Name D:\robocopy\copy_epay_logs.bat

Frequency




7.3 Application Stability

ODBC Connection to access MS Access:

1. Click Start, and then click Control Panel.

2. In the Control Panel, double-click Administrative Tools.

3. In the Administrative Tools dialog box, double-click Data Sources (ODBC).

The ODBC Data Source Administrator dialog box appears.4. Click User DSN, System DSN, or File DSN, depending on the type of data source you want to add. For

more information, see the section About ODBC data sources.

5. Click Add.

6. Select the driver that you want to use, and then click Finish or Next.

If the driver you want is not listed, contact the administrator of the database you are

connecting to for information about how to obtain the correct driver.

7. Follow the instructions and enter the required connection information in any dialog boxes that follow.


http://ms-help//MS.MSACCESS.12.1033/MSACCESS/content/HA10275550.htm#1






8 Error and Log Handling

9.0 Issues & Suggestions (for enhancements)

The following are the existing issues/suggestions that can be considered for this application

9.1 Issues

• <Issues>

• <Identify the Business Processes/Activities which are redundant or bottlenecks to users. Activties which

take longer time or they are very costly to the user.>

9.2 Suggestions

• <suggestions>

• <Suggest how to automate some manual activities to reduce time. Suggest alternatives to reduce the cost of doing a particular activity >

10. Application Support and Maintenance

10.1 Common Problems

10.1.1 ePayment Server Report Generation

There is a java program named ReprotFileGenerator in the following location of the acceptance

environment (elsoxfappt004).

D:\epaymentreport com\elsevier\ePayment\report\

This java program is scheduled to run (by a batch file named Report.bat) every day morning at 8.00

and it collects log of all the transactions coming into the system capturing details and timings

henceforth. The details are stored in a spreadsheet in the following location.

\\Elsoxfs30316\car_upl\EPS_reports\Test\ePayReport.csv

10.2 Critical Problems

11. Glossary of Business Terms

<Glossary>

1. Abbreviations

<Abbreviations>

2. References

3. Contact Information


http://elsoxfs30316/car_upl/EPS_reports/Test/ePayReport.csv

http://elsoxfs30316/car_upl/EPS_reports/Test/ePayReport.csv




E.g.: Given below is the list of contact persons in XYZ application at the time of application knowledge of GOBI application.

Name of

Person

Business /

System/support

Consulting /

Department

Primary/Secondary Phone Pager Mail Id

4. Application Artefacts (Inventory)

<<to be customized based for the application>>

Document Inventory

# Name Description Rev # Rev Date Softcopy

Hardcopy

Source Inventory

Application Files

Sr.No. File names Type (Java,..) Module Name1

2

3

4

Other Files

Sr.No. File names Type (Java,..) Module Name1

2

3

4

5

License & Tools Inventory

<List licenses & tools that come along with this application>

# License for License Expiry License Transferable?

# Tools/Software

(include version#)

Purpose Comments (E.g. transferable?)





Configuration and Environment Setting

<E.g. how is CLASSPATH setup, how the database connectivity – e.g via JDBC>

Miscellaneous Information

<E.g. information about NetDynamics>

5. Setting up the Development Environment

Offshore

< Mention special steps / tips for setting up the development environment offshore.

Eg: Special environment variables not mentioned in Installation Guide >

6. Escalation and Notification process

< Mention the escalation and notification process followed for the application >

7. Procedure to request access to application

< Mention the process to obtain the required access to the app. based on the role of the support professional >

---- EOF ---

Documents

Wave2 Finance NonEBS ePay AID V1.4