WO2008117171A1

WO2008117171A1 - Method of determining transaction currency for a card transaction

Info

Publication number: WO2008117171A1
Application number: PCT/IB2008/000737
Authority: WO
Inventors: Sunil Sharma
Original assignee: Pure Commerce Pty Limited
Priority date: 2007-03-28
Filing date: 2008-03-28
Publication date: 2008-10-02
Also published as: NZ554222A

Abstract

A computer implemented method of determining a transaction currency for a card transaction between a cardholder and a merchant, the method including the steps of: a) sending a transaction authorization request over an electronic payment network (53); b) receiving issuer response data in response to the authorization request (54); c) determining a card issuer currency from the response data (55); d) selecting the card issuer currency as the transaction currency (56, 57, 58).

Description

Method of Determining Transaction Currency For a Card Transaction. FIELD OF INVENTION

This invention relates to electronic payment cards including debit and credit cards, and to electronic payment networks that manage electronic transfer of funds between different entities or accounts. The invention has a particular, but not sole, application in processing payment card transactions with currency conversion.

BACKGROUND ART

Payment Card systems are well known. In recent times there has been a move toward offering a financial service to card holders in payment card transactions in which the card holders have the cost of transactions converted to their local currency when making payment in a foreign currency. This service is sometimes referred to as Dynamic Currency Conversion (DCC).

DCC services have a number of advantages, including:

• the visibility of charges made in foreign countries

• the ability to enter expenses more easily (for business travellers)

• a comparable or less expensive fee than the currency conversion rates charged by credit card companies.

Known methods for processing a Payment Card transaction with currency conversion are discussed below. Further information on Card payment systems is provided later in this document.

The normal steps for processing a Payment Card transaction with currency exchange are:

1. Obtain the Payment Card from the Customer.

2. Swipe the Payment Card on the Card Reader to extract the card number (sometimes referred to as the track 2 data). Alternatively enter the Card Number manually.

3. Determine the Card Currency from the Card for a potential exchange transaction. 4a. If the Card is determined to be foreign, convert local amount into foreign amount. 4b. Solicit Customer Choice (whether the customer wants to proceed with the converted amount or to have the transaction proceed in the normal fashion).

5. Process the payment transaction in the chosen currency and print receipt.

Steps 1 , 2 and 5 always occur, regardless of whether currency exchange is involved or not (step 5 defaults to merchant's local currency in this case). With manual currency exchange, steps 3 and 4 are performed manually, and are candidates for computerization. Step 4b, in fact stays manual even after computerization, in the sense that the operator has to prompt the customer to express the choice by pressing a button somewhere. In one attempt of automation of these steps (disclosed in NZ published patent specification 517105) a map of card prefixes vs currency is provided in the hand held terminal along with the Currency versus Conversion Rate. A search through these files must be performed while the transaction is in progress, so that the currency of the card can be determined on the fly, and automatically offer a choice to the customer.

The information relating to card number prefixes or Bank Identification Numbers (BINs), and corresponding currency symbols is generally organized in terms of tables similar to the following :

456789 AUD 432198 GBP

567890 EUR

The above table means that if a card number starts with 456789, it was issued by an Australian Bank, so a transaction currency choice of Australian Dollars should be offered. Similarly, if the card number starts with 432198, the choice should be offered in British Pounds, and if it starts with 567890, in Euros, and so on and so forth. Card Schemes often issue entire ranges of BINs to large banks. For example, all BINs in the range 432198 to 432210 might belong to a single British bank. So rather than having 13 consecutive entries for GBP, a table can have a single range entry as follows :

456789 AUD 432198-210 GBP

567890 EUR

This table, with mixed single entries and range entries is more efficient than the previous table in terms of saving in storage space and speed of search.

In view of the fact that there are hundreds of thousands of such entries to be loaded on a point of sale terminal, a lot of memory space must be reserved for it. In view of the fact that these entries have to be searched through while a transaction is in progress, substantial computing power is required to ensure there is no latency in the progress of the transaction. While these issues are not very important on high powered server and desktop machines with memory space running into gigabytes, and processor speeds running into several gigahertz, they become important issues for standard hand held terminals routinely seen in shopping malls.

A variety of techniques are commonly employed. The known technique of using BIN ranges accomplishes a saving in memory space and enhanced speed of execution, but only up to a point. Most hand-held devices currently in use have got only a few megabytes of memory to accommodate all of program and information files. BIN files have grown rapidly in recent years and don't fit into standard devices anymore, even with range optimization included. Locating these files on remote server machines on the network is one option, but this has its own problems. Payment Terminals are usually linked up with Payment Networks using dial-up networking. They dial into the acquirer host on the payment network every time a new transaction is requested and then hang up. If BIN and Exchange Rate files were to be located on the network as well, the terminal will need to dial twice, once into the Currency Exchange Service Provider, for the currency exchange steps (steps 3 and 4a above), and then into the Acquirer Network for Authorization. This will cause unacceptable latency, and would be an unacceptable solution.

OBJECT OF THE INVENTION

It is an object of the present invention to provide a card transaction method or system which at least provides a useful alternative to existing transaction methods or systems.

Alternatively, it is an object of the invention to provide an improved dynamic currency conversion (DCC) method or system.

BRIEF SUMMARY OF THE INVENTION

Accordingly in one aspect the invention consists in a computer implemented method of determining a transaction currency for a card transaction between a card holder and a merchant, the method including the steps of:

a) sending a transaction authorization request over an electronic payment network;

