WO2003067535A1

WO2003067535A1 - Transaction processing system

Info

Publication number: WO2003067535A1
Application number: PCT/AU2003/000113
Authority: WO
Inventors: Daniel Lavecky
Original assignee: Pure Commerce Pty Ltd
Priority date: 2002-02-05
Filing date: 2003-02-05
Publication date: 2003-08-14
Also published as: AUPS033502A0

Abstract

A transaction processing system for transacting in multiple currencies, the system comprising: a first transaction processing system for entering transaction; at least one gateway processing system interconnected to the first transaction processing system by a wide area network; a currency conversion system connected to the gateway processing system for converting the transaction value to a foreign currency value whilst the transaction is being carried out; a transaction charging system for charging the converted transaction value to the customer's card account. A method of processing a transaction between a merchant operating in a first currency and a customer having a transaction account in a second currency, in which the transaction is settled via one or more intermediate parties is also disclosed.

Description

Transaction processing system

Field of the invention

The present invention relates to the field of transaction processing and, in particular, discloses a multi currency credit card transaction processing system. Background of the invention

In the year 2000, $76.8 billion was processed in credit card payments in Australia (APCA 2001). According to the Reserve Bank of Australia, $81,734 billion was transacted using credit cards for the financial year 2000/01 (www.rba.gov.au)

At present, when it is desired to perform multi currency credit card transactions, the process is quite convoluted with the credit card issuing bank often making large profits.

Summary of the invention

It is an object of the present invention to provide for an alternative form of transaction processing. hi accordance with a first aspect of the present invention, there is provided a transaction processing system for transacting in multiple currencies, said system comprising: a first transaction processing system for entering a transaction in a first currency ; at least one gateway processing system interconnected to said first transaction processing system by a wide area network; a currency conversion system connected to said gateway processing system for converting the transaction value in said first currency to a currency value in a second currency whilst the transaction is being carried out; a transaction charging system for charging the converted transaction value to the customer's card account.

Preferably the currency conversion system forwards said converted transaction value to said first transaction processing system for display to a merchant's customer. The currency conversion system is preferably interconnected to at least one externally provided rate determination system for determining an approximate converted transaction value. hi a preferred embodiment there are at least two independently operable gateways each independently connected to said first transaction processing system.

According to a second aspect of the invention there is provided a method of processing a transaction between a merchant operating in a first currency and a customer having a transaction account in a second currency, in which the transaction is settled via one or more intermediate parties, said method including the steps of: (a) providing transaction processing means configured to interact with a currency conversion means to convert a monetary value in said first currency into a monetary value in said second currency;

(b) receiving a transaction request in the first currency at the transaction processing means ; (c) processing the transaction request with the currency conversion means to determine a transaction amount expressed in the second currency; and

(d) settling the transaction with the merchant in the first currency and communicating the transaction details, expressed in the second currency, to the one or more intermediate parties to allow settlement of the transaction with the customer in the second currency. Preferably step (c) includes the sub-steps of: receiving an authorisation request expressed in the first currency; processing the authorisation request with the currency conversion means to determine the transaction amount expressed in the second currency; and processing the authorisation request in the second currency and enabling the transaction to continue if one or more predetermined authorisation conditions are met.

Step (c) can also include the sub-step of: providing a converted transaction value to the customer expressed in the second currency. hi preferred embodiments the transaction processing means may receive the transaction request from any one of the following; a point of service terminal, a cash register, a website, a server, an interactive voice response system, a call centre terminal, an automatic teller machine, a vending machine, a computer terminal, a mobile phones, a PDA, a television, a refrigerator, a satellite.

Preferably the transaction processing means includes at least one gateway means in communication with the currency conversion means and one or more of said intermediate parties to enable transaction processing and settlement information to be communicated to and from the transaction processing means.

Brief description of the drawings

Preferred embodiments of the present invention will now be described with reference to the accompanying drawings in which: Fig. 1 illustrates a flow chart of prior art methods of conducting credit card transactions;

