Copyright © ICICI Bank Limited. All rights reserved.

1

Copyright © ICICI Bank Limited. All rights reserved.

Merchant Integration Guide Version: 2.0

Release Date: March 29, 2006

2


Copyright Information

Copyright © ICICI Bank Ltd. All rights reserved. No part of this document may be

reproduced, stored in retrieval form, adopted or transmitted in any form or by

any means, electronic, mechanical, photographic, graphic, optic or otherwise,

translated in any language or computer language, without prior written permission

from ICICI Bank Ltd.

Disclaimer

This document has been prepared in accordance with the accepted techniques for

solution specifications definition at ICICI Bank Ltd. The information represented

herein, has been gathered after studying market trends and inputs supplied by

expert consultants. The representations and related information contained in the

document reflect ICICI Bank’s best understanding of the business. However, ICICI

Bank makes no representation or warranties with respect to the contents hereof and

shall not be responsible for any loss or damage caused to the user by the direct or

indirect use of this document and the accompanying software package.

Further, ICICI Bank reserves the right to alter, modify or otherwise change in any

manner the content hereof, without the obligation to notify any person of such

revision or changes.

3


About Payseal

Payseal is brought to you by ICICI Bank Ltd. Payseal provides secure electronic

commerce payment solutions in the B2C & B2B environments.

About ICICI

ICICI Bank is India's second-largest bank with total assets of about Rs. 1 trillion and

a network of about 540 branches and offices and over 1,000 ATMs. ICICI Bank

offers a wide range of banking products and financial services to corporate and retail

customers through a variety of delivery channels and through its specialised

subsidiaries and affiliates in the areas of investment banking, life and non-life

insurance, venture capital, asset management and information technology. ICICI

Bank's equity shares are listed in India on stock exchanges at Chennai, Delhi,

Kolkata and Vadodara, the Stock Exchange, Mumbai and the National Stock

Exchange of India Limited and its American Depositary Receipts (ADRs) are listed

on the New York Stock Exchange (NYSE).

ICICI Bank was originally promoted in 1994 by ICICI Limited, an Indian financial

institution, and was its wholly-owned subsidiary. ICICI's shareholding in ICICI Bank

was reduced to 46% through a public offering of shares in India in fiscal 1998, an

equity offering in the form of ADRs listed on the NYSE in fiscal 2000, ICICI Bank's

acquisition of Bank of Madura Limited in an all-stock amalgamation in fiscal 2001,

and secondary market sales by ICICI to institutional investors in fiscal 2001 and

fiscal 2002. ICICI was formed in 1955 at the initiative of the World Bank, the

Government of India and representatives of Indian industry. The principal objective

was to create a development financial institution for providing medium-term and

long-term project financing to Indian businesses. In the 1990s, ICICI transformed its

business from a development financial institution offering only project finance to a

4


diversified financial services group offering a wide variety of products and services,

both directly and through a number of subsidiaries and affiliates like ICICI Bank. In

1999, ICICI become the first Indian company and the first bank or financial institution

from non-Japan Asia to be listed on the NYSE.

After consideration of various corporate structuring alternatives in the context of the

emerging competitive scenario in the Indian banking industry, and the move towards

universal banking, the managements of ICICI and ICICI Bank formed the view that

the merger of ICICI with ICICI Bank would be the optimal strategic alternative for

both entities, and would create the optimal legal structure for the ICICI group's

universal banking strategy. The merger would enhance value for ICICI shareholders

through the merged entity's access to low-cost deposits, greater opportunities for

earning fee-based income and the ability to participate in the payments system and

provide transaction-banking services. The merger would enhance value for ICICI

Bank shareholders through a large capital base and scale of operations, seamless

access to ICICI's strong corporate relationships built up over five decades, entry into

new business segments, higher market share in various business segments,

particularly fee-based services, and access to the vast talent pool of ICICI and its

subsidiaries. In October 2001, the Boards of Directors of ICICI and ICICI Bank

approved the merger of ICICI and two of its wholly-owned retail finance subsidiaries,

ICICI Personal Financial Services Limited and ICICI Capital Services Limited, with

ICICI Bank. The merger was approved by shareholders of ICICI and ICICI Bank in

January 2002, by the High Court of Gujarat at Ahmedabad in March 2002, and by

the High Court of Judicature at Mumbai and the Reserve Bank of India in April 2002.

Consequent to the merger, the ICICI group's financing and banking operations, both

wholesale and retail, have been integrated in a single entity.

5


Technical Contact

Email [email protected]

Tel 91-22-56673140

6


Index Preface................................................................................................................... 8

What’s in This? ................................................................................................... 8

Audience............................................................................................................. 8

Information Not Available.................................................................................... 8

Navigating This Book.......................................................................................... 9

Printing this Book.............................................................................................. 10

Introduction .......................................................................................................... 11

What is Payseal? .............................................................................................. 11

How does Payseal work? ................................................................................. 12

Advantages....................................................................................................... 13

Merchant Classification ........................................................................................ 17

MOTO Merchants ............................................................................................. 17

SSL Merchant ................................................................................................... 20

The Merchant Web Interface................................................................................ 22

Integrating with Payseal ....................................................................................... 46

The Store Front Adaptor (SFA)......................................................................... 46

General Requirements...................................................................................... 47

Merchant Key.................................................................................................... 47

SFA Library....................................................................................................... 48

Java Installation ................................................................................................ 50

ASP Installation (Windows 2000 and NT)......................................................... 54

ASP Installation (Windows 2003)...................................................................... 56

PERL Installation .............................................................................................. 57

PHP Installation ................................................................................................ 60

Sample Codes .................................................................................................. 64

Method Summary ............................................................................................. 65

Trouble shooting................................................................................................... 76

7


1

Preface

What’s in This?

This book is intended for merchants who want to integrate their e- commerce

applications with the Payseal Payment Gateway. This document provides

information about the merchant administration features in the MWI (Merchant

Web Interface) of Payseal Payment Gateway. The document also details the

process of integrating the merchant application with the Payseal Payment Gateway

Audience

This book is primarily intended for the administrators of the merchants. The

merchant site integrators, who will integrate the merchant application with the

Payment Gateway, can also use this document

Information Not Available

ICICI has made every effort to include all relevant information in this book. However,

it is possible that some specific information you are looking for is not available. If

you would like this information to be included in a subsequent version of this book,

do contact the support personnel.

8


Navigating This Book

This book is organized as follows

• Introducing Electra Payment Gateway

Provides basic information on the Payseal Payment Gateway,

the features it offers to merchants and the technology and

security mechanisms it provides

• Merchant Classification

Provides the technical differences between MOTO Merchants and SSL

Merchants

• Merchant Integration

Provides the integration process to facilitate the integration

of the merchant application with the Payseal Payment Gateway

• Merchant Web Interface

Provides details of the Web based administration interface

for administration of the Payseal Payment Gateway system.

• Troubleshooting

Provides information on how to troubleshoot frequently encountered

problems

9


Printing this Book

This book is designed in a printer-friendly book format. To print this document:

1. Use File > Page Setup to set general printing options. The available

options will vary with different printers and drivers. See your printer driver

documentation for details.

2. Click the Print button or choose File >> Print. Select appropriate options.

For information on printing PDF documents, refer Acrobat Reader

Help.

3. Select one of the following:

- OK to print the document.

- Cancel to exit the Print window without printing the document.

10


2 Introduction

This chapter provides basic information on the Payseal Payment Gateway, the

features it offers to merchants and the technology and security

mechanisms it provides.

What is Payseal?

Payseal is a payment gateway. It allows you to make secure online credit card

payments. It ensures that when you shop on the Internet

Payment gateway is an intelligent router that receives Internet payment messages

and directs them to the applications responsible for carrying through financial

transactions. The gateway.

• Authenticates the parties involved in the online transaction

• Routes messages securely between the parties for authorization and

settlement of the transaction.

• Ensures integrity and privacy of all messages.

• Provides administration support to the parties involved.

11


How does Payseal work?

In a typical retail purchase on the Internet, Payseal would work as follows:

The customer fills his shopping cart on a merchant website and proceeds to check

out.

The transaction information is transmitted to the merchant server.