b) receiving issuer response data in response to the authorization request;

c) determining a card issuer currency from the response data;

d) selecting the card issuer currency as the transaction currency;

Preferably the step of determining a card issuer currency includes the steps of searching the response data for a plurality of predetermined fields and retrieving data relating to one or more of the fields.

Preferably the method includes the step of allowing the cardholder to confirm the transaction currency. Preferably the method includes the step of providing the cardholder with an opportunity to instead proceed with the transaction in the currency of the merchant after the card issuer currency has been selected as the transaction currency.

Preferably the method includes the step of providing the transaction amount to the customer in the transaction currency prior to completion of the transaction.

Preferably the method includes the step of using an exchange rate to calculate a transaction amount in the transaction currency, and providing the transaction amount to the customer prior to completion of the transaction.

In a further aspect the invention broadly consists in a system for determining a transaction currency for a card transaction between a cardholder and merchant, the system including one or more processors programmed and operable to perform the method as set forth in any one o the preceding statements.

Further aspects of the invention will become apparent from the following description.

DRAWING DESCRIPTION

One of more embodiments of the invention will be described below with reference to the accompanying drawings. The drawings referred to on this document may be briefly described as follows:

Figure 1 is a front view of a credit card

Figure 2 is a rear view of a card of Figure 1

Figure 3 is a perspective view of a card payment terminal

Figure 4 is a schematic diagram of a Global Payment Network, and

Figure 5 is a flow chart illustrating operation of the present invention. DETAILED DESCRIPTION

Payment Cards

Payment Cards of the type shown in Figures 1 and 2 are well known. They are an embodiment of electronic money, the money which a person already has (Debit Cards) or the money a person borrows (Credit Cards). A typical credit card is shown in Figure 1 (front view) and Figure 2 (rear view).

Payment Terminals

A typical Payment Terminal is shown in Figure 3. It has a mechanism 2 that allows the Payment Card to be swiped, so the Card information can be read into the processing centre of the computer that this device enshrines. It also has a number pad 3, so that a user can key-in the PIN number as a security check, and some other buttons to facilitate the progression and management of payment transactions. All these buttons, together with the card swiping mechanism represent the "Input" of the Payment Terminal, not quite unlike the Keyboard and Mouse of a personal Computer. There is a small LCD screen 4 built into this device for displaying essential messages. This screen represents the Output" of the Payment Terminal, again not quite unlike the screen of a personal Computer. Apart from the Power Cable, this terminal device has another electric cable emanating somewhere from it, this is the "Wire". All communication with the Acquirer occurs via this Wire. Modern Payment Terminals can communicate wirelessly, the Radio Link being the invisible "Wire".

In this document a Payment Terminal is not limited to a device having the physical appearance of the device shown in the picture. Any programmable computing device that has necessary Input, Output and remote communication mechanism, passes security requirements, and is approved by the Acquiring Bank or Acquiring Network (Acquirer, please see below) will constitute a Payment Terminal.