Fig. 2 illustrates a flow chart of the methods of conducting credit card transactions of the preferred embodiment;

Fig. 3 illustrates an example architecture of the preferred embodiment; Fig. 4 is a flow chart of a transaction; and

Fig. 5 is a flow chart of a refund transaction.

Detailed description of the embodiments

The preferred embodiment, hereinafter designated PFX POS allows businesses to accept international credit card payments from their Point of Sale terminal with real-time currency conversion. PFX POS is a value added service which enables merchants to earn a new revenue stream from the processing of foreign credit card transactions. PFX POS allows the operator to capture the Foreign Exchange margin at the Point of Sale, which is normally collected by a credit card issuing bank. PFX Pos thereby generates a new revenue stream for the operator and merchant as the FX margin is shared with the merchant.

During operation, a foreign customer in a local jurisdiction hands the local merchant their credit card. The foreign customer's credit card is swiped through the PFX POS terminal and the system determines the customer's country of origin. The terminal display shows the exact amount that will appear on the customers' monthly credit card statement, in their own country's currency. The transaction proceeds and the customer is billed in their home currency. There is no currency conversion performed by the issuing bank (provider of the credit card e.g. estpac or NAB) as the system ensures that the transaction occurs in the home currency of the customer.

The benefit for customers is that they can keep tabs on their spending and not have to worry about mental arithmetic every time they use their credit cards. The benefit for businesses is that it allows them to reconcile their expenses quickly, efficiently and accurately without waiting for their monthly statements to make their claims. A significant reason that a business would want to use this service, apart from providing enhanced customer service, is that they would receive an additional revenue stream by receiving a portion of the foreign exchange that is made on each sale, h a normal transaction where a customer is using their credit card overseas, the issuing bank (i.e. the bank that gave the customer the credit card) converts the money to the customer's home currency. With the present embodiment, the conversion is done by the systems and therefore, the operator of the system retains any foreign exchange margin. The transaction proceeds as an international currency payment. The operator is able to share a percentage of this foreign exchange with the business. An example of the difference of operation is illustrated in the two flow charts of

Fig. 1 and Fig. 2. In Fig. 1, there is illustrated the present normal transaction 10 in which a merchant 11 sells a good for AU$150.00. This is communicated to the acquiring bank 12 which interacts with the card provider so as to charge AU$150.00 13. The credit card provider 13 then charges the issuing bank of the credit card 14 which conducts a foreign exchange transaction converting the AUD amount into the customer's native currency thereby debiting the customers credit card 15.

In Fig. 2, in the preferred embodiment, 20, the merchant again charges the client AU$150.00 21. Over, the merchant interacts with the preferred embodiment 22 so as to conduct an immediate foreign exchange transaction converting the AUD amount into the customer's native currency. This is then converted to US dollars and charged to the acquiring bank 23. Next, the acquiring bank charges the credit card provider 24 which in turn charges the issuing bank 25 and the statement appears on the customers credit card 26. The utilisation of the preferred embodiment at stage 22 highlights the difference provided by the present system.

It should be noted that the operator of the PFX POS terminal takes on many of the roles of the Acquiring bank, in certain embodiments will be viewed as the acquiring bank by the merchant, in the sense that the PFX POS operator will settle all transactions with the merchant. The PFX POS operator will then process and communicate the transaction (via one or more intermediate entities) to the card-holder's bank, h this case the PFX POS operator will have its own acquiring bank which provides it with access to credit card organisations such as Visa, MasterCard, American Express or the like.

The system is preferably also be able to process debit payments using the EFTPOS network in the local currency of the merchant. The EFTPOS terminal of the preferred embodiment differs from other devices on several accounts. These are:

Multi-currency capability instead of just single currency

The ability to determine the country of origin of the card

Ability to query a database of real-time exchange rates and convert the sale price into the customer's home currency Accept payment in many different currencies

Turning now to Fig. 3, there is illustrated the components of an example PFX POS System 30.