The web merchant forwards a digital order to the Payseal server in an encrypted

format.

Payseal authenticates the merchant & provides payment options and payment

details screens directly on the customer's browser over a secure 128-bit SSL+

connection.

The customer provides his credit card details, which is directly sent to the Payseal

server when he clicks "Pay"

The credit card details are then switched to ICICI Bank for authentication. ICICI

Bank then transmits the message to the cardholders' bank for payment

authorization. The issuing bank authorizes the payment, provided the card is valid

and has the requisite credit limit, and transmits the confirmation back to the payment

gateway through ICICI Bank.

On receiving the authorization, Payseal forwards a digital receipt to the merchant

server.

12


The merchant provides a confirmation of the payment to the customer's browser.

The entire process integrates seamlessly with the shop and buys application of the

web merchant. The merchant may then ship the goods and capture the transaction

on the gateway server.

Advantages

With Payseal, businesses are assured of ...

· Easy installation, operation and management

· Single platform for all payment options

· Adaptability to multiple platforms

· Optimum server utilisation at your site

· Fast, easy integration

· Centralised and secure data management

· Verisign certification

· Automatic upgrades and scalability

· Swift Transaction processing

Easy installation, operation and management

Payseal eliminates the need for complex software, large databases, and heavy-duty

processing on the merchant site. Instead, all payment operations are handled by

Payseal's own 24x7 secure Payment Servers. As a result, software installation,

integration and management is no longer a major hurdle for merchants and their site

developers

13


Single platform for all payment options

Payseal's unified architecture can support the Internet's widest range of secure

payment options.

Adaptability to multiple platforms

The Payment Client software is available for Microsoft® Windows NT™ and leading

versions of Unix.

Optimum server utilization on your site

The Payment Client software connects the merchant's storefront to Payseal's

services. It is the only software component that needs to reside on the merchant's

site server, as Payseal physically hosts the rest of the software at its own sites. This

leaves the merchants' server resources free for other tasks, at the same time allows

them to accept multiple modes of payment from your net customers.

Fast, easy integration

The Payment Client offers developers and integrators of shop-and-buy applications

a number of programming language interfaces, minimizing the coding effort required.

The Payment Client can be quickly and easily customized to facilitate integration

with all major merchant storefront platforms.

14


Centralized and secure data management

To protect the integrity of merchant transactions, Payseal supports the Internet's

strongest security technologies. The client software encrypts transaction information

using 280 bit RSA before passing it through an SSL pipe using 128-bit encryption.

Verisign certification

The gateway server is assigned a server ID and authenticated by "Verisign", one of

the leading certifying authorities for websites. For more information, check here.

Automatic upgrades and scalability

Businesses can automatically take advantage of new payment technologies,

standards and services as they emerge, without undergoing costly and time-

consuming software changes to merchant site. Businesses retain the same

interface, yet are able to stay abreast of the latest technologies and offer customers

the widest range of options.

Swift Transaction processing.

Payseal delivers a real time, highly scalable and reliable Internet payment platform

that processes transactions within 20seconds.

15


https://digitalid.verisign.com/cgi-bin/Xquery.exe?Template=authCertByIssuer&form_file=../fdf/authCertByIssuer.fdf&issuerSerial=b67af0d2f90f6c0de61aae1fa731e663

Features

Payseal provides a set of unique features, which ensure fast and easy integration to

your systems and also maintenance of your records.

· Merchant Administration Module

Merchant Administration Module Payseal offers a unique and extensive client

interface platform in the merchant administration module. The interface is provided

via a dedicated access to the Payseal server, in which organizations can view

comprehensive records of all transactions conducted through Payseal.

The module facilitates extensive MIS reporting and monitoring of financial

transactions.

Each merchant is allowed to reconcile, review individual transactions, and assign

different levels of authority for refunds, voids, and captures.

The interface also provides additional functionalities including capture, partial

capture, refund and partial refund of authorized transactions.

· Integration Expertise

Payseal's unique payment client software has been integrated across most leading

Internet platforms across a variety of environments.

Hence we would be able to achieve swift and complete integration of the gateway at

your end.

16


3 Merchant Classification

Based on certain classifications of the merchant the processing of online payment

transactions would differ. This chapter highlights these changes. The administrative

users must understand these classifications and the processing required before

proceeding to using the system

ICICI Bank would classify certain merchants as MOTO merchants. These

merchants would have the capability to reliably accept credit card transactions

from their customer and forward the same to the payment gateway for further

processing.

Merchant who do not accept the credit card details are classified as SSL merchants. These merchants would redirect their customers to the payment

gateway pages to reliably accept card details.

MOTO Merchants

MOTO merchants have the capability to reliably accept credit card transactions

from their customer and forward the same to the payment gateway for further

processing.

The initial portion of processing remains the same for both MOTO and SSL

Merchants. In both the case, Customers of the merchant visit their site for the online

purchase

17


After filling the shopping cart information the customer chooses the pay for his/her

purchase. At this stage the processing would differ for the two merchant

classifications.

In the case of a MOTO merchant, the merchant website confirms the transactions

and posts a page where the customer can enter the card details.

Customer enter the card details and on submitting it, the merchant receives the

request, might perform certain validation on the data entered and sends the request

to the Payment Gateway in the format provided in the Appendix of this document. To

help the integration effort, Payseal uses HTTPS as the protocol for sending the

request. Merchant developers would have to use the SFA (detailed later) to send the

transaction to the Payment Gateway. When Payseal receives the request it

validates the merchant using few cases. Once this authentication has been

completed, the transaction is accepted for further business level validations and

processing. After processing the payment request, the response on the

success or failure of the transaction is sent back to the merchant who can

display appropriate message to their customers.

The Payment Gateway also provides a Public Key infrastructure for authentication of

the merchant. A public key and a private key pair are generated for each merchant.

Data is encrypted at the SFA using the public key and decrypted at the Gateway

using the private key.

18


The following diagram shows the flow of the request and the processing done by the

merchant and Payseal

I am a MOTO Merchant so

I take the card details

Net User k

I know this merchant, so I don’t

mind giving him my Card Details

Merchant Payseal

Payment

Gateway

I am PG, I know this is a

MOTO merchant

Copyright © ICICI Bank Limited

Net Users Ban

1

2

3
4
5

6

19

. All rights reserved.

SSL Merchant

Merchant who do not accept the credit card details are classified as SSL merchants.

These merchants would redirect their customers to the payment gateway pages to

reliably accept card details.

As the in the case of SSL Merchant, the transaction is asynchronous, more

validation of the request is required. Hence, redirecting the customer to the Payment

Gateway, the merchant sends an online request to the payment gateway, in the

message format provided in the appendix using HTTPS. Payment Gateway

validates the merchant and returns back a set of encrypted data. Validation is also

achieved by means of the Public Key Infrastructure implemented by the Payment

Gateway.

The SFA receives the transaction details (excluding the card details) from the

merchant and sends it to the Payment Gateway. In return the SFA returns to the

Merchant component a URL to which the request must be redirected. The Merchant

redirects the customer to the URL received from the SFA.

The payment gateway shows the page where the customer can enter the card data.

The request is processed at the Payment Gateway and the success or failure

response is sent back to the Merchant on the response URL specified by the

Merchant. The customer would then be re-directed back to the merchant web site.

20


The following diagram shows the flow of the request and the processing done by the

merchant and Payseal

I am a SSL Merchant, so I will have to

ask the bank to take the card details

Net User

Merchant

k

Payseal

Payment

Gateway

I am PG, I know this is a SSL

merchant. I will provide page where

user can enter card details

I prefer giving my card details to

the bank

Copyright © ICICI Bank Limited. All

Net Users Ban

1

2

3

4
5 6
7

8

21

rights reserved.

4

The Merchant Web Interface

Login Screen

- This screen is used for logging into the System

- Enter the login Id and Password and click on the button to login to the system

When you log on to MWI Module for the first time you need to change you password.

Once you change you password you will be able to see the link to other functions

available in MWI Module.

22


Transactions

Basic Search

To locate the transactions in the system select Basic Search sub menu under the

Transactions module Select the Format type as view to view the result in a tabular