Track 2

The information related to the card is stored in a series of magnetic tracks on the magnetic stripe behind the card, not quite unlike you store music on cassettes, albeit digitally. Of them, Track 2 is most important from transaction processing point of view. This is how the data on a typical Track 2 on a Payment Card appears :

4123456789987654=09091010000030600000?

The portion in front of the "=" represents card number, "=" is just a delineator, 0909 represents the expiry date of the card (September 2009). The train of digits behind is security information required by bank to verify its authenticity.

At the commencement of a transaction, when the Card is swiped, the entire track 2 information is read into the memory of the computer, and Card Number and Expiry Date are extracted from it and some validation checks are run. This always happens, without exception. The Card Number is available in the Payment Terminal Computer at this point of time, and the programmer can do whatever he or she wants with it.

Merchant

Merchant, in the context of Payment Card Business represents the agency that accepts Payment Card as a mode of making payments, and has the means to handle such payments.

Acquirer

Payment Cards are issued and accepted globally. The merchant needs a local agency to handle all types of Cards, regardless of their origin. They need a single agency to settle with them all their transactions. This role is filled by an Acquirer, typically a Bank. The Merchant's Payment Terminal connects electronically with the local Acquirer, and pushes all the Card Transactions into the Acquirer's Payment Network for Authorization and subsequent Settlement (see below).

Issuer

An Issuer is a Card Scheme member, typically a Bank, that sells or issues Payment Cards to individual customers. Card Schemes

Card Schemes like MasterCard and VISA are well known. They are responsible for creation of various schemes, specifications, processing networks, management of transaction operations, settlement of funds between different parties, enforcement of policies and procedures etc. They motivate Banks and other financial businesses to become their members and sell Payment Cards branded by them.

To ensure uniqueness of a Card Number at a global level, Card Schemes divide the total available set of numbers into different ranges or intervals, and allow members to issue card numbers within those intervals only. It is the issuing member's responsibility to ensure uniqueness within its own range. Typically a Credit Card Scheme would use the most significant 6 digits (i.e. the first 6 digits of the card number) to manage allocation between its members, and leave the rest of the digits for the members to manage themselves. The six digit number, representing the most significant six digits of a payment card is called Bank Information Number or BIN. Card Schemes have been pre-allocated the first couple of digits, and they have to manage their BINs subject to this constraint. Thus VISA cards must begin with first two digits between 40 and 49, a MasterCard must begin with first two digits between 51 and 55. This still leaves the Card Schemes with tens of thousands of BINs for allocation amongst their members, and hundreds of thousands or millions of numbers are available against each BIN for allocation to Payment Card Holders.

Card Schemes regularly (typically annually) compile a directory of information about all the member Banks and distribute it among them. These directories contain complete information about the name, location, contact details and allocated BINs for various members. BINs are always country specific and this is the rule. While a multinational bank may be issued multiple BINs for use in a particular country, it may not use a particular BIN in multiple countries.

ISO 8583

ISO 8583 is the message exchange protocol that drives or underlies virtually all Payment Networks in the world. This protocol specifies exactly what kinds of transactions are possible, the parameters that need to be exchanged between various parties, and how they should be formatted. The following refers to the 2003 edition of ISO 8583, from the Annex F, "Summary of Changes made to ISO8583:1993". It is apparent that it holds good for 1993 edition, and possibly for earlier editions, although the article numbers might be different.

Article 6.2.3 of ISO 8583 - this code specifies that the Amount shall be expressed in the Currency of the associated Currency Code element. Article 6.2.4 specifies how Conversion Rate element should be specified. It is because of the presence of these fields that ISO 8583 based networks have always been capable of doing Multi-Currency transactions. This is the reason why it has always been possible to do Currency Exchange with Payment Card transactions using this standard, even if manually.

Acquirers don't always implement the entire specification on their local networks, primarily for economic reasons. However, in choosing their subset for implementation, they need to understand the entire specification to make sure the interface with the external global Card Scheme Network doesn't break down. Each and every single item has to be thoroughly analysed before inclusion or exclusion excluding in the local specification to make sure mandatory items don't get left out for Global interfacing.