PFX POS Terminal 31 This consists of hardware for swiping credit/debit cards and software for processing transactions. The software resides on a PC 32 which is part of the terminal 31. The card information is passed from a swipe reader to the software. The payment information is passed from the cash register 33 to the software. The transaction is generated and sent to one of the PFX Gateways 35,36. The PFX POS terminal 31 constantly polls the PFX Gateways 35,36 to check availability.

PFX Gateway 35,36

These machines support trouble shooting facilities for the PFX POS Terminal. They also provide a pathway for switching transactions to a PFX Converter 37, Pure Global Pay 38 and the Debit Acquirer 39.

PFX Converter 37

The PFX Converter 37 machine manages the currency exchange for transactions. This links with the Rate Engines 41 and Derivatives Engines 42 to find competitive exchange rates and process deals. Rate Engines (externally supplied) 41

This is located at the financial institution and provides real-time exchange rates. The PFX Converter can be linked to many Rate Engines.

Derivatives Engine (externally supplied) 42

This is located at the financial institution and provides forward and spot contracts for exchange deals.

Pure Global Pay 38

Pure Global Pay is the multi-currency merchant service system which links to multiple financial institutions around the world 44 for the processing of credit card transactions. Debit Acquirer (externally supplied) 39

The Debit Acquirer is a financial institution that processes debit card transactions.

Treasury Management System 46 This system is for managing the foreign exchange accounting including exchange rates used for transactions, profit/loss made, aggregate accounts for specified time intervals.

Global Settlement System 47 This system is for managing settlement of funds to clients. It will calculate the amount owing to clients, create client statements and will link to the banking system to settle funds into the clients' nominated bank accounts.

Online Reporting System 48

This system provides the client with real-time sales reports. It links into the transaction database which logs all transactions. It also allows the client to search for individual transactions that were processed through the system and therefore acts as a CRM solution for the client.

Turning to Fig. 4, there is illustrated the series of steps involved in executing a credit card type transaction utilising the preferred embodiment. Further, in Figure 5, there is illustrated the series of steps involved in providing a customer refund utilising the preferred embodiment.

Figure 4 depicts a flow chart 40 representing a method for conducting a credit card transaction, according to a preferred embodiment of the present invention, in which the merchant's native currency is different to that of the customer, hi the initial step 401 the merchant presents a bill to the customer in the merchant's native currency.

The native currency of a party to a transaction should be understood to refer to that currency that the party to the transaction would prefer to, or must, conduct the transaction. For example a merchant's native currency will typically be the currency used in the geographical location in which they operate, eg. a merchant in Australia will typically operate in Australian dollars. However the native currency of the merchant may be a foreign currency if they have a foreign currency bank account. A customer's native currency will be the currency in which the credit or debit card being used is operated. As will be appreciated this will typically be the local currency in the customer's homeland but may be another currency. In the next Step 402 the bill is processed by the PFX POS terminal (item 31 of figure 3). The PFX POS terminal uses the credit card details to determine the currency in which the cardholder is to ultimately be billed, ie. card holders native currency. The PFX POS terminal also interrogates the exchange rate engine to determine an exchange rate to use for the transaction, and the details of the foreign exchange rates are stored. This determined foreign exchange rate is then used to convert the transaction value (which up to this point has been expressed in the merchant's native currency) into the native currency of the customer. The authorisation request is then sent to the Acquiring bank in terms of the calculated transaction value expressed in the customer's native currency. In Step 403, the authorisation response is received from the customer's bank at the PFX POS terminal. If the transaction is declined then the transaction ends. If it is approved then a receipt in the merchant's native currency is issued for the customer's signature. At this point the customer can be informed that the transaction has been processed in their home currency and the amount charged to their credit card in their native currency. Thus the customer can immediately be made aware of the transaction value in a currency that he/she is familiar with, which may aid the customer with budgeting or other cost analysis, hi an alternative embodiment the customer may be notified of the transaction value in his or her native currency prior to the authorisation request being processed. This would enable the customer to stop the transaction before processing if he or she finds he or she is unhappy with the price when it is expressed in a currency familiar to him or her.

