WO2003067535A1 - Transaction processing system - Google Patents

Transaction processing system Download PDF

Info

Publication number
WO2003067535A1
WO2003067535A1 PCT/AU2003/000113 AU0300113W WO03067535A1 WO 2003067535 A1 WO2003067535 A1 WO 2003067535A1 AU 0300113 W AU0300113 W AU 0300113W WO 03067535 A1 WO03067535 A1 WO 03067535A1
Authority
WO
WIPO (PCT)
Prior art keywords
type
function
string
return
parameters
Prior art date
Application number
PCT/AU2003/000113
Other languages
French (fr)
Inventor
Daniel Lavecky
Original Assignee
Pure Commerce Pty Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to AUPS0335A priority Critical patent/AUPS033502A0/en
Priority to AUPS0335 priority
Application filed by Pure Commerce Pty Ltd filed Critical Pure Commerce Pty Ltd
Priority claimed from AU2003202303A external-priority patent/AU2003202303A1/en
Publication of WO2003067535A1 publication Critical patent/WO2003067535A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING; COUNTING
    • G06Q—DATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING; COUNTING
    • G06Q—DATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING; COUNTING
    • G06Q—DATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/342—Cards defining paid or billed services or quantities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING; COUNTING
    • G06Q—DATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/381—Currency conversion
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/02—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices
    • G07F7/025—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices by means, e.g. cards, providing billing information at the time of purchase, e.g. identification of seller or purchaser, quantity of goods delivered or to be delivered

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

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 credit 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 unique 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
PCT/AU2003/000113 2002-02-05 2003-02-05 Transaction processing system WO2003067535A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AUPS0335A AUPS033502A0 (en) 2002-02-05 2002-02-05 Transaction processing system
AUPS0335 2002-02-05

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
AU2003202303A AU2003202303A1 (en) 2002-02-05 2003-02-05 Transaction processing system

Publications (1)

Publication Number Publication Date
WO2003067535A1 true WO2003067535A1 (en) 2003-08-14

Family

ID=3833936

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2003/000113 WO2003067535A1 (en) 2002-02-05 2003-02-05 Transaction processing system

Country Status (2)