form.

Select the format type as CSV to obtain comma-separated format

Enter the transaction reference number if you want to locate a specific transaction

This is the transaction number generated by the merchant’s system to identify a

transaction Select the transaction status Select the date range Select the card type.

Click on Search The list of transactions satisfying the criteria are displayed

Click on the reference number to view the complete details of that specific

transaction

23


There is link in the transaction details page to see the history of the transaction-click

on the previous transaction reference number for viewing the previous stage of the

transaction.

The transaction details page allows the Merchant to initiate a related transaction on

the transaction being displayed. For example, if the transaction search yields a “Pre-

Authorization” that is successful, then the “Authorization” option is displayed.

Clicking on the “Authorization ” button generates the Authorization transaction.

Similarly, a Search, which displays a successful “Sale” transaction, will display the

Void Sale and the Refund links.

24


Advanced Search

To further narrow down the search of transactions, the advanced search facility can

be used

For this select Advanced Search sub menu under the Transactions module

Select the Format type as view to view the result in a tabular form.

Select the format type as CSV to obtain comma separated format

Select the transaction status

Enter the transaction amount. You can locate transactions lesser than the amount

entered, equal to the amount entered or more than the amount entered. Select the

appropriate option

Select the date range.

25


Select the transaction type (Multiple Selection of Transactions type is available)

Select the card type. Multiple selections of card types is also allowed Click on

Search

Related transactions can be invoked on the Search results displayed.

(Note: Search Option with card number is available to MOTO Merchants)

Order Fulfillment This refers to the generation of Authorization (capture) of successful Pre-

Authorization transactions.

This screen allows the view of all the end-to-end successful preauthorization

transactions, for which authorization can be initiated. The

Merchant Administrator can initiate the Authorization transaction from this page.

To locate the pre-authorization transactions in the system select Order Fulfillment sub menu under the Transactions module

26


Click on Search The list of transactions satisfying the criteria are displayed


transaction

27


Multiple Authorizations can be initiated by checking the check boxes against the

displayed transactions. The Authorization transaction that is generated will have the

amount same as the Pre-Authorization transaction. If the amount of Authorization is

to be different than the Pre-Authorization, then the amount has to be entered on the

Transaction details page before firing the transaction.

28


Refunds

Refund is the generation of a refund transaction on successful Sale/Authorization transaction.

This screen allows the view of all the end-to-end successful sale transactions, for

which void has not been initiated earlier or for which refund has not been initiated

and for which refund can be initiated.

To locate the refund transactions in the system select Refunds submenu under the

Transactions module

Select the date range

Select the card type. Multiple selections of card types is also allowed

Click on Search

29


The list of transactions satisfying the criteria are displayed


transaction

There is link in the transaction details page to see the history of the transaction-click

on the previous transaction reference number for viewing the previous stage of the

transaction

Multiple Refunds can be initiated by checking the check boxes against the displayed

transactions. The Refund transaction/s that is/are generated will have the amount

same as the original transaction.

If the amount of Refund is to be different than the original transaction, then the

amount has to be entered on the Transaction details page before firing the

transaction.

30


Batch Upload files This facility can be used to upload the card stop-list file

Browse from your local machine the file to be uploaded and select the type of file

such as bin stop list

Click on Upload File to upload the file to the server. When successfully uploaded

the message is displayed. Note: All fields are “|” delimited. FIELD NAME

DATA TYPE

LEN

FIELD DESCRIPTION

MANDATORY

ACTION CODE

Char 1 A – ‘A’dd to Stop-List W – ‘W’ithdraw from Stop-List

Y

CARD NUMBER (Moto)

Char 20

The exact Card Number which needs to be added into / removed from the stop-list.

Y

31


MERCHANT ID

Char 10

If the Merchant ID is present, only transactions originating from this merchant would get affected by this entry. If the Merchant ID is absent, all transactions done by the card would get affected.

N

STOP LIST REASON CODE

Char 2 List of codes are as under : L - Lost Card S - Stolen Card ND - Not Delivered C - Counterfeit Card E - Expired Card SV - Security Violation CO - Contentious AU - Abusive Usage AUC – Abusive,Usage,Capture R - Refer To Issuer MCI - Miscellaneous,Contact Issuer MR - Miscellaneous,Refuse MC - Miscellaneous,Capture

STOP LIST REMOVAL CODE

Char 2

List of codes are as under : F - Found Card C - Captured Card B - Bank Decision O - Overdue Card

Depending on the action to be performed, either the STOP LIST REASON CODE or STOP LIST REMOVAL CODE would be mandatory

Naming Convention “CS”+Delimiter+Merchant Id+Delimiter+DateTime stamp+Delimiter+file extension The delimiter is “.” Date Time stamp – ddmmyyyyhhmmsshh is 24 hour format Example: CS. M000000001.01012003010101.txt Or CS. EPG001.01012003010101.txt ( if the file uploaded is to apply to all merchants in the system.) Sample file Format: Action code| card number |merchant id |stop list reason code| stop list removal code ADD|4111111111111111|00001000|MR

32


Upload transaction batch files This facility can be used to upload the files required for the bulk processing of

transactions instead of manual processing Browse from your local machine the file

to be uploaded.

Click on Upload File to upload the file to the server. When file is successfully

uploaded the message is displayed

The System generates a Batch number, referred as the “Merchant Batch Number”

for the file. The Batch number can be used for searching transactions from the

Transaction Search Screens.

33


This file is used by the merchants for uploading Capture / Refund transactions. NOTE: All fields are “|” delimited.

FIELD NAME DATA TYPE

LEN FIELD DESCRIPTION MAND

ATORY

TRANSACTION

TYPE

Char

Each txn. type would

be

uniquely identified as

foll :

“Authorization”

“Refund”

Y

MERCHANT ID

Char

8 Merchant ID as defined

in

EPG

Y

MERCHANT

TRANSACTION

ID

Char

50 Transaction ID used by

the

merchant for linking

his/her

transactions. A

transaction

Id should be unique for

a

transaction Id for root

transactions in a day.

Root

transactions refer to

Sale

and Pre-Authorizations

Y

34


ROOT RRN Char

12 RRN of the original

Transaction

Y

ROOT AUTH

CODE

Char

6 Authorization Code of

the

Original transaction

Y

AMOUNT Num

10, 5 Transaction Amount –

Should be null for

VOIDs

-

CURRENCY Char

3 ‘INR’ - Should be null for

VOIDs

-

ROOT TXN

REFERENCE

NUMBER

Char

15 Txn. reference number

of

the original transaction

Y

Naming Convention “TU”+Delimiter+Merchant Id+Delimiter+DateTime stamp+Delimiter+file extension

The delimiter is “.”

Date Time stamp - ddmmyyyyhhmmss

hh is 24 hour format

Example: TU.M000000001.01012003010101.txt

Sample file formats

Txn Type | Merchant ID | Merchant Transaction ID | Root RRN No | Root Auth Code

| Amount | Currency | Root Txn Reference Number

Authorization|M0000003|1057934691970|000000000038|000038|350|INR|20030710

0000058

35


Txn Type | Merchant ID | Merchant Transaction ID | Root RRN No | Root Auth Code

| Amount |Currency | Root Txn Reference Number

Refund|M0000003|1057934748282|000000000040|000040|50|INR|2003071000000

60

Reports Merchant Snap shot This is a snapshot of all the transactions in the system. If the Merchant is a Super

Merchant he/she can select the sub-merchant for whom the snap shot is to be

generated.

The snapshot displays the following information Attempts – This is the total number

of transactions accepted by the System

Approved – These are the end-to-end successful transactions in the

system

Rejected by Processor – These are the transactions that are rejected by

the system

Rejected by Switch – These are the transactions that are rejected by the

switch

Transaction Cancelled - These are the transactions that are cancelled

The snapshot displays the number, value and percentage distribution of

the transactions.

To view the snapshot, select the merchant snapshot sub menu under

the Reports module

Select the Format type as view to view the logs in a tabular form.

Select the format type as CSV to obtain comma separated format Select the date

range

Click on View

36


The snapshot is displayed

There is a link on the grouping such as attempts, approved to view the list of all such

transactions.