In Step 404, the cost to be charged to the customer and paid to the merchant are effectively set (although deductions or fees etc have not yet been subtracted from the merchant's amount) However the foreign exchange transaction has not been performed. In step 404 a set of exemplary rules for affecting the foreign exchange transaction by the set out. As will be appreciated by those skilled in the art variations to these rules are readily applicable depending on the level of risk the operator of the system and method desires. Step 405 in the method describes an exemplary method of performing the capture stage of a credit card transaction, including steps of taking out the foreign exchange contract determined in step 404.

In Step 406 settlement is performed with the merchant by paying the settlement amount plus any deductions, such as refunds, or the merchant services fee, to the merchant. This settlement is with the merchant is performed in the merchant's native currency. As a forward contract was used for the foreign exchange component of the transaction, the settlement to the merchant is conducted before the funds from the foreign exchange are received. Step 407 comprises the step of receiving funds from acquiring bank in foreign currency and converting that currency into AUD at the forward contract exchange rate.

Step 408, is a general accounting step to calculate, inter alia, profit or loss on the transactions. This accounting information is then used in Step 409 any calculate commission to be sent to the merchants, and to send merchant services fees to the credit card acquiring banks .

Figure 5 shows a similar flow chart 500, but sets out an exemplary set of steps for performing a refund using a system according to the present invention. Initial Step 501 includes a step of the customer asking for a refund and showing their receipt. The customer's credit card is then be swiped through POS terminal to obtain card information which is then combined with the transaction details to be sent through to the multi currency transaction processing system, the next Step 502 the transaction identification is verified and, if valid, the refund is approved. If the transaction identification is invalid the refund is declined. hi Steps 503 and 504 settlement with the merchant is processed and the original amount (in the merchant's native currency ie. the value of the bill in step 401 of figure 4) plus any refund fee is deducted from the merchant's account. h step 505 the amount charged to the customer's account is looked up and refunded. Any losses or profits made the result of the refund are also accounted for in this step. In the final step 506 the system operator settles the refund with the acquiring bank. Whilst it will be evident that many different software designs can be utilised to achieve the operational aspects of the present invention, appendix A discloses code indicative of a Java server class able to be used in connection with an embodiment of the present invention. The current invention is described in relation to processing credit card transactions, however it should be noted that the system and method may be applied to transactions using debit cards or the like.

It will be understood that the invention disclosed and defined herein extends to all alternative combinations of two or more of the individual features mentioned or evident from the text or drawings. All of these different combinations constitute various alternative aspects of the invention.

The foregoing describes embodiments of the present invention and modifications, obvious to those skilled in the art can be made thereto, without departing from the scope of the present invention.

Claims

1. A transaction processing system for transacting in multiple currencies, said system comprising: a first transaction processing system for entering a transaction in a first currency ; at least one gateway processing system interconnected to said first transaction processing system by a wide area network; a currency conversion system connected to said gateway processing system for converting the transaction value in said first currency to a currency value in a second currency whilst the transaction is being carried out; a transaction charging system for charging the converted transaction value to the customer's card account.

2. A system as claimed in claim 1 wherein said currency conversion system forwards said converted transaction value to said first transaction processing system for display to a merchant's customer. 3. A system as claimed in either claim 1 or 2 wherein said currency conversion system is interconnected to at least one externally provided rate determination system for determining an approximate converted transaction value.

4. A system as claimed in any one of the preceding claims wherein there are at least two independently operable gateways each independently connected to said first transaction processing system.

5. A method of processing a transaction between a merchant operating in a first currency and a customer having a transaction account in a second currency, in which the transaction is settled via one or more intermediate parties, said method including the steps of: (a) providing transaction processing means configured to interact with a currency conversion means to convert a monetary value in said first currency into a monetary value in said second currency; (b) receiving a transaction request in the first currency at the transaction processing means ;