Country Link
AU (1) AUPS033502A0 (en)
WO (1) WO2003067535A1 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1579356A2 (en) * 2002-11-07 2005-09-28 Planet Group, Inc. Time-of-transaction foreign currency conversion
WO2007131285A1 (en) * 2006-05-16 2007-11-22 Travelex Outsourcing Pty Limited Transaction system supporting dynamic currency conversion
US20110218914A1 (en) * 2010-03-05 2011-09-08 Marc Rochman Closed loop stored value instrument brokerage system, method and computer program product
US20120036063A1 (en) * 2008-03-10 2012-02-09 Sumithran Sivapathasundram Dynamic currency conversion system and method
US9043225B2 (en) 2012-11-30 2015-05-26 Wal-Mart Stores, Inc. Approximating alternate currency equivalents in digital receipts
US9747599B2 (en) * 2006-03-31 2017-08-29 Mastercard International Incorporated Method and system for identifying and processing currency conversion in a financial transaction
CN109427155A (en) * 2017-08-24 2019-03-05 东芝泰格有限公司 Settlement terminal device and control method, terminal device

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001059727A2 (en) * 2000-02-09 2001-08-16 Internetcash.Com Method and system for making anonymous electronic payments on the world wide web
EP1018711B1 (en) * 1999-07-12 2001-12-05 Mainline Corporate Holdings Limited Dynamic currency conversion for card payment systems
WO2002039395A2 (en) * 2000-11-13 2002-05-16 Francis Enda Murphy Transaction processing and inter-computer communications
GB2369711A (en) * 2000-11-14 2002-06-05 Vcheq Com Pte Ltd An electronic funds transfer system for processing multiple currency transactions
EP1251470A2 (en) * 2001-04-20 2002-10-23 Hitachi, Ltd. International-online automatic cash transaction system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1018711B1 (en) * 1999-07-12 2001-12-05 Mainline Corporate Holdings Limited Dynamic currency conversion for card payment systems
WO2001059727A2 (en) * 2000-02-09 2001-08-16 Internetcash.Com Method and system for making anonymous electronic payments on the world wide web
WO2002039395A2 (en) * 2000-11-13 2002-05-16 Francis Enda Murphy Transaction processing and inter-computer communications
GB2369711A (en) * 2000-11-14 2002-06-05 Vcheq Com Pte Ltd An electronic funds transfer system for processing multiple currency transactions
EP1251470A2 (en) * 2001-04-20 2002-10-23 Hitachi, Ltd. International-online automatic cash transaction system

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1579356A2 (en) * 2002-11-07 2005-09-28 Planet Group, Inc. Time-of-transaction foreign currency conversion
EP1579356A4 (en) * 2002-11-07 2005-12-28 Planet Group Inc Time-of-transaction foreign currency conversion
US7660768B2 (en) 2002-11-07 2010-02-09 Planet Payment, Inc. Time-of-transaction foreign currency conversion
US9747599B2 (en) * 2006-03-31 2017-08-29 Mastercard International Incorporated Method and system for identifying and processing currency conversion in a financial transaction
WO2007131285A1 (en) * 2006-05-16 2007-11-22 Travelex Outsourcing Pty Limited Transaction system supporting dynamic currency conversion
US20120036063A1 (en) * 2008-03-10 2012-02-09 Sumithran Sivapathasundram Dynamic currency conversion system and method
US8849713B2 (en) * 2008-03-10 2014-09-30 Global Blue Currency Choice Holdings B.V. Dynamic currency conversion system and method
US20110218914A1 (en) * 2010-03-05 2011-09-08 Marc Rochman Closed loop stored value instrument brokerage system, method and computer program product
US9043225B2 (en) 2012-11-30 2015-05-26 Wal-Mart Stores, Inc. Approximating alternate currency equivalents in digital receipts
CN109427155A (en) * 2017-08-24 2019-03-05 东芝泰格有限公司 Settlement terminal device and control method, terminal device
EP3457368A1 (en) * 2017-08-24 2019-03-20 Toshiba TEC Kabushiki Kaisha Settlement terminal device and control method of settlement terminal device

Also Published As

Publication number Publication date
AUPS033502A0 (en) 2002-02-28

Similar Documents

Publication Publication Date Title
US20180315102A1 (en) Value processing network and methods
US8924289B1 (en) International banking system and method
CA2872561C (en) Using card image to extract bank account information
US8924294B2 (en) Methods and systems for routing payment transactions
JP5643856B2 (en) Foreign currency conversion at transaction
US8712914B2 (en) Method and system for facilitating micropayments in a financial transaction system
US8781960B2 (en) Computerized method to accept and settle cash transaction payments
US9275410B2 (en) Internet payment system and method
US8799153B2 (en) Systems and methods for appending supplemental payment data to a transaction message
US8814039B2 (en) Methods for processing a payment authorization request utilizing a network of point of sale devices
US8596527B2 (en) Methods for locating a payment system utilizing a point of sale device
US8794509B2 (en) Systems and methods for processing a payment authorization request over disparate payment networks
US7248855B2 (en) Convergent communications system and method with a rule set for authorizing, debiting, settling and recharging a mobile commerce account
US8820633B2 (en) Methods for a third party biller to receive an allocated payment authorization request
US8875990B2 (en) Systems and methods for allocating a payment authorization request to a payment processor
US9129464B2 (en) Staged transactions systems and methods
US8646685B2 (en) Device for allocating a payment authorization request to a payment processor
US8131627B2 (en) Open clearing system
US6424706B1 (en) Method and system for transferring telecommunication-time units among accounts and exchanging same for goods or services
AU2002247375B2 (en) Method and system for making small payments using a payment card
US7912784B2 (en) Methods and systems for processing, accounting, and administration of stored value cards
US7587363B2 (en) System and method for optimized funding of electronic transactions
US7726561B2 (en) System and method for reconciling credit card payments with corresponding transactions
US8032452B2 (en) Multiple-entity transaction systems and methods
US6594647B1 (en) Real time bank-centric universal payment system

Legal Events

Date Code Title Description
AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
WWW Wipo information: withdrawn in national office

Country of ref document: JP

NENP Non-entry into the national phase in:

Ref country code: JP