Electronic Payment Network

A schematic organization (simplified version), of a Global Payment Network is shown Figure 4. Payment Terminals 20 and ATMs 21 owned or licensed by banks are linked up with the Bank's processing Centre 24 via phone lines, or wirelessly as shown in the Figure. The Bank's Processing Centre links up with Card Scheme Networks 26 via computers called Routing Hosts 25. The Card Scheme Networks shown in Figure 4 (as clouds) are typically collections of thousands of such Routing Hosts. These Routing Hosts contain BIN versus Issuer mappings, so that they can send different transactions to appropriate Issuers e.g. issuing Bank A, issuing Bank B (refer to the other end of cloud in Figure 4, near the bottom). Once a transaction hits the Issuer Host, it is authorized there, and the result is sent back (via the Card Scheme network).

The collection of all Payment Terminals and ATMs linked up with a Bank constitute the Bank's Local Network. Three such networks are shown in Figure 4. These networks link up with the Global Card Schemes Network via Routing Hosts as shown. Sometimes Banks team up to create a joint local network, and joint interface with the Global Network, one example being ETSL (Electronic Transactions Services Limited) in New Zealand.

Authorization and Settlement

Authorization is the process whereby a transaction request is sent to the Card Issuer, and an approval received. The idea is to establish availability of funds in the Payment card account. It may be followed by a Settlement request which results in the Card Holder account getting debited. The Equivalent amount is paid by the Issuer to the Card schemes, who pay it to the Acquirer who in turn pays it to the Merchant. The Card Holder sees this debit in her (typically) monthly bill from the Card Issuer.

How a standard Payment Card Transaction progresses

A standard payment card transaction progresses as follows:

The Card is swiped at the Payment Terminal and Card Number and Expiry are entered into Terminal's processing area. If the magnetic stripe of the Card is worn out, or the terminal swiper doesn't work, the Card Number and Expiry Date can be keyed into the Terminal.

The amount of transaction is entered into the Terminal.

The Terminal casts the transaction information into requisite format and sends it to the Acquirer.

The Acquirer Host looks at the Card information, and determines the Card Scheme (as mentioned before, the first two digits of the card number contain this information).

The Acquirer Host pushes the transaction into the Card Scheme Network.

The Routing Host in the Scheme's Network looks at the BIN of the Card Number, and identifies the Issuer of the Card (as noted before, since BINs are country specific, this identification embodies the country specific branch of the Issuer, for example Citibank Hong Kong, or Citibank Australia etc, not just Citibank).

The Card Scheme Network sends the transaction to the Issuer Host.

The Issuer Host checks to see if funds are available, and if "yes", approves the transaction.

The Issuer Host sends the result of the transaction to Card Scheme Network, which in turn sends it to the Acquirer Host, and it eventually reaches the Merchant payment Terminal.

The transaction result displays on the terminal, and the transaction receipt prints. The customer is asked to sign it as a means of authentication, unless he entered some kind of PIN number in the course of the transaction.

Electronic Payment Networks

Electronic Payment Networks, from a computer perspective, link up and represent collections of a range of (human) user interface devices like EFTPOS devices, Automatic Teller Machine (ATMs), Web Payment Pages etc with transaction processing and accounting systems of Payment Card Schemes like Visa and MasterCard and Banks like American Express or Bank of New Zealand. The afore-mentioned human interface devices are collectively called Terminal Devices.

Terminal Devices could be real, as in case of ATMs which need to dispense cash, or virtual, like Web Payment Pages. This distinction arises from the fact that for real devices, the terminal transaction management hardware and software is located locally, whereas for virtual devices, it is elsewhere on the network. A Terminal Device may have features from both varieties wherein part of the terminal side of transaction computing occurs on the device, the rest occurs elsewhere on the network (background devices). As noted above most real Terminal Devices (on Electronic Payment Networks), regardless of size, shape and appearance, and background devices, are programmable electronic computers. Similarly most Virtual Terminal Devices are driven remotely by programmable electronic computers. The terminal devices manage human user interaction and electronic communications to capture all the information required for processing a transaction, send this information electronically to the card scheme or bank's accounting system, and convey the result to the human user at the end of the transaction.

Preferred Embodiments of the Present Invention