(c) processing the transaction request with the currency conversion means to determine a transaction amount expressed in the second currency; and (d) settling the transaction with the merchant in the first currency and communicating the transaction details, expressed in the second currency, to the one or more intermediate parties to allow settlement of the transaction with the customer in the second currency.

6. A method as claim in claim 5 wherein step (c) includes the sub-steps of: receiving an authorisation request expressed in the first currency; processing the authorisation request with the currency conversion means to determine the transaction amount expressed in the second currency; and processing the authorisation request in the second currency and enabling the transaction to continue if one or more predetermined authorisation conditions are met. 7. A method as claim in either claim 5 or 6 wherein step (c) includes the additional sub-step of: providing a converted transaction value to the customer expressed in the second currency.

8. A method as claimed in any one of claims 5 to 7 in which the transaction processing means receives the transaction request from any one of the following; a point of service terminal, a cash register, a website, a server, an interactive voice response system, a call centre terminal, an automatic teller machine, a vending machine, a computer terminal, a mobile phones, a PDA, a television, a refrigerator, a satellite.

9. A method as claimed in any one of claims 5 to 8 in which said transaction processing means includes at least one gateway means in communication with the currency conversion means and one or more of said intermediate parties to enable transaction processing and settlement information to be communicated to and from the transaction processing means. 10. A transaction processing system substantially as hereinbefore described with reference to the accompanying drawings.

11. A method of conducting credit card transactions substantially as hereinbefore described with reference to the accompanying drawings.

Appendix A Transaction Server- Example interface FileName: databaseTEST.java

Overview: This class is responsible for making connections to the database and logging the response as It is received from the payment gateway.

Public methods in the class:

1. makeRequest

Function Name: makeRequest

Return Type: boolean

Overview: The following function will log the transaction request details in the database. Parameters: The function will take the following parameters

Merchant ID : TYPE : Integer

Trans Amount : TYPE : Integer

Trans Notes : TYPE : Integer

2. logResponselnDatabase

Function Name: logResponselnDatabase

Return Type: void

Overview: The following function will log the response from IBM, in the database.

Parameters: The function will take the following parameters

Return Code : TYPE : Integer

Result Code : TYPE : Integer

Bank Code : TYPE : Integer

Return Message : TYPE : String

Bank Message : TYPE : String

Order Reference : TYPE : String

Transaction ID : TYPE : Integer (It must match with the transaction ID when the request was made.)

3. recordCreditCardHolderDetails

Function Name: recordCreditCardHolderDetails

Return Type: boolean

Overview : The function will write the details of the credit card holder to the database.

Parameters: The function will take the following parameters

ChFName TYPE: String chLName TYPE : String ccType TYPE : String ccExpiryDate :TYPE . String ccNumber :TYPE String cchPhone ^■TYPE String cchAddl TYPE String cchAdd2 TYPE String cchCity ^•TYPE String cch State TYPE String cchZipCode TYPE : String cch Country :TYPE : String cchEmail TYPE : String

4. getOrderNumber

Function Name: getOrderNumber

Return Type: integer

Overview: The function will return the transaction ID.

Parameters: Nil

5. getOrigSaleNum

Function Name: getOrigSaleNum

Return Type: String

Oveπ_/iew: The function will return the origSaleNumber input by the customer. Parameters: Nil

FileName: erchantValidatϊon I EST.java

Overview: This class is used to validate a merchant. It is also used to return the merchant details from the database so^' that a valid request can be put through the gateway for further processing.

Public methods in the class:

1. authenticateMerchant

Function Name: authenticateMerchant

Return I ype: boolean • Overview: The function will return a boolean value indicating that whether or not the merchant could be validated. False means, merchant could not be validated. And true, means that the merchant is valid.

Parameters: The following arguments are accepted by the method.

Merchant! D TYPE Integer merehantName TYPE String password TYPE String

. getKeyName

Function Name: getKeyName

Return Type: String

Overview; The function will return the merchant keyname from the database. Parameters: Nil