From the transaction list there is a link for drilling down to the details of the specific

transaction.

37


Settlement Report Settlement Report is a summary report of Successful transaction done by a given MID. Select the Format type as view to view the logs in a tabular form.

Select the format type as CSV to obtain comma-separated format Select the date

range Click on View Select Currency for which you want to view the summary report. Report Type, will allow you to check the daily/weekly/monthly summary of transactions

This report provides you with the Count and Amount of Preauth, Auth , Sale and Refund for the duration mentioned.

38


Group management / User Management EPG system has users classified in different groups according to the role

they perform. There are different groups for the different roles

This screen allows searching for a group based on some criteria.

The administrator can search based on the status of the group such as

active/inactive and group type.

The groups are classified in the following group types

- Merchant user

- Merchant administrator

View Groups This Screen shows the groups for the specified criteria. The navigation for further

managing the group is also provided in this page

Add User – This creates and adds a user for the selected group 39


Modify – This modifies the properties of the group

Delete – This deletes the selected group

View Privileges – This displays the privileges assigned to the selected group.

Privileges are the right to access various modules of the system

Assign Privileges – This allows the administrator to modify the assigned privileges

and re-assign privileges to the selected group

View Users – This displays the users belonging to the selected group

Change Status – This toggles the status of the selected group between active and

inactive

Assign privileges screen This Screen enables the assigning or removal of privileges for the selected group

Every menu is a privilege. EPG has a role-based menu.

40


The administrator can select the privileges to be assigned to a Group

The left hand side list displays the privileges that can be assigned and the right

hand side list displays the privileges already assigned Select a privilege from the

assignable privileges Click on ‘>’ to assign or Click on ‘<’ to remove the privilege

Add User This Screen enables the administrator to add a user to the selected group

41


42


Add Group This screen enables the administrator to create a new group.

Enter Group Name

Select the group type

Enter the maximum login count. This is the maximum number of concurrent logins

for the user in the Group

Enter the Maximum login retries. This is the maximum number of times login can be

retried with invalid password

Click on Add to add the group

A message is displayed on successful addition of group

43


Stop List Query Stop-list This screen enables the administrator to query a card in the stop list

To query a card from the stop list select Query Stop list sub menu under the

Personalize module

The Search is based on a Card number

Click on Search

Add Card to Stop List This screen enables the merchant administrator to add a card to the stop list.

To add a card to stop list select Add Card(s) sub menu under the Personalize module

44


Withdraw card This screen enables the administrator to withdraw a card from the stop list

To withdraw a card from the stop list select Withdraw card sub menu under the

Personalize module Enter the card number. Select the withdrawal reason Click on

Withdraw

45


5 Integrating with Payseal

The Payment Gateway provides a set of Libraries (API) to the Merchant to facilitate

the process of integrating the Merchants application with the Payment Gateway.

This section provides details about the process of integration. It also provides code

snippets that will help the Merchant in using the libraries.

The Store Front Adaptor (SFA)

The Payseal Payment Gateway aims to provide a seamless procedure by which the

Merchant application can integrate with the Payment Gateway services in minimum

time.

The Store Front Adaptor is a set of Libraries that can be used by the Merchant for

the integration with the Payment Gateway.

The SFA is currently available in the following different technologies –

• JAVA

• ASP

• PERL

• PHP

The Merchant can choose the SFA that is best suited for the platform and the

technology on which his/her application is running.

46


General Requirements

Merchant should make sure that he meets the following requirements before starting

the integration with Payseal Payment Gateway

• The Merchant must possess the key file generated by the Payment Gateway.

For more information about key see section Merchant key.

• The Merchant should be able to install required dependencies on the server

where SFA will be installed. If the server is shared server then merchant can

contact his web-host for installing required dependencies.

• The Merchants server where SFA will be installed should allow HTTPS

connection to payseal.icicibank.com on port 443

Merchant Key

Technical support team assigns a unique Merchant Id for a merchants. Ex.

00001234. This Merchant Id needs to passed by merchant for every transaction.

Once a Merchant Id is created, Merchant is supplied following information.

• Merchant Id. ex. 00001001

• Type of Merchant. (SSL or MOTO)

• Password for “Super” user which can be used to login in Merchant Web Interface Module