The present invention does not require BIN or similar information to be stored in or at the hand held terminal, or be specifically retrieved by a request separate from the usual transaction process. Instead, a new method is provided which makes use of the standard information provided by the electronic payment system network, or card scheme network, in response to a standard transaction authorization request. This new method greatly simplifies the process and reduces the resources required by the hand held terminal.

Referring to Figure 5, the present invention proposes the following process flow.

The process begins at step 50. Track 2 data is obtained from the card through a card swipe operation for example in step 51 (or by simply keying in the card number and/or other information), and the merchant begins to process the transaction in step 52. Then, in step 53, rather than requesting authorization at a later time, a conventional transaction authorization request is now sent to the electronic payment system network as described above.

In accordance with standard transaction procedure, the payment network responds to the authorization request in step 54 with an issuer response packet containing data derived from the card issuer. This packet contains information sufficient to authorize (or decline) the transaction, and also contains further information that typically includes one or more of the following: Country names, telephone numbers, card issuer currency.

Therefore, from this information, the "home" currency of the card can be determined directly or indirectly in step 55 as the data returned in the response packet includes currency or geographic information relating to the card. For example if the issuer currency is returned in the issuer response packet, then the currency is known directly. If the telephone number is returned, then the leading digit(s) will also indicate the currency. Thus the data in the issuer response packet is analysed or searched to locate fields which indicate the country (or actual currency) of the card issuer. The data from one or more of those fields is then used to make a determination of the card issuer currency i.e. the "home currency" of the card. For example, in the case of a telephone number being returned in the response packet, the currency determination can be made by comparing the leading digits of the telephone number with international telephone dialing prefixes tabulated or mapped to a related country code. The country code can in turn be used to directly identify the appropriate currency. As another example, if a country name is returned, then this can be compared with a table of country names that relates the names to a country (or directly to a currency) code.

The data that is returned in the response packet can be identified as to whether it represents a telephone number, country name, address, or currency for example by field identifiers in the packet.

In step 56, the issuer currency as determined in the preceding step is compared with the currency of the merchant. If it is the same, then the transaction is processed in the currency of the merchant (step 57). If the issuer currency is not the same as the merchant's currency, then the card holder is offered the option of allowing the transaction to proceed in the issuer currency in step 58. Alternatively, if the issuer currency is not the same as the merchant's currency, then the transaction automatically proceeds in the determined issuer currency.

It should be noted that various changes and modifications to the presently preferred embodiments described herein will be apparent to those skilled in the art. Such changes and modifications may be made without departing from the spirit and scope of the present invention as set forth in the accompanying claims and without diminishing its attendant advantages. It is, therefore, intended that such changes and modifications be included within the present invention.

Claims

1. A computer implemented method of determining a transaction currency for a card transaction between a cardholder and a merchant, the method including the steps of:

b) receiving issuer response data in response to the authorization request;

c) determining a card issuer currency from the response data;

d) selecting the card issuer currency as the transaction currency.

2. A computer implemented method as claimed in claim 1 wherein the step of determining a card issuer currency includes the steps of searching the response data for a plurality of predetermined fields and retrieving data relating to one or more of the fields.

3. A computer implemented method as claimed in any one of the preceding claims including the step of allowing the cardholder to confirm the transaction currency.

4. A computer implemented method as claimed any of the preceding claims including the step of providing the cardholder with an opportunity to instead proceed with the transaction in the currency of the merchant after the card issuer currency has been selected as the transaction currency.

5. A computer implemented method as claimed in any one of the preceding claims including the step of providing the transaction amount to the customer in the transaction currency prior to completion of the transaction.

6. A computer implemented method as claimed in claim 5 including the step of using an exchange rate to calculate a transaction amount in the transaction currency, and providing the transaction amount to the customer prior to completion of the transaction.

7. A system for determining a transaction currency for a card transaction between a cardholder and merchant, the system including one or more processors programmed and operable to perform the method as set forth in any one of the preceding claims.

8. A computer implemented method of determining a transaction currency for a card transaction between a card holder and a merchant substantially as herein described with reference to Figure 10.

9. A system for determining a transaction currency for a card transaction between a cardholder and merchant substantially as herein described.