3. getKeyFileName

Function Name: getKeyFileName

Return Type: String

Overview: The function will return the keyfile name so that encryption/decryption may take place/ Parameters: Nil

4. getProjectCode

Function Name: getProjectCode

Return Type: String

Overview: The function will return the project code issued by the IBM.

Parameters: Nil

5. getCurrency

Function Name: getCurrency

Return Type: String

Overview: The function will return the associated currency.

Parameters: Nil

FileName: PureTransTESTjava

Overview: This class is the heart of the system. All the NTF functions are called from this class. It is responsible for actually processing the transactions and pulling and parsing the response.

Public methods in the class:

1. setCardHolderFName

Function Name: setCardHolderFName

Return Type: void

Overview: The function is used to set the credit card holder first name.

Parameters: String

2. setCardHolderLName

Function Name: setCardHolderLName

Return Type: void

Overview: The function is used to set the credit card holder last name.

Parameters: String

3. setCardType

Function Name: setCardType

Return Type: void

Overview: The function is used to set the credit card type.

Parameters: String

4. setCardExpiry

Function Name: setCardExpiry

Return Type: void

Overview: The function is used to set the credit card expiry date.

Parameters: String

5. setCardNumber

Function Name: setCardNumber

Return Type: void

Overview: The function is used to set the credit card number.

Parameters: String

6. setCardHoiderAddl

Function Name: setCardHoiderAddl

Return Type: void

Overview: The function is used to set the first address line of the credⁱt card holder's address. Parameters: String

7. setCardHo!derAdd2

Function Name: setCardHolderAdd2

Return Type: void

Overview. The function is used to set the second line of the credit card holder's address. Parameters: String

8. setCardHolderCity

Function Name: setCardHolderCity

Return Type: void ,

Overview: The function is used to set the city value in credit card holder's address. Parameters: String

9. setCardHolderState

Function Name: setCardHolderState

Return Type: void

Overview: The function is used to set state value in credit card holder s address. Parameters: String iO.setCardHolderCountry

Function Name: setCardHoiderCountry

Return Type: void

Overview: The function is used to set the credit card holder's country value. Parameters: String

H .setCardHolderPhone

Function Name: setCardHolderPhone

Return Type: void

Overview: The function is used to set the credit card holder's phone number. Parameters: String

12. setCardHo!derEmail

Function Name: setCardHolderEmail

Return Type: void

Overview: The function is used to set the credit card holder's email address. Parameters: String

13. setCardHolderZipCode

Function Name: setCardHolderZipCode

Return Type: void

Overview: The function is used to set the credit card holder's zip code.

Parameters: String

14. setOrigSaleMum

Function Name: setOrigSaieNum

Return Type: void

Overview: The function is used to set the original sale number as input by the user. Parameters: String

15. doCCAuth Function Name: doCCAuth Return Type: int Overview: This is probably the most important method. This is the function that actually calls NTF methods and does all the core things.

Parameters: The method takes following parameters: merchantNumber Type : integer totalAmount Type Integer fname Type String

Iname Type String

IsUS I ype Boolean currency Type String ccNumber Type String ccExpire Type String chName Type String

MerchName Type String

MerchNumber Type String

KeyName Type String

KeyFile Type String

Offset Type Integer

TransNotes Type String

I ^β. geterrors

Function Name: geterrors

Return Type: String

Overview: The function will return the errors, if any.

Parameters: Nil

17. getreturncode()

Function Name: getreturncode

Return Type: String

Overview: The function will return the return code sent to us by the

NTF. Parameters: Nil

18. getresult

Function Name: getresult

Return Type: String

Overview: The function will return the result.

Parameters: Nil

19.getbankcode

Function Name: getbankcode

Return Type: String

Overview: The function will return the bank code.

Parameters: Nil

20.getretmessage

Function Name: getretmessage

Return Tyoe: String

Overview:^' The function will return the return message sent to us by tne

IBM. Parameters: Nil