(https://payseal.icicibank.com/mwipages/login.jsp)

For every merchant id, a pair of public and private key is generated. Data is

encrypted at the SFA using the public key and decrypted at the Gateway using the

private key. Merchant should download the public key from the MWI Module

47


https://payseal.icicibank.com/mwipages/login.jsp

(https://payseal.icicibank.com/mwipages/login.jsp). Procedure for downloading the

key is as follows: -

1. Login to MWI Module using the Super user.

2. Click on the link “SFA>> Key Download”.

3. Save the .key file in a secured location. (When a popup box appears, do

not click on cancel button).

4. This key file should have read privileges for the user by which application

server runs (Ex. In Linux, “nobody” in case of apache)

The key can be downloaded only once. Extreme care should be taken while

downloading the key. Merchant should take care that this key is kept is secured

location. If the key is corrupted of lost then Merchant has to send a request to

Technical Support team to regenerate key.

SFA Library

The data passed from the Merchant to the Payment Gateway via the SFA is logically

grouped into the following categories -

• Merchant Information

• Card Information (Only in case of MOTO Merchants)

• MPI Information

• Address Information, comprising of Shipping and Billing details

The SFA Library provides an Object mapping of the information items for ease of

use. The following is the mapping between the Information items and the actual SFA

Objects.

• Merchant Information - Merchant

• Card Information -CardInfo

• MPI Information - MPIData

• Shipping Address - ShipToAddress 48



• Billing Address – BillToAddress

• PGResponse – Maps to the response received from the Payment

Gateway

Apart from the above-mentioned Objects, the SFA Library is also packaged

with a component that accepts the various Information Objects from the Merchant

and then passes on the data to the Payment Gateway site.

The SFA Library is shipped as a ZIP file for all installations.

49


Java Installation

Merchants on Windows as well as on Linux/Unix platform can use SFA Java library.

Requirements: - • The Merchant's server where SFA will be installed should have SUN JDK1.3

installed.

• Merchant’s server should have an application server, which can host .jsp files.

Download required files: - • Login to MWI Module, Click on “SFA -> download SFA”, select java sfa and

download java.zip file.

• Extract java.zip so that following files will get extracted.

o jsse.jar:- Required to establish the SSL connection with PG

o jcert.jar - Required to establish the SSL connection with PG

o jnet.jar – Required to establish the SSL connection with PG

o cryptix32.jar – Required by SFA to encrypt the data sent to the PG

o sfa.jar (This contains a properties file and a set of class files) –

Required to send transactions to the PG

o pgcert.cer – This is the public certificate of the Payment Gateway

which needs to be imported into the keystore of the Java Runtime.

This is required for establishing the SSL connection between the

SFA and the PG

Installation Process: - • Set the jar files in the CLASSPATH (app and system) (The classpath must

contain the absolute path to the jar files with the names of the jar files

included).

• Set the key file directory. For more information see Set Key Directory 50


• Import public certificate. For more information see Import Public Certificate

• The Merchants components can now start using the SFA components Please

refer to the Java Documents that are sent along with the SFA zip file for

further details

Back to PERLSet Key Directory: - Back to PHP

• Open the file sfa.jar using WINZIP. Open the sfa.properties file.

• For the parameter 'Key.Directory' in the properties file set the name of the

folder, which contains the key. A trailing slash has to be put at the end of this

value. The name of the file need not be set.

• Save the properties file in the jar.

Note: -

If WINZIP or a similar facility is not available on the machine then the following java

command can be used for extracting the properties file

jar -xvf sfa.jar

To jar the file again use,

jar -cvf sfa.jar com sfa.properties

To verify the success of the above operations open the jar file again and check if the

properties file has the values set.

Back to PERL

Import Public Certificate Back to PHP

It is necessary to import the public key of the Payment Gateway into the

keystore of the JDK so that the SSL communication can be facilitated. keytool is located in $JAVA_HOME/bin/keytool

For importing public certificate, use following command

keytool -import -trustcacerts -alias pgcert –file $CERT_LOCATION$\pgcert.cer –

keystore $JAVA_HOME$\jre\lib\security\cacerts -storepass changeit

51


example: keytool -import -trustcacerts -alias epgcert -file epgcert.cer -keystore /usr/local/java/jre/lib/security/cacerts

the default keystore password is changeit, please make a note of the password and

the alias used since that would be required while removing the certificate.

To remove an existing certificate; keytool -delete -alias epgcert -keystore /usr/java/j2sdk1.4.2/jre/lib/security/cacerts

Where,

$CERT_LOCATION$ is the location of the cert file

$JAVA_HOME$ refers to the folder in which the JDK is installed

Note: -

• Replace $CERT_LOCATION$ and $JAVA_HOME$ with absolute paths.

• The directory delimiter "\" must be changed as per the Operating System

• A reference file named setkeystore.bat is shipped along with the SFA

Using the batch file (only WINDOWS users)

• Open the Batch file setkeystore.bat. Set the following parameters in the Batch

file –

o JAVA_HOME - This parameter should point to the installation

directory of the JDK Example, c:\jdk1.3;

o CERT_PATH - This parameter should point to the folder in which the

.cer has been placed. The name of the file need not be set. Execute

the batch file setkeystore.bat from 'cmd'

After executing the command or batch file, a message is displayed on the console

"Trust this certificate? [no]:". Type 'y'.

A message "Certificate was added to keystore" should be displayed

indicating the certificate was successfully imported into the keystore

52


Running the JAVA LoadTester Set this file javaLoadTester.class in the Path.

Try to execute this file by given the command:

java JavaLoadTester [MID] [TYPE] [COUNT]

Where MID: Merchant Id provided by ICICI. Ex. 00001001

TYPE: 1 for SSL and 2 for MOTO

COUNT: Number of transactions to be fired

Please Note: In order to run the LoadTester, you need to set the verbose flag in the

sfa.properties to true.

53


ASP Installation (Windows 2000 and NT)

Merchants on Windows 2000 or Windows NT (Versions which has inbuilt java

support can integrate using this section

Download required files: - • Login to MWI Module, Click on “SFA -> download SFA”, select asp sfa and

download asp.zip file.

• Extract asp.zip so that following files will get extracted.

o ASP_SFA_DEPENDENCIES_1.zip: - Contains .class files required to

encrypt the data sent to the PG

o ASP_SFA_DEPENDENCIES_2.zip: - Contains msxml.msi component,

required to establish the SSL connection with PG

o ASP+SFA+&+ASP+DOCS.zip: - This zip file contains the components

& docs, which provide the core SFA functionality

Installation Process: - • Install Msxml.msi component present in ASP_SFA_DEPENDENCIES_2.zip.

(It is necessary to install SP3 on WINDOWS Server for the installation

of this package)

• Unzip the files cryptix32.jar and sfa.jar present in

ASP_SFA_DEPENDENCIES_1.zip under the folder

$:\WINNT\java\trustlib where '$' points to the drive in which Windows is

installed. The following structure should be created in the folder

54


• Extract sfa.zip file present in ASP+SFA+&+ASP+DOCS.zip in the default

folder of the web server, which hosts the Merchants ASP file. For example

www-root. Unzipping the file would create a folder called “Sfa” under the

default folder of the web server & file sfa.properties in default folder.

• Open the sfa.properties file. For the parameter 'Key.Directory' in the

properties file set the name of the folder, which contains the key. A trailing

slash has to be put at the end of this value. The name of the file need not be

set. Save the properties file

55


ASP Installation (Windows 2003)

JRE support needs to be added in Windows 2003 so that ASP SFA library can be

used to send transactions to Payment Gateway. Install the version of JRE 1.4

(mjavax86.exe) Microsoft Virtual Machine & follow same steps as ASP Installation

for Windows 2000.

56


PERL Installation

Merchants on Windows as well as on Linux/Unix platform can use SFA PERL library.


installed.

• Merchant’s server should have an application server, which can host perl

files.

Download required files: - • Login to MWI Module, Click on “SFA -> download SFA”, select perl sfa and

download perl.zip file.

• Extract perl.zip so that following files will get extracted.

o PerlFiles.zip:- This zip file contains the Perl Modules that provide

the SFA functionality.

o PERL_SFA_DEPENDENCIES.zip - This zip file contains the additional

software that has to be installed for the SFA to function. This includes

Inline-0.44.tar.gz and Inline-Java-0.41.tar.gz

o PERL+SFA.zip – This zip file contains additional required components

of java, used by Perl modules internally. This zip file contains following

files.

• jsse.jar:- Required to establish the SSL connection with PG

• jcert.jar - Required to establish the SSL connection with PG

• jnet.jar – Required to establish the SSL connection with PG

• cryptix32.jar – Required by SFA to encrypt the data sent to the

PG

• sfa.jar (This contains a properties file and a set of class files) –

Required to send transactions to the PG 57


• pgcert.cer – This is the public certificate of the Payment

Gateway which needs to be imported into the keystore of the

Java Runtime. This is required for establishing the SSL

connection between the SFA and the PG

Installation Process: - • Extract all jar files from PERL+SFA.zip and set the Jar files in the System

classpath (The classpath must contain the absolute path to the jar files with

the names of the jar files included).

• Set the key file directory. For more information see Set Key Directory


• Extract PerlFiles.zip in default folder of the web server, which hosts the

Merchants Perl files. Typically cgi-bin directory. Unzipping the file would

create a folder called “Perl” under which the Perl modules are located.

• Open the file PostLib.pm and specify the directory option DIRECTORY =>

'/usr/local/tmp'. Set it to a location where there are write privileges. This is the

directory where Inline::Java places the generated class files.

• Install Inline Module. Steps for installation are:-

o Extract files using following command

gtar –xzvf Inline-0.44.tar.gz

o Go in extracted directory and type following commands

perl Makefile.PL

make

make test

make install

o Note: - For windows, use nmake instead of make.

• Install Inline-java Module. Steps for installation are:-

o Extract files using following command

gtar –xzvf Inline-Java-0.41.tar.gz

o Go to extracted directory and type following commands

58


perl Makefile.PL J2SDK=/your/java/dir

make java

make

make test

make install

o Note: - For windows, use nmake instead of make.

59


PHP Installation

Merchants on Windows as well as on Linux/Unix platform can use SFA PHP library.


installed.

• Merchant’s server should have an application server, which can host .php

files.

• PHP should have Java support. For more information see section Adding

Java support in PHP.

Download required files: - • Login to MWI Module, Click on “SFA -> download SFA”, select java sfa and

download php.zip file.

• Extract php.zip so that following files will get extracted.

o phpfiles.zip:- This zip file contains the PHP Modules that provide the

SFA functionality

o sfa.zip - This zip file contains additional required components of java,

used by PHP modules internally.

Installation Process: - • Extract all jar files from phpfiles.zip and set the Jar files in the classpath

specified in php.ini For more information see the configuration of Java support

in PHP.

• Set the key file directory. For more information see Set Key Directory 60



• The Merchants components can now start using the PHP SFA components

Configuring Java support in PHP on UNIX With APACHE: -

1. To include Java support in your PHP build you must add the option –with-

java[=DIR].

Where DIR points to the base install directory of your JDK.

2. You have to configure php with following command.

./configure --with-apxs2=/usr/local/apache2/bin/apxs –with-java[=Dir].

3. make

4. make install.

5. Copy all the jar files sfa.jar, jnet.jar, jsse.jar, jcert.jar, servlet.jar, cryptix32.jar into

directory “/usr/local/lib/php/extensions/no-debug-non-zts-20020429 “.(You can

put the jar files in another directory also but then you have to specify

directory in the "java.class.path" of php.ini file).

6. Edit the php.ini file in /usr/local/lib/ directory.

a. extension_dir = /usr/local/lib/php/extensions/no-debug-non-zts-20020429.

b. extension=java.so.

c. java.class.path = /usr/local/lib/php/extensions/no-debug-non-

zts-20020429/sfa.jar:/usr/local/lib/php/php_java.jar:

/usr/local/lib/php/extensions/no-debug-non-zts-20020429/servlet.jar:

/usr/local/lib/php/extensions/no-debug-non-zts-20020429/jnet.jar:

/usr/local/lib/php/extensions/no-debug-non-zts-20020429/jcert.jar:

/usr/local/lib/php/extensions/no-debug-non-zts-20020429/jsse.jar:

/usr/local/lib/php/extensions/no-debug-non-zts-20020429/cryptix32.jar

d. java.home = /usr/java/jdk1.3/jre.

e. java.library = /usr/java/jdk1.3/jre /bin/classic/libjvm.so.

(Where /usr/java/jdk1.3 is $JAVA_HOME directory)

61


(/usr/local/lib/php is the directory where php is installed)

Note: php_java.jar file should be in the java.class.path for PHP

to java connection.

7. You only need to add the following lines in httpd.conf, and restart your server

AddType application/x-httpd-php .php.

8. Add entry to "envvars" file in /usr/local/apache2/bin/

LD_LIBRARY_PATH="/usr/local/apache2/lib:$JAVA_HOME/jre/bin/classic:$JAV

A_H OME/jre/bin:$LD_LIBRARY_PATH"

export LD_LIBRARY_PATH.

9. Also Add entry to the .bashrc file inside your login directory (inside

/home/login name)

10. LD_LIBRARY_PATH="/usr/local/apache2/lib:$JAVA_HOME/jre/bin/classic:$JAV

A_HOME/jre/bin:$LD_LIBRARY_PATH"

export LD_LIBRARY_PATH.

($JAVA_HOME/jre/bin/classic and $JAVA_HOME/jre/bin is the path of JDK

directory where your "libjvm.so" and "libjava.so" is located).

11. Copy PHP SFA and all the test pages to the Document root of the Apache.

12. To make symbolic link do 'cd' into the extensions directory (Directory where

java.so is located) and run command 'ln -s java.so libphp_java.so'

13. Run index.php page to know whether php is installed properly.

14. Run testjava.php to know whether php and java connection working properly.

Configuring PHP on Windows With IIS 5 1. Assuming php is already installed under directory structure c:\PHP\.

2. Make a directory and copy all the jar file inside it. For example make a directory

"javafiles" inside c:\php.

3. Copy sfa.jar, servlet.jar, cryptix32.jar, jnet.jar, jcert.jar, and jsse.jar

inside c:\php\javafiles.

62


4. Set the Environment variable to PATH=%PATH%;C:\PHP;(Assuming

php.exe is under c:\php directory). If PATH entry is already there then

don’t set the PATH variable already there).

5. Open php.ini file in C:\WINNT.

a. Update extension_dir = c:\php\extensions or c:\php (depending upon

where are all your libraries).

b. Update doc_root = c:\inetpub\wwwroot.

c. Update

java.class.path=”c:\php\extensions\php_java.jar;c:\php\javafiles\sfa.jar;c:\p

hp\javafiles\cryptix32.jar;c:\php\javafiles\jnet.jar;c:\php\javafiles\jcert.jar;c:\

php\javafiles\jsse.jar;c:\php\javafiles\servlet.jar.

d. java.home = "c:\jdk1.3\jre".

e. Update extension=php_java.dll

f. Update java.library = "c:\jdk1.3\jre\bin\classic\jvm.dll".

(While c:\jdk1.3 is JAVA_HOME directory).

6. Copy php_java.dll inside "c:\php\extension" or "c:\php" (depending upon your

path given in extension_dir in php.ini file, Don’t copy if it is already there).

7. php_java.dll and php_java.jar can be downloaded from site http://fresh.t-systems-

sfr.com/pc/src/www/.warix/php-4.2.3-Win32.zip.html

8. Copy the php SFA and the test pages inside “c:\inetpub\wwwroot” or in your root

directory specified in doc_root in php.ini file.

9. For IIS configuration go to system administrator console using command

"inetmgr" in start->run.

10. Select the “Default web site”, right click on it and then select properties.

11. Go to "Home directory" Tab, click on "configuration" button select "Add Mapping"

tab click on "add" button add "C:\php\php.exe" in executable text box and ".php"

in extension textbox without quotes and apply it. If entry is already there then you

don't need to add it.

12. Execute index.php to check whether phpfile is running properly.

63


13. Execute testjava.php to know whether java and php connection is made properly.

The Merchants can now start using the SFA components.

http://fresh.t-systems-sfr.com/pc/src/www/.warix/php-4.2.3-Win32.zip.html

http://fresh.t-systems-sfr.com/pc/src/www/.warix/php-4.2.3-Win32.zip.html

Sample Codes

ICICI can provide sample files for the testing purpose. Send a mail to Technical

contact requesting sample files. Following files can be provided: -

• TestSsl - For ssl merchants

• TestMoto - For moto merchants

• SfaResponse- For ssl merchants. Response page.

• TestTxnSearch- For online Transaction search

• TestOnlineInquiry- For getting the status of old transaction

• TestRelatedTxn- For related transactions. I.e. Auth, Refund

These test pages are currently available in following technologies.

• JAVA

• ASP

• PERL

• PHP

Merchants can create their own files with the help of sample files.

64


Method Summary

The MOTO and the SSL Merchant’s use the Store Front Adaptor for integrating with

the Payment Gateway. This section details the data that is passed from the

Merchant to the Payment Gateway via the Store Front Adaptor.

The following sections define the various parameters and their definitions.

(Underlined parameters can be hard coded in the script)

setMerchantDetails SSL and MOTO merchants should invoke this method for passing merchant and root

transaction details. Sr. No

Parameter Details Example Maximum size / Type

Mandatory

1 astrMerchantID ID assigned by the Payment

Gateway to the Merchant

00001001 8

Numeric

Yes

2 astrVendor

Same as Merchant ID 00001001 8

Numeric

No

3 astrPartner


Numeric

No

4 astrCustIPAddress

Corresponds to the IP

Address of the Customer. In

case of a SSL merchant this

data will be captured by the

Payment Gateway. However,

a MOTO merchant has to

pass this data to the Payment

Gateway. This data is

mandatory for a MOTO

merchant and non-mandatory

for the SSL merchant

233.10.23.

34

20 SSL: No

MOTO:

Yes

65


5 astrMerchantTxnID

Transaction number

generated by the Merchant

for reference. Multiple

transactions can share the

same Transaction Reference

Number. For example, the

Auth and the Capture can

have the same Transaction

Reference Number but

different Transaction Id's.

Root Transactions should

have unique Transaction

Reference Number.

PG-

20041223-

001-001

50

Alphanumeric

Yes

6 astrOrderReferenc

eNo

Order number generated by

the Merchant for his/her

reference.

ORD-0001 30

Alphanumeric

No

7 astrRespURL

URL of the Merchants site on

which the Payment

Gateway must post the

results of the transaction.

This parameter is valid only in

case of a SSL merchant The

MOTO merchant always

receives the response via the

PGResponse Object

https://mysi

te.com/pgR

esponse.js

p

80

Url

SSL:

Yes

8 astrRespMethod

HTTP method (GET/POST)

to be used by the Payment

Gateway for posting the

results of the transaction to

the Merchants site. This

parameter is valid only in

case of a SSL merchant

POST

GET

4

Characters

Yes

9 astrCurrCode

Currency of the transaction.

ISO Alpha Currency Code

INR 3

ISO

Yes

10 astrInvoiceNo

Invoice number generated by

the Merchants application

Inv-001 20

Alphanumeric

No

66


11 astrMessageType

Indicates the type of

transaction. This field can

contain either of the values

mentioned in the adjacent

field

req.Preaut

horization

req.Sale

20

Alphanumeric

Yes

12 astrAmount

Amount of the transaction 999999999

999999.99

999

15.5

Numeric

Yes

13 astrGMTOffset

GMT Time Offset of the

Merchants sites locale

GMT+05:3

0

9

GMT±hh:mm

No

14 astrExt1

This field can be used by

merchant to pass additional

data.

1 50

Alphanumeric

No

15 astrExt2

For SSL (non-MPI)

merchants this field is only

used to set the encryption of

the response received to true

/ false.

If set to “true”, the response

would be encrypted.

For MOTO and SSL-MPI

merchants, this field can be

used by merchant to pass

additional data.

true / any

other data.

50

Alphanumeric

No

16 astrExt3

Additional fields provided to

the Merchant for passing any

specific data

3 50

Alphanumeric

No

17 astrExt4



specific data

4 50

Alphanumeric

No

18 astrExt5



specific data

5 50

Alphanumeric

No

67


setMerchantRelatedTxnDetails SSL and MOTO merchants should invoke this method for related transaction. I.e.

For capturing transactions or refunding transactions. Sr. No


Mandatory

1 astrMerchantID ID assigned by the Payment

Gateway to the Merchant

00001001 8

Numeric

Yes

2 astrVendor


Numeric

No

3 astrPartner


Numeric

No

4 astrMerchantTxnID

Transaction number

generated by the Merchant

for reference. Multiple

transactions can share the

same Transaction Reference

Number. For example, the

Auth and the Capture can

have the same Transaction

Reference Number but

different Transaction Id's.

Root Transactions should

have unique Transaction

Reference Number.

PG-

20041223-

001-001

50

Alphanumeric

Yes

5 astrRootTxnSysRef

Num

Transaction reference

number generated by the

Payment Gateway for the

original transaction and sent

to the merchant. Example, for

an Authorization transaction

the Root Transaction System

reference of Pre-

Authorization needs to be

given. Similarly, for a Refund

200411260

375166

50

Alphanumeric

Yes

68


transaction the Root

Transaction System

reference of Authorization

needs to be given

6 astrRootPNRef RRN number sent by the

Payment Gateway to the

merchant for the original

transaction. Example, for an

Authorization transaction the

RRN of Pre-Authorization

needs to be given. Similarly,

for a Refund transaction the

RRN of Authorization needs

to be given.

000000217

649

20

Numeric

Yes

7 astrRootAuthCode Auth Code sent by the

Payment Gateway to the

merchant for the original

transaction

217649 6

Numeric

Yes

8 astrRespURL This value can be currently

passed as null. This field is

reserved for a future use

80

Alphanumeric

No

9 astrRespMethod This value can be currently

passed as null. This field is

reserved for a future use

POST /

GET

4 No

10 astrCurrCode Currency of the transaction INR 3

ISO

Yes

11 astrMessageType Indicates the type of

transaction. This field can

contain either of the values

mentioned in the adjacent

field

req.Refund

req.Authori

zation

2

Alphanumeric

Yes

12 astrAmount Amount of the transaction 2345.34 15.5

Numeric

Yes

13 astrGMTOffset GMT Time Offset of the

Merchants sites locale

GMT+05:3

0

9

GMT±hh:mm

No

14 astrExt1 This field can be used by 1 50 No

69


merchant to pass additional

data.

Alphanumeric

15 astrExt2

For SSL (non-MPI) merchant

this field is only used to set

the encryption of the

response received to true /

false.

If set to “true”, the response

would be encrypted.

For MOTO and SSL (MPI)

merchants, this field can be

used by merchant to pass

additional data.

2 50

Alphanumeric

No

16 astrExt3



specific data

3 50

Alphanumeric

No

17 astrExt4



specific data

4 50

Alphanumeric

No

18 astrExt5



specific data

5 50

Alphanumeric

No

setCardDetails MOTO merchants should invoke this method for passing card information to

Payment Gateway. This is a mandatory method for MOTO merchants and object

created by this method must be passed to Payment Gateway. Sr. No


Mandatory

1 astrCardType The card type of user. For

Visa card parameter value

should be VISA and for

mastercard it should be MC

VISA

MC

5

Characters

Yes

2 astrCardNum Card number of the user 412345671 20 Yes

70


2345678 Numeric

3 astrCVVNum CVV2 / CVC2 number of card 123 3

Numeric

Depend

s upon

card

type

4 astrExpDtYr Expiry Date of Card 2008 4

Numeric

Yes

5 astrExpDtMon Expiry Month of Card 10 2

Numeric

Yes

6 astrNameOnCard Name printed on Card Myname

Mysurnam

80

Alphabetic

No

7 astrInstrType Currently only Credit Cards

are supported by PG.

CREDI

DEBIT

5

Alphabetic

Yes

setAddressDetails (Ship To Address) Merchants can invoke this method for passing ship to address details to Payment

Gateway. Merchants can also pass null object instead on passing object created by

this method. However, if the Class is instantiated and passed to the SFA, then it is

necessary to populate the fields marked as mandatory Sr. No


Mandatory

1 astrAddrLine1 Line 1 of address details 23/B, my

society

50

Alphabetic

Yes

2 astrAddrLine2 Line 2 of address details My Road 50

Alphabetic

No

3 astrAddrLine3 Line 3 of address details Mahim 50

Alphabetic

No

4 astrCity City of Card holder Mumbai 30

Alphabetic

Yes

5 astrState State of Cardholder Maharashtr

a

30

Alphabetic

Yes

6 astrZip Valid zip code of cardholder 400016 10

Numeric

Yes

71


7 AstrCountryAlphaC

ode

ISO Code of Country. IND for

India

IND 3

Alphabetic

Yes

8 astrEmail Email address of Card holder Myemail.ici

cibank.com

80

Alphanumeric

No

setAddressDetails (Bill To Address) Merchants can invoke this method for passing ship to address details to Payment

Gateway. Merchants can also pass null object instead on passing object created by

this method. However, if the Class is instantiated and passed to the SFA, then it is

necessary to populate the fields marked as mandatory Sr. No


Mandatory

1 astrCustomerId Customer Id. Reserved for

future use

0001000 10

Alphanumeric

No

2 astrCustomerName Customer Name. Reserved

for future use

somename 80

Alphanumeric

No

3 astrAddrLine1 Line 1 of address details 23/B, my

society

50

Alphabetic

Yes

4 astrAddrLine2 Line 2 of address details My Road 50

Alphabetic

No

5 astrAddrLine3 Line 3 of address details Mahim 50

Alphabetic

No

6 astrCity City of Card holder Mumbai 30

Alphabetic

Yes

7 astrState State of Cardholder Maharashtr

a

30

Alphabetic

Yes

8 astrZip Valid zip code of cardholder 400016 10

Numeric

Yes

9 AstrCountryAlphaC

ode

ISO Code of Country. IND for

India

IND 3

Alphabetic

Yes

10 astrEmail Email address of Card holder Myemail.ici

cibank.com

80

Alphanumeric

No

72


SetMPIResponseDetails MOTO MPI enabled merchants should invoke this method for passing the response

received from MPI. Sr. No


Mandatory

1 AstrECI ECI Value received from MPI 05 2

Numeric

Yes

2 AstrXID XID generated by MPI NTBlZjRjM

ThjNTUxYz

k1MTY=

28

Alphanumeric

Conditio

nal

3 AstrVBVStatus Result of MPI transaction Y, N, U, A,

E

1

Character

Yes

4 AstrCAVV CAVV returned by MPI AAAAAAA

AAAAAAA

AAAAA=

28

Alphanumeric

Conditio

nal

5 AstrShoppingConte

xt

Same as Merchant

Transaction Id

PG-1001 256

Alphanumeric

No

6 AstrPurchaseAmou

nt

Amount Passed to MPI 1000 20

Alphanumeric

No

7 AstrCurrencyVal Numeric ISO code of

currency

356 3

Numeric

No

setMPIRequestDetails SSL MPI enabled merchants should invoke this method for requesting MPI Call. Sr. No


Mandatory

1 AstrPurchaseAmou

nt

Amount of transaction.

Unformatted purchase

amount. It should not contain

any special characters such

as “$” etc.

10045.78 20

Numeric

Yes

2 astrDisplayAmount Formatted purchase amount.

This field should contain a

INR1,234.5

6

20

Alphanumeric

Yes

73


currency symbol, with an

thousands separator (s),

decimal point and ISO minor

units defined for the currency

specified in the Purchase

Currency field.

3 astrCurrencyVal This is the ISO Numeric

currency code used by the

merchant.

356 3

Numeric

Yes

4 astrExponent Denotes the number of digits

after the decimal point in the

amount

2 3

Numeric

Yes

5 AstrOrderDesc Brief description of items

purchased, determined by the

Merchant

2 shirts 125

Alphanumeric

Yes

6 astrRecurFreq This field is calculated based

on installments and the Recur

End and it denotes the

frequency of payment

(Send blank for normal

transactions)

12 3

Numeric

Yes

7 astrRecurEnd This field indicates the end

date of recurring value. It

should be less than the card

expiry date.


transactions)

20041021 8

Numeric

(yyyymmdd)

Yes

8 astrInstallment Number of Installments


transactions)

5 3

Numeric

Yes

9 astrDeviceCategory This attribute indicates mode

of transaction. For an internet

based transaction the value

to be set is "0".

0 1

Numeric

Yes

10 astrWhatIUse This field is used by the MPI

to denote the browser

6.0 8

Alphanumeric

No

74


version.

11 astrAcceptHdr The Accept request-header

field can be used to specify

certain media types which are

acceptable for the response.

Accept headers can be used

to indicate that the request is

specifically limited to a small

set of desired types, as in the

case of a request for an in-

line image. The server

property

request.getHeader("Accept")

can be used for setting this

value.

image/gif,

image/x-

xbitmap,

image/jpeg,

image/pjpe

g,

application/

vnd.ms-

powerpoint,

application/

vnd.ms-

excel,

application/

msword,

application/

x-

shockwave

-flash, */*

256

Alphanumeric

Yes

12 astrAgentHdr The User-Agent-header

contains information about

the user agent (typically a

newsreader) generating the

article, for statistical purposes

and tracing of standards

violations to specific software

needing correction. Although

not one of the mandatory

headers, posting agents

SHOULD normally include it.

The server property

request.getHeader("User-

Agent") can be used for

setting this value.

Mozilla/4.0

(compatible

; MSIE 5.5;

Windows

NT 5.0)

256

Alphanumeric

Yes

75


6 Trouble shooting

This chapter details the solutions to some commonly encountered problems faced

by the Merchant while using the merchant module

Q) On accessing the Java SFA, a java.lang.NoClassFoundDefError is generated. What needs to be done in this case? A) It is necessary to set the name of the SFA jar file in the classpath. The absolute

path to the Jar file along with the file name must be set in the classpath to resolve

the error.

Q) I have posted the Request to the Payment Gateway, however, am not receiving the response online? A) The Payment Gateway posts the response of the transaction to a URL passed to

the SFA. This URL is called the Response URL. Please check if an appropriate URL

is passed to the method.

Q) I have uploaded a Transaction Batch file to the Payment Gateway. How do I see the status of the transactions that have been uploaded in the file?

A) The Payment Gateway provides an “Advanced Search” capability under the

“Transactions” option in the Merchant Web Interface. In the section “Merchant Batch

Number” enter the Batch number given by the Payment Gateway and then click on

“Search”.

76


Q) On accessing the Asp SFA, a “No object for Monikers” is generated. What needs to be done in this case? A) Check the trustlib directory structure in C:\WINNT\java

Q) We logged in to the MWI interface login page , however we can see just two options , change password and download SFA. Why it is so? A) Once you change the password you will be able to see other options as well.

Q) We are getting following error: RESPO0NSE CODE=2 RESPONSE MESSEGE: INTERNAL PROCESSING ERROR A) Please check if the parameters, format of parameters, length of the

parameters are matching with mandatory requirements.

These errors (Internal Processing Errors) occur on account of data that is sent to

Payment Gateway not in conformance with the predefined field lengths. Please use

script level validations in your website / inputs to the Payment Gateway scripts to

ensure data as per specifications

Kindly refer to the Payment Gateway function call details given in this manual.

Q) We are getting following error: Response code:2 Response message: No response From Payment Gateway or URL not found A) Please check your connectivity to the server using the following command;

telnet payseal.icicibank.com 443

this should result in a blank window, indicating proper connectivity with the Payment

Gateway Servers.

Check with your network administrators if you are situated behind a firewall to

ensure connectivity to the servers over 443 port.

Q) We are getting following error

77


Response Code: 2

Response Message: Invalid Credentials The problem is with key, or the key has become corrupt. Please contact

PGHelpdesk and get a key regenerated. Please ensure you store a copy of the key.

Q) Error Type: Java Exception (0x80004005) java.io.FileNotFoundException: C:/icici/00001000.key /Sfa/include.asp, line 325 A) The SFA is unable to locate the key file, please check key directory path in the

sfa.properties file, and ensure the key is stored with the filename as your merchant

ID and “.key” as extension.

Example: For Merchant ID 00001000, the key filename would be 00001000.key

Q) Error '8000ffff' catastrophic failure /Sfa/include.asp, line 325 A) Check the trustlib directory structure

Q) Getting error “Java Exception error '80004005' java.lang.ArrayIndexOutOfBoundsException /sfa/include.asp, line 325 A) Please check the trustlib directory structure.

Q) Error is Error '800401e4' /erosindia/shopping/Sfa/include.asp, line 324 A) On Windows 2003, the Version of JRE you need to install is 1.4.1_03

(msjavx86.exe, Microsoft Virtual Machine). Please install JRE from below given link.

Don’t forget to restart the IIS every time you do any of these activities.

Please click on this UrL

http://www.filemirrors.com/search.src?file=msjavx86.exe&size=5473872

78


Please do the following:

http://www.filemirrors.com/search.src?file=msjavx86.exe&size=5473872

in include.asp file(present in sfa folder) change Set

objXML=Server.CreateObject("MSXML2.ServerXMLHTTP.4.0") to

Set objXML=Server.CreateObject("MSXML2.ServerXMLHTTP") if this doesn't work

then keep it as it was. (Make sure you install msxml.msi)

Q) Error Occured. Error Code:2 Error Message: Internal Processing Error Error while writing data. Transaction cannot be processed Please note: Certificate error could occur only for JAVA, PHP and PERL SFAs only.

This could be due to a problem in certificate. Try to install the certificate again.

Q) Message: Error in the properties file. Value for OS.Type is not mentioned or is invalid A) Please check the property “OS.Type” ,is it present in sfa.properties file or not.

Make sure that it is in correct case.

Q) You see following error “AS004 : User inactive “ when you are trying to login to the Merchant Web Interface. A) This would need the user to be activated, and the password to be reset.

79


Q) I got following error when i tried to login from Warning! MWI AS006 : Max. Concurrent logins reached. A) This is due to number of users logged in to the MWI Interface, exceeding the

maximum count allowed. Note: Please do logout of the Interface after you are finished with your activities.

Q) I got following error when i tried to login from Warning! MWI WS004 : Invalid session , Click here to login. A) This is due to the session timeout resulting on account of idle time on the MWI

window. Please close the window, and login again in a new browser window. Note: Please do logout of the Interface after you are finished with your activities.

Q) Error “Rejected by Gateway”: Transactions will be Rejected by Gateway because of following reasons:-

1)Invalid card number:-when the end-user is not putting or typing his card number

and validation date properly then payment gateway system verify the contents and

send the message that card number is not valid and because of that the particular

transaction is rejected by gateway.

2) Duplicate Merchant Transaction Id:-Order ID should be unique for each and every

transaction. If the same order id is passed from merchant side for two different

transactions then the “Duplicate Merchant Transaction Id” error will appear on

interface. So its merchant’s responsibility to take care that “Order ID” should be

unique for each transaction.

And last transaction was already done with dummy credit card details so it is giving

expected result "unauthorized usage" error on gateway that means transactions

going through the gateway successfully. If any problem is happened with the

payment gateway then our other merchants should not able to do transaction

successfully on their site.

80



81


Q) Response code: 2 Response Code: Merchant is SSL type. MOTO txn not allowed

A) Above error message is comes when the merchant is configured SSL on payment

gateway system and merchant tried to pass the parameters as MOTO merchant

from his end. You are configured as SSL merchant at our end because as per the

banks security policy we can allow SSL type of integration for your Merchant ID,

since we do not wish that you accept the card numbers at your server/site. The card

number, expiry date & security information are accepted & stored in the banks

server and the same can be accessed by authorized bank personnel only. For any

further clarification you may contact your local ICICI Bank relationship manager.

Date post:	06-Feb-2022
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times