21. getbankmessage

Function Name: getbankmessage

Return Type: String

Overview: The function will return the bank message sent by the respective financial institution. Parameters: Nil

22.getorderref

Function Name: getorderref

Return Type: String

Overview: The function will return the Order reference number.

Parameters: Nil

23. getOrderNumber

Function Name: getOrderNumber

Return Type: String

Overview: The function will return the order number, which is a unⁱque transaction identifier issued by us. Parameters: Nil

24. getOrigSaleNum

Function Name: getOrigSaleNum

Return Type: String . . . ..

Overview: The function will return the original sale number, input by the user while making the request. Parameters: Nil

25.retMessage

Function Name: retMessage

Return type: S ring

Overview: The function will interpret the return code and will lookup the respective return message.

Parameters: retCode: Type: integer

Please note that in^' addition to the above file/methods, there is an additional java class file called Simulate which is a Java servlet. This servlet is very much self explanatory from the code itself. There is only one method ie. doPost.

Class files for refunds

Filename : databaseRefundTEST.java

Overview: This class manages database related stuff. It involves making connections, logging response.

Public methods in the class:

1. getOrderReference

Function Name: getOrderReference

Return Type: String

Overview: The function will return the IBM Order Reference Number from the database. Parameters: Nil

2. getTransactionStatus

Function Name: getTransactionStatus

Return Type: String

Overview: The function will return the status of the transaction in the sense that whether or not the transaction is already refunded or if it had failed at the first place. Parameters: Nil

3. getTransactionAmount

Function Name: getTransactionAmount

Return Type: Integer

Overview: The function will return the original amount of transaction.

The amount of refund must match with the amount of the transaction. Parameters: Nil

4. getRefundlD

Function Name: getRefundlD

Return Type: Integer

Overview: The function will return the refund Id from the database, which is always unique. Parameters: Nil checkStatus

Function Name : checkStatus Return Type : boolean

Overview : The following function check the status of the transaction before refunding it.

Parameters : The function will take the following parameters Transaction ID: TYPE : Integer

6. logResponse

Function Name : logResponse Return Type : boolean Overview : This function will write the response of the refund request into the database.

Parameters : The function will take the following parameters Transaction amount: Type : Integer

Result code: Type Integer Return code; Type Integer Message: Type String

7. updateTransaction

Function Name : updateTransaction

Return Type boolean

Overview This function will update the status of the transaction.

Parameters The function will take the following parameters

TransactionlD: Type : Integer

Refund ID: Type: Integer

Filename : PureRefTEST.java

Overview: This is the main refund class that actually processes the refund request and calls the NTF methods.

Public methods in the class:

getResultCode Function Name: getResultCode Return Type: String Overview: The function will return the result code associated with the refund request.

Parameters: Nil getReturnCode

Function Name: getReturnCode

Return Type: String

Overview: The function will return the return code associated with the refund request.

Parameters: Nil getRetivlessage

Function Name: getRetMessage

Return Type: String

Overview: The function will return the return message sent to us by the

IBM as a response for the refund request made. Parameters: Nil doRefund

Function Name: doRefund

Return Type: Integer

Overview: This function is the most important function in the total refund process. It calls all the NTF refund related functions. Parameters: The method takes following parameters in order to successfully complete a refund request.

MerchName; Type: String

MerchNumber: Type: String totalAmount: Type: Integer isUS: Type: Boolean currency: Type: String offset: Type: Integer number: Type: String

OrderRef: Type: String

KeyName: Type: String

Key File: Type: String

In addition to it, there is Java servlet called SimulateRefund which incorporates just one single doPost method, which doesn't need to be mentioned here.

Please note that the naming convention that has been followed is that all the files for the testing gateway ends with TEST and ail the live files will end with LIVE. But in the case of sen/lets the name of the servlets for the live gateway are as follows:

1. Live (Its Simulate under stage/testing environment.)

2. Refund (Its SimulateRefund under the stage/testing environment.)

The End

Amit.Sharma