CA2494549A1 - Methods and systems for effecting payment card transactions - Google Patents
Methods and systems for effecting payment card transactions Download PDFInfo
- Publication number
- CA2494549A1 CA2494549A1 CA002494549A CA2494549A CA2494549A1 CA 2494549 A1 CA2494549 A1 CA 2494549A1 CA 002494549 A CA002494549 A CA 002494549A CA 2494549 A CA2494549 A CA 2494549A CA 2494549 A1 CA2494549 A1 CA 2494549A1
- Authority
- CA
- Canada
- Prior art keywords
- transaction
- merchant
- payment card
- currency
- transaction record
- Prior art date
- Legal status (The legal status 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 status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY 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 OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY 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
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Finance (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Computer Networks & Wireless Communication (AREA)
- Cash Registers Or Receiving Machines (AREA)
Abstract
The present invention relates to card payment systems. In particular, the present invention relates to systems and methods for processing payment card transactions in a dynamic currency conversion and/or multi-currency scheme. To operate correctly, ghost transactions are used. However to prevent duplication of debits against the Card Holder, these "ghost copy" transactions must not be processed into the card schemes with the normal transactions. Thus the Acquirer's and/or third parties host systems have to be amended, in addition to modifications to the related accounting thereof. To overcome this necessity, the present invention provides a method for effecting the performance of a payment card transaction for a first transaction amount in a first currency, between a first merchant and a first payment card holder, the method comprising the steps of a)creating a first payment card transaction record between the first merchant and a second cardholder for the first transaction amount, b) creating a second payment card transaction record between a second merchant and the first cardholder, wherein the second transaction record identifies a second transaction amount in a second currency which equates to the first transaction amount converted into the second currency, and submitting the first transaction record and the second transaction record for processing as payment card transactions.
Description
Title METHODS AND SYSTEMS FOR EFFECTING PAYMENT CARD
TRANSACTIONS
Field of the Invention The present invention relates to card payment systems. In particular, the present invention relates to systems and methods for processing payment card transactions in a dynamic currency conversion and/or multi-currency scheme.
Background to the Invention Several types of card payment systems are available, examples of which include credit cards, charge cards and debit cards. In general, transactions involving a card payment are conducted in the currency of the merchant. Thus, if an Irish credit card is used for a purchase in the USA, the currency of the transaction will probably be in US$.
The transaction value will subsequently be converted into an equivalent EURO
value by the credit card holder's bank but is unknown at the point of sale. This equivalent EURO
value will subsequently appear on the credit card holder's statement. This restriction can be inconvenient for cardholders travelling abroad, as they are unsure of the exact value of the transaction in their own currency at the point and time of sale.
Dynamic currency conversion overcomes these limitations by performing the currency conversion at the point of sale at the time the customer makes a purchase using their payment card. An example of a dynamic currency conversion system is described .
in WO01/0486. With dynamic currency conversion processes, the cardholder is informed at the point of purchase as to what amount they are paying in the cardholder's own currency, whilst the merchant obtains payment in the merchant's own currency.
This process is possible because the function of converting from the currency of the merchant to the currency of the cardholder is performed at the point of sale terminal rather than in the computer systems of the bank in which the cardholder has their credit card account. In the context of the present application, the term bank refers generally to any financial institution, which offers payment card services and may be taken to include, for example, building societies and credit unions.
In addition to dynamic currency conversion schemes, mufti currency schemes also operate to perform the currency conversion part of the transaction prior to submitting the transaction records to the banks for processing. However, in a mufti currency scheme the conversion process does not necessarily take place at the point or time of sale but is converted subsequently.
Payment card transactions are processed and submitted from the merchants to the financial institutions, or an intermediary, as transaction records. Each transaction has an associated transaction record, containing the details of the transaction.
Before the introduction of dynamic currency conversion in payment card transactions, an extract of a transaction record would have looked something along the lines of the transaction "AO" shown in Figure 1.
The precise fields and formats of fields used may vary from bank to bank. In brief, the data in the fields identifies the date of the transaction, the name of the holder of the payment card, the card number of the payment card, the expiry date of the payment card, the name of the merchant who is performing the transaction, the code of the merchant performing the transaction and the amount of the transaction.
With the introduction of dynamic currency conversion transactions, a number of additional fields are required to be "captured". An extract of an exemplary transaction record in a dynamic currency conversion environment is shown in the transaction "BO"
in figure 2. The additional fields to be captured comprise the converted currency element of the transaction, which may include the converted amount in the currency of the cardholder's payment card account, which the cardholder will see on their statement and the exchange rate used to perform the conversion. The currency of the cardholder may also be required.
Normal transactions (transactions processed in the currency of the merchant only, an example of which is shown in figure 1) are processed conventionally typically through the acquiring bank of the merchant, whereas the dynamic currency conversion transactions may be separated from the normal transactions and may be routed to a dynamic currency conversion system , which may be separate from the acquiring bank, for transmission into the card schemes and which may be settled back to the acquiring bank and/or the merchant via a mufti-currency payment card processing bank or other route. A mufti-currency payment card processing bank is a bank which is capable of processing payment card transactions from merchants in more than one currency.
The separation function may be handled by a POS device dispatching normal and/or converted transactions to a first host and normal and/or converted transactions to another host or hosts. The separation function may also be performed before the POS
device, at the POS device and/or post the POS device by an acquirer and/or 3rd party host, server or switch service and/or any other suitable separation means.
For the purposes of the Acquirer and/or other third parties paying the merchant and/or providing the Merchant with the statement in relation to all merchant transactions (rather than two separate regular payments and/or two separate statements), the normal and dynamic currency conversion transactions need to be amalgamated in some way.
Accordingly, for settlement purposes vis a vis the acquirer to the merchant, and likewise the statement from the acquirer to the merchant and/or for related card scheme merchant service fee charges deducted & payable to the acquirer by the merchant, a "ghost copy"
of the dynamic currency conversion transactions may be incorporated/sent to the Acquirer's or other third parties host. However, to prevent duplication of debits against the Card Holder, these "ghost copy" transactions must not be processed into the card schemes with the normal transactions. Thus the Acquirer's and/or third parties host systems have to be amended, in addition to modifications to the related accounting thereof.
This presents a significant difficulty for acquiring banks interested in using dynamic currency conversion services, as the acquiring banks have to amend their computer systems to deal with the splitting/amalgamation for the purposes of providing a statement to the merchant and payment/settlement to the merchant. To facilitate dynamic currency conversion services, a significant amount of computer code is required to be re-written on the banks' computer systems.
Accordingly, although it appears that a significant number of banks would like to offer dynamic currency conversion payment card facilities, the diversion of computer resources which are frequently scarce and in several cases must be booked years in advance makes the proposition unattractive. Furthermore, the necessity of having to interfere with existing bank computer IT systems/procedures is something that banks are extremely reluctant to risk.
This situation is to be contrasted to the position regarding the software on the payment card terminals located at the merchant locations or even at an intermediate host, where it is relatively easy to have independent resources allocated to amend the software in the payment card terminals or an intermediate host. Any changes to software in either the payment card terminals or at an intermediate host are unlikely to interfere with the operation of the acquiring bank's host computer.
Accordingly, it is an object of the present invention to provide a method to effect the performance of a converted payment card transaction, which obviates the necessity for changes to the acquiring banks' host computer system.
Summary of the Invention Accordingly, a first embodiment of the invention provides a method for effecting the performance of a payment card transaction for a first transaction amount in a first currency, between a first merchant and a first payment card holder, the method comprising the steps of:
a) creating a first payment card transaction record between the first merchant and a second cardholder for the first transaction amount, b) creating a second payment card transaction record between a second merchant and the first cardholder, wherein the second transaction record identifies a second transaction amount in a second currency which equates to the first transaction amount converted into the second currency, and 5 c) submitting the first transaction record and the second transaction record for processing as payment card transactions.
As the first cardholder is effectively replaced by a second cardholder in the first transaction record, the subsequent processing of the second transaction by a dynamic currency conversion operator will not cause a double debit in respect of the first cardholder. Thus the necessity of re-writing an acquirer's software to avoid any such related type double debit is avoided. Similarly, from the perspective of the acquirer and/or its merchant handling of transactions processed for the merchant, the acquirer systems do not have to be amended to introduce and/or receive ghost transactions for the purposes of amalgamation and/or calculating service charges for the merchant.
The second cardholder may be associated with the second merchant.
The step of submitting the first transaction record and the second transaction record for processing may comprise the step of submitting the first transaction record for processing as an unconverted payment transaction. The step of submitting the first transaction record and the second transaction record for processing may comprise the step of submitting the second transaction record for processing as a converted payment transaction.
Optionally, the invention may comprise the additional steps of creating a third payment card transaction record between the second cardholder and the second merchant for an amount in the first currency, which is the negative equivalent of the first amount and submitting the third transaction for payment processing. The third transaction may be submitted as an unconverted payment card transaction.
The advantage of this third transaction record is that it effectively cancels out the first transaction record vis a vis the second cardholder. Thus there is no need to correct the balances on the account of the second cardholder.
The method may comprise the initial step of determining whether a transaction is a dynamic currency convertible transaction prior to performing the steps of creating the one or more transaction records.
The method may comprise the initial step of receiving an indication of a payment card transaction for a first transaction amount in a first currency between a first merchant and a first payment card holder.
The method may comprise the step of posting the first and/or second and/or third transactions to the computer system associated with an acquiring bank.
The invention also provides a system adapted to effect the performance of a payment card transaction, the system comprising means for receiving details of a transaction for a first transaction amount in a first currency, between a first merchant and a first payment card holder, means for creating a first payment card transaction record between the first merchant and a second cardholder for the first transaction amount, means for creating a second payment caxd transaction record between a second merchant and the first cardholder, wherein the second transaction record identifies a second transaction amount in a second currency which equates to the first transaction amount converted into the second currency, and means for submitting created transaction records to a host for processing as payment card transactions.
The means for submitting created transaction records may be suitably adapted to submit the first transaction record for processing as an unconverted payment transaction.
The means for submitting created transaction records may be suitably adapted to submit the second transaction record for processing as a converted payment transaction.
Optionally, the system may comprise means for creating a third payment card transaction record between the second cardholder and the second merchant for an amount in the first currency, which is the negative equivalent of the first amount and submitting the third transaction for payment processing. The means for submitting created transaction records may be suitably adapted to submit the third transaction record for processing as an unconverted payment transaction.
The system may comprise means for determining whether a transaction is a dynamic currency convertible transaction prior to performing the steps of creating the one or more transaction records.
In one embodiment the system comprises a payment card terminal. In this embodiment, the means for receiving details of the transaction for a first transaction amount in a first currency comprises the data entry means of the terminal, including for example smart card readers, magnetic strip readers and keypads. The means for receiving details may include means for retrieving the details of the merchant from the terminal memory. In a terminal, the means for creating the first and second payment transaction records may be implemented using appropriate software routines.
The details for the second merchant and cardholder may suitably be stored in the terminal memory and retrieved by the means for creating the first and second payment transaction records as required when creating first and second payment transaction records.
In one embodiment the system comprises an intermediate host computer system adapted to receive payment transaction records from a payment card terminal or other device and route them for processing as either converted or unconverted transactions. In this embodiment, the means for receiving details of the transaction comprises means for receiving transaction records. The means for creating the first payment caxd transaction record and the means for creating the second payment card transaction may be implemented as software routines. The host may be an acquirer's host, a mufti-currency bank's host, an intermediate host or any other host. Moreover an acquirer and/or a multi-currency bank may be one and the same person or entirely separate, i.e. in the acquirer and multi-currency (and/or its/their host) may be one entity, two independent entities within the same bank or two separate banks.
Other advantageous embodiments will be appreciated from the claims and description which follow.
Brief Description of the Drawings The invention will now be described in greater detail with reference to the accompanying drawings in which:
Figure 1 is an example of a transaction record according to the prior art, Figure 2 is an example of a second transaction record known from the prior art, Figure 3 is a block diagram representation of a system suitable for implementing the present invention, Figure 4 is a flowchart of a method according to the present invention, Figure 5 is an example of a first transaction according to the present invention, Figure 6 is an example of a second transaction according to the present invention, and Figure 7a is an example of a third transaction according to the present invention, and Figure 7b is an example of a transaction where the two merchant numbers are not the same.
Detailed Description of the Drawings The present invention is intended for use within a card payment system, and in particular for use with converted transactions. An exemplary scheme, illustrated in Figure 3, comprises a number of POS (point of sale) terminal devices 1. The Terminal devices 1 are adapted to perform payment card transactions. Each device is associated with a merchant. In the exemplary configuration shown, an intermediate host 2 acts as an interface between the POS devices and the payment processing systems of the banks and currency conversion schemes.
Payment card transactions are conventionally initiated by a cardholder presenting a payment card at the point of sale at the time of making a purchase. The merchant operating the POS device conventionally swipes the payment card through a magnetic strip reader on a POS device, and then enters the amount of the transaction using a keypad. Other methods of performing card transactions, e.g. by telephone or the Internet, are well known in the art. The exact manner of entering the payment card details and the transaction details are unimportant in the context of the present invention.
The individual payment card transactions may be either a conventional (unconverted) transaction or a converted transaction. In a conventional transaction, the transaction is performed in the currency of the merchant. In a conventional transaction, if the cardholder's account operates in a different currency to that of the merchant, the cardholder's bank performs a conversion into the currency of the cardholder's account at the time of posting the transaction to their account. This conversion generally takes place some time, even days, after the initial transaction has been completed.
Conventional transactions are to be contrasted to converted transactions, where the transaction amount is converted into the currency of the cardholder's payment card account prior to submission of the transaction to the banks for processing. An example of a converted transaction is a dynamic currency converted transaction. An example of a dynamic currency conversion system is described in W001/0486.
In the exemplary scheme shown, each of the POS devices 1 is adapted to handle conventional and/or converted payment card transactions. For each transaction conducted on a POS device, a transaction record is created and stored on the POS
device.
An exemplary conventional transaction record 100 is shown in figure 1. The transaction record identifies the date of the transaction 3, the name of the cardholder 4, the card number of the cardholder 5, the expiry date of the card 6, the name of the merchant 7, the merchant code 8 and the transaction amount 9. The transaction record may include other information and fields.
An exemplary converted transaction 200 is shown in figure 2.Fields that are the same as those fields described previously for a conventional transaction are given the same reference numerals. The converted transaction has a number of fields corresponding to the fields contained in a conventional transaction, such as the name of the cardholder 4, the card number of the cardholder 5, the expiry date of the card 6, the name of the merchant 7, the merchant code ~ and the transaction amount 9 etc.
The converted transaction record may also include other information and fields 10 present in conventional transaction records. In addition, to these fields the converted transaction record contains data in a number of additional fields, which identify the transaction as being a converted transaction. These fields may include a field to store the transaction amount in the currency of the cardholder 11 and/or a field to store the exchange rate used in the conversion 10. Other fields that may be provided include a currency identifier field for identifying the currency of the cardholder.
It will be appreciated that the same field structure may be used for converted and unconverted transactions with an identifier or other means used to distinguish between the two types of transaction. For example, a conventional transaction could be distinguished from a converted transaction by the absence of data (or the presence of null values) in fields relating to converted transactions, e.g. the converted amount field or exchange rate field.
The individual transaction records are uploaded to the intermediate host 2, for example as a batch process at the end of each day or at any time during or at the end of the transaction creation and capture cycle.
To facilitate the uploading of transaction records, the POS devices 1 are suitably adapted to communicate with the intermediate host using appropriate communication means, typically by modem over a telephone line.
The intermediate host 2 is adapted to receive the transaction records from the POS devices 1 and to process. The intermediate host 2 subsequently forwards the transaction records onto the computer systems associated with acquiring banks, which are ultimately responsible for the processing of the payment card transactions.
Upon receipt of the individual transaction records, the intermediate host 2 may perform some checks and verification routines to ensure the accuracy of the records submitted. The intermediate host 2 may then separate the converted transactions from the conventional transactions. The conventional transactions are forwarded for processing in accordance with the methods of the prior art to the merchant's acquiring bank 12, which in turn forwards the transaction to the payment card schemes 13. The card payment schemes 13 ensure that the correct charges are applied to appropriate cardholders' accounts.
In the prior art, the converted transactions were forwarded directly to the currency conversion scheme 14 or an associate of the currency conversion scheme to facilitate transactions to be processed through a mufti-currency bank 15. The multi-currency bank 15 in turn forwards the transactions to the payment card schemes 13., who in turn apply the charges to appropriate cardholder's accounts.
In the present invention, an exemplary implementation of which is shown in Figure 4, a number of new transaction records are created from each convertible transaction record generated from a POS device, and at least one of these new transaction records is submitted for processing to the merchant's acquiring bank.
The exemplary method, illustrated in Figure 4, will now be described with reference to the exemplary converted transaction record 200 shown in Figure 2, which identifies a record for a converted payment card transaction between a merchant and a cardholder for an amount. This converted payment card transaction record may be received by a host from the POS device of the merchant.
Once the convertible payment card transaction record is received by a host 400, the host commences generating a number of payment transaction records.
In particular, a first transaction record is created 401 between the merchant and a second cardholder for the same amount as the received transaction record.
This first transaction record identifies an unconverted transaction between the merchant and a second cardholder. An exemplary resulting first transaction record 500 is shown in Figure S. This newly created first transaction record may be created by amending the received record.
The second cardholder identified in the first transaction record 500 is a cardholder account or pseudo cardholder of an intermediary possibly for example the operator or an associate of the operator of the currency conversion scheme.
Thus the resulting transaction created, effectively creates a debit from the intermediary cardholder to the merchant. This first transaction may subsequently be submitted to the acquiring bank 12 of the merchant for payment processing in the same way as the conventional (unconverted) transaction records. A record will thus exist in the acquiring bank 12 of the merchant showing a credit to the merchant's account. This credit will appear as a conventional payment card transaction between the merchant and a second cardholder (which in the present example is the operator or an associate thereof of the currency conversion scheme).
Accordingly, charges, reports and calculations for the merchant may be performed without any requirement for alteration of the software of the acquiring banks or the posting and subsequent removing or "fixing" of ghost transactions.
In addition, to the creation of the first transaction record 500, a host creates 402 a second transaction record, illustrated for example in Figure 6. This second transaction record 600 identifies a transaction between a second merchant and the first cardholder.
In the present example, the second merchant is a merchant account associated with the intermediary, which may for example be the operator or an associate of the operator of the currency conversion scheme. The second transaction record 600 is a converted transaction record and thus contains a second transaction amount in a second currency (that of the cardholder) equating to the first transaction amount converted into the second currency. Thus, a payment card transaction is effectively created which credits an intermediary or pseudo merchant, possibly, for example, an operator or an associate of the operator of the currency conversion scheme, and debits the cardholder.
This second transaction record 600 may be submitted for payment processing, as in the prior art, to the currency conversion scheme 14 for onward submission via a multi-currency bank 15 and subsequently the card schemes 13.
As the cardholder is effectively replaced by a second (intermediary) cardholder in the first transaction record, the subsequent processing of the second transaction by a dynamic currency conversion will not cause a double debit in respect of the first cardholder. Thus the necessity of re-writing an acquirer's software to avoid any such related double debit is avoided. Similarly, from the perspective of the acquirer and/or its merchant handling of transactions processed for the merchant, the acquirer systems do not have to be amended to introduce, cater and/or receive ghost transactions for the purposes of amalgamation and/or calculating service charges for the merchant.
The above described method in effect creates two transactions, the net result of which is a debit from the cardholder and a credit to the merchant, with a third party acting as an intermediary and having a merchant account and a cardholder account.
It will be appreciated that the merchant account of the intermediary will accumulate funds (credit), whilst the cardholder account of the intermediary will be debited. To prevent inconsistencies arising in the operation of the acquiring banks systems, it may be necessary to offset the balances in the intermediary's merchant account against those in the intermediaries cardholder account. This could for example be implemented using a daily transfer from the intermediary's merchant account to the intermediary's cardholder account. Such a transfer could be implemented at the end of each day for the outstanding account balance as a payment card transaction between the intermediaries cardholder and the intermediaries merchant account, in effect a refund.
Another approach is to effectively perform a transfer between the intermediary's merchant account and the intermediary's cardholder account for each converted transaction. Thus, in addition, to the creation of the two transaction records described above, a third transaction 700 may be created 403 as shown by example in Figure 7.
This transaction represents a conventional payment card transaction between the intermediary's merchant account and the intermediary's cardholder account.
This third transaction 700 may be submitted, for example to the merchant's acquiring bank for processing 404. As shown in Figure 7b the merchant numbers need not be the same in this invention. In other words the pseudo merchant should be one and the same, but not the merchant number.
Although the present invention has been described with reference to an intermediate host, it.will be appreciated that the crux of the present invention is the conversion of a single payment card transaction into two or more separate payment card transactions (as appropriate) using an intermediary as the join between the two or more separate transactions. It will further be appreciated that this concept may be applied in a number of different ways to achieve the desired end result. For example, the splitting into two or more transactions may be performed at the POS terminal, the intermediate host or a combination of the two Although dynamic currency conversion offers significant advantages to foreign customers of merchants, some merchants nonetheless receive a portion of the resultant additional revenue in handling dynamic currency converted transactions.
Accordingly, there is a general need to settle merchants additional revenue based on the value of dynamic currency transactions conducted. Similarly, the multi-currency banleing partner member card scheme processor (MBPMCSP) which is responsible for processing the mufti-currency payment transactions into the payment card systems generally charges an additional fees for the extra work required in processing a mufti-currency transaction as compared to a conventional unconverted transaction.
It will thus be appreciated that for any one transaction there are a number of settlement measures required to ensure that the requisite funds are distributed appropriately and that appropriate balances occur. The present invention may be modified by the inclusion of one or more further payment card transactions to achieve one or more of these objectives as described below.
In particular, to settle individual merchants their proportion (where applicable) of any additional revenue in handling dynamic currency converted transactions, a further 10 transaction record may be created. The amount of this further transaction, herein after referred to as a merchant additional revenue card transaction, would represent the additional revenue to be settled to the merchant. The merchant additional revenue card transaction would be between the second cardholder (described above) or another pseudo cardholder of the operator or an associate of the operator of the currency 15 conversion scheme and the first merchant. For convenience, the individual additional revenue to be settled to a merchant may be amalgamated into a single merchant additional revenue card transaction record for example at the end of each day, week or month. The merchant additional revenue card transaction record may be posted for processing by the card schemes as a conventional card transaction. A less preferred alternative method would be for the first merchant to have their own cardholder account to which their additional revenue may be settled as described above as a refund from the second merchant or an associated merchant thereof.
Similarly, an additional transaction record may be created to pay the MBPMCSP
their fee for handling the transaction. This transaction, hereinafter referred to as the MBPMCSP transaction, would represent the fee payable to the MBPMCSP. The MBPMCSP transaction may be between the second cardholder (described above) or another pseudo cardholder of the operator or an associate of the operator of the currency conversion scheme and a merchant (account) associated with the MBPMCSP . For convenience, the individual fees payable to the MBPMCSP may be amalgamated into a single MBPMCSP card transaction for example at the end of each day, week or month.
A less preferred alternative method would be for the MBPMCSP to have their own cardholder account to which their fees may be paid as described above as a refund from the second merchant or an associated merchant thereof.
In addition, it is accepted that the primary driving factor for implementing dynamic currency conversion is that the operator of the dynamic currency conversion scheme benefits financially from additional revenue. The presence of additional revenue does however create an imbalance between the various transactions described above.
This may best be explained by way of an example. Consider the case where a nominal ~100 transaction is conducted at a point of sale for a Japanese cardholder.
This transaction may, for example, be quoted to the cardholder at a rate of 119~/~
or ~11,900.
However, when the ~11,900 transaction is processed and returned from the Card Schemes via the MBPMCSP to the dynamic currency conversion scheme operator, it may be converted to say ~103 by the dynamic currency conversion scheme operator. Of this total amount, ~100 is effectively routed to the merchant as payment in respect of the transaction whereas the ~3 additional revenue is routed to/through the dynamic currency conversion scheme operator.
To operate this scheme successfully requires the dynamic currency conversion scheme operator to set up effective ring-fenced accounts in the relevant currencies as well as a further central account in the real merchant's currency, which in the European Eurozone would be the Euro.
Although the above method has been described with respect to the operator of the dynamic currency conversion scheme being associated with the second cardholder account and second merchant account, an alternative approach would be for these accounts to be associated accounts of the MBPMCSP, i.e. for the intermediary accounts to be the MBPMCSP. This may advantageously be employed to cleanly efficiently and effectively delineate the dynamic currency conversion scheme operator additional revenue for the transaction from the substantive transaction. In particular, this may be achieved by reducing the amount of the third transaction 700 (described above) by an amount equating to the additional revenue and creating a further transaction for an amount equating to the additional revenue. This further card transaction would be between the second (intermediate) merchant and a cardholder account associated with the dynamic currency conversion scheme operator. Alternatively, the transaction could be performed as a refund from the cardholder account of the second merchant to a merchant account associated with the dynamic currency conversion scheme operator.
It will be appreciated that a number of suitable combinations of the methods described above are possible and a number of variants may be implemented, with suitable amendment, without deviating from the scope of the present invention.
For example, in one embodiment the intermediary merchant and/or cardholder may represent the same entity but with distinct merchant\cardholder accounts for each.
The words "comprises/comprising" and the words "having/including" when used herein with reference to the present invention are used to specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.
TRANSACTIONS
Field of the Invention The present invention relates to card payment systems. In particular, the present invention relates to systems and methods for processing payment card transactions in a dynamic currency conversion and/or multi-currency scheme.
Background to the Invention Several types of card payment systems are available, examples of which include credit cards, charge cards and debit cards. In general, transactions involving a card payment are conducted in the currency of the merchant. Thus, if an Irish credit card is used for a purchase in the USA, the currency of the transaction will probably be in US$.
The transaction value will subsequently be converted into an equivalent EURO
value by the credit card holder's bank but is unknown at the point of sale. This equivalent EURO
value will subsequently appear on the credit card holder's statement. This restriction can be inconvenient for cardholders travelling abroad, as they are unsure of the exact value of the transaction in their own currency at the point and time of sale.
Dynamic currency conversion overcomes these limitations by performing the currency conversion at the point of sale at the time the customer makes a purchase using their payment card. An example of a dynamic currency conversion system is described .
in WO01/0486. With dynamic currency conversion processes, the cardholder is informed at the point of purchase as to what amount they are paying in the cardholder's own currency, whilst the merchant obtains payment in the merchant's own currency.
This process is possible because the function of converting from the currency of the merchant to the currency of the cardholder is performed at the point of sale terminal rather than in the computer systems of the bank in which the cardholder has their credit card account. In the context of the present application, the term bank refers generally to any financial institution, which offers payment card services and may be taken to include, for example, building societies and credit unions.
In addition to dynamic currency conversion schemes, mufti currency schemes also operate to perform the currency conversion part of the transaction prior to submitting the transaction records to the banks for processing. However, in a mufti currency scheme the conversion process does not necessarily take place at the point or time of sale but is converted subsequently.
Payment card transactions are processed and submitted from the merchants to the financial institutions, or an intermediary, as transaction records. Each transaction has an associated transaction record, containing the details of the transaction.
Before the introduction of dynamic currency conversion in payment card transactions, an extract of a transaction record would have looked something along the lines of the transaction "AO" shown in Figure 1.
The precise fields and formats of fields used may vary from bank to bank. In brief, the data in the fields identifies the date of the transaction, the name of the holder of the payment card, the card number of the payment card, the expiry date of the payment card, the name of the merchant who is performing the transaction, the code of the merchant performing the transaction and the amount of the transaction.
With the introduction of dynamic currency conversion transactions, a number of additional fields are required to be "captured". An extract of an exemplary transaction record in a dynamic currency conversion environment is shown in the transaction "BO"
in figure 2. The additional fields to be captured comprise the converted currency element of the transaction, which may include the converted amount in the currency of the cardholder's payment card account, which the cardholder will see on their statement and the exchange rate used to perform the conversion. The currency of the cardholder may also be required.
Normal transactions (transactions processed in the currency of the merchant only, an example of which is shown in figure 1) are processed conventionally typically through the acquiring bank of the merchant, whereas the dynamic currency conversion transactions may be separated from the normal transactions and may be routed to a dynamic currency conversion system , which may be separate from the acquiring bank, for transmission into the card schemes and which may be settled back to the acquiring bank and/or the merchant via a mufti-currency payment card processing bank or other route. A mufti-currency payment card processing bank is a bank which is capable of processing payment card transactions from merchants in more than one currency.
The separation function may be handled by a POS device dispatching normal and/or converted transactions to a first host and normal and/or converted transactions to another host or hosts. The separation function may also be performed before the POS
device, at the POS device and/or post the POS device by an acquirer and/or 3rd party host, server or switch service and/or any other suitable separation means.
For the purposes of the Acquirer and/or other third parties paying the merchant and/or providing the Merchant with the statement in relation to all merchant transactions (rather than two separate regular payments and/or two separate statements), the normal and dynamic currency conversion transactions need to be amalgamated in some way.
Accordingly, for settlement purposes vis a vis the acquirer to the merchant, and likewise the statement from the acquirer to the merchant and/or for related card scheme merchant service fee charges deducted & payable to the acquirer by the merchant, a "ghost copy"
of the dynamic currency conversion transactions may be incorporated/sent to the Acquirer's or other third parties host. However, to prevent duplication of debits against the Card Holder, these "ghost copy" transactions must not be processed into the card schemes with the normal transactions. Thus the Acquirer's and/or third parties host systems have to be amended, in addition to modifications to the related accounting thereof.
This presents a significant difficulty for acquiring banks interested in using dynamic currency conversion services, as the acquiring banks have to amend their computer systems to deal with the splitting/amalgamation for the purposes of providing a statement to the merchant and payment/settlement to the merchant. To facilitate dynamic currency conversion services, a significant amount of computer code is required to be re-written on the banks' computer systems.
Accordingly, although it appears that a significant number of banks would like to offer dynamic currency conversion payment card facilities, the diversion of computer resources which are frequently scarce and in several cases must be booked years in advance makes the proposition unattractive. Furthermore, the necessity of having to interfere with existing bank computer IT systems/procedures is something that banks are extremely reluctant to risk.
This situation is to be contrasted to the position regarding the software on the payment card terminals located at the merchant locations or even at an intermediate host, where it is relatively easy to have independent resources allocated to amend the software in the payment card terminals or an intermediate host. Any changes to software in either the payment card terminals or at an intermediate host are unlikely to interfere with the operation of the acquiring bank's host computer.
Accordingly, it is an object of the present invention to provide a method to effect the performance of a converted payment card transaction, which obviates the necessity for changes to the acquiring banks' host computer system.
Summary of the Invention Accordingly, a first embodiment of the invention provides a method for effecting the performance of a payment card transaction for a first transaction amount in a first currency, between a first merchant and a first payment card holder, the method comprising the steps of:
a) creating a first payment card transaction record between the first merchant and a second cardholder for the first transaction amount, b) creating a second payment card transaction record between a second merchant and the first cardholder, wherein the second transaction record identifies a second transaction amount in a second currency which equates to the first transaction amount converted into the second currency, and 5 c) submitting the first transaction record and the second transaction record for processing as payment card transactions.
As the first cardholder is effectively replaced by a second cardholder in the first transaction record, the subsequent processing of the second transaction by a dynamic currency conversion operator will not cause a double debit in respect of the first cardholder. Thus the necessity of re-writing an acquirer's software to avoid any such related type double debit is avoided. Similarly, from the perspective of the acquirer and/or its merchant handling of transactions processed for the merchant, the acquirer systems do not have to be amended to introduce and/or receive ghost transactions for the purposes of amalgamation and/or calculating service charges for the merchant.
The second cardholder may be associated with the second merchant.
The step of submitting the first transaction record and the second transaction record for processing may comprise the step of submitting the first transaction record for processing as an unconverted payment transaction. The step of submitting the first transaction record and the second transaction record for processing may comprise the step of submitting the second transaction record for processing as a converted payment transaction.
Optionally, the invention may comprise the additional steps of creating a third payment card transaction record between the second cardholder and the second merchant for an amount in the first currency, which is the negative equivalent of the first amount and submitting the third transaction for payment processing. The third transaction may be submitted as an unconverted payment card transaction.
The advantage of this third transaction record is that it effectively cancels out the first transaction record vis a vis the second cardholder. Thus there is no need to correct the balances on the account of the second cardholder.
The method may comprise the initial step of determining whether a transaction is a dynamic currency convertible transaction prior to performing the steps of creating the one or more transaction records.
The method may comprise the initial step of receiving an indication of a payment card transaction for a first transaction amount in a first currency between a first merchant and a first payment card holder.
The method may comprise the step of posting the first and/or second and/or third transactions to the computer system associated with an acquiring bank.
The invention also provides a system adapted to effect the performance of a payment card transaction, the system comprising means for receiving details of a transaction for a first transaction amount in a first currency, between a first merchant and a first payment card holder, means for creating a first payment card transaction record between the first merchant and a second cardholder for the first transaction amount, means for creating a second payment caxd transaction record between a second merchant and the first cardholder, wherein the second transaction record identifies a second transaction amount in a second currency which equates to the first transaction amount converted into the second currency, and means for submitting created transaction records to a host for processing as payment card transactions.
The means for submitting created transaction records may be suitably adapted to submit the first transaction record for processing as an unconverted payment transaction.
The means for submitting created transaction records may be suitably adapted to submit the second transaction record for processing as a converted payment transaction.
Optionally, the system may comprise means for creating a third payment card transaction record between the second cardholder and the second merchant for an amount in the first currency, which is the negative equivalent of the first amount and submitting the third transaction for payment processing. The means for submitting created transaction records may be suitably adapted to submit the third transaction record for processing as an unconverted payment transaction.
The system may comprise means for determining whether a transaction is a dynamic currency convertible transaction prior to performing the steps of creating the one or more transaction records.
In one embodiment the system comprises a payment card terminal. In this embodiment, the means for receiving details of the transaction for a first transaction amount in a first currency comprises the data entry means of the terminal, including for example smart card readers, magnetic strip readers and keypads. The means for receiving details may include means for retrieving the details of the merchant from the terminal memory. In a terminal, the means for creating the first and second payment transaction records may be implemented using appropriate software routines.
The details for the second merchant and cardholder may suitably be stored in the terminal memory and retrieved by the means for creating the first and second payment transaction records as required when creating first and second payment transaction records.
In one embodiment the system comprises an intermediate host computer system adapted to receive payment transaction records from a payment card terminal or other device and route them for processing as either converted or unconverted transactions. In this embodiment, the means for receiving details of the transaction comprises means for receiving transaction records. The means for creating the first payment caxd transaction record and the means for creating the second payment card transaction may be implemented as software routines. The host may be an acquirer's host, a mufti-currency bank's host, an intermediate host or any other host. Moreover an acquirer and/or a multi-currency bank may be one and the same person or entirely separate, i.e. in the acquirer and multi-currency (and/or its/their host) may be one entity, two independent entities within the same bank or two separate banks.
Other advantageous embodiments will be appreciated from the claims and description which follow.
Brief Description of the Drawings The invention will now be described in greater detail with reference to the accompanying drawings in which:
Figure 1 is an example of a transaction record according to the prior art, Figure 2 is an example of a second transaction record known from the prior art, Figure 3 is a block diagram representation of a system suitable for implementing the present invention, Figure 4 is a flowchart of a method according to the present invention, Figure 5 is an example of a first transaction according to the present invention, Figure 6 is an example of a second transaction according to the present invention, and Figure 7a is an example of a third transaction according to the present invention, and Figure 7b is an example of a transaction where the two merchant numbers are not the same.
Detailed Description of the Drawings The present invention is intended for use within a card payment system, and in particular for use with converted transactions. An exemplary scheme, illustrated in Figure 3, comprises a number of POS (point of sale) terminal devices 1. The Terminal devices 1 are adapted to perform payment card transactions. Each device is associated with a merchant. In the exemplary configuration shown, an intermediate host 2 acts as an interface between the POS devices and the payment processing systems of the banks and currency conversion schemes.
Payment card transactions are conventionally initiated by a cardholder presenting a payment card at the point of sale at the time of making a purchase. The merchant operating the POS device conventionally swipes the payment card through a magnetic strip reader on a POS device, and then enters the amount of the transaction using a keypad. Other methods of performing card transactions, e.g. by telephone or the Internet, are well known in the art. The exact manner of entering the payment card details and the transaction details are unimportant in the context of the present invention.
The individual payment card transactions may be either a conventional (unconverted) transaction or a converted transaction. In a conventional transaction, the transaction is performed in the currency of the merchant. In a conventional transaction, if the cardholder's account operates in a different currency to that of the merchant, the cardholder's bank performs a conversion into the currency of the cardholder's account at the time of posting the transaction to their account. This conversion generally takes place some time, even days, after the initial transaction has been completed.
Conventional transactions are to be contrasted to converted transactions, where the transaction amount is converted into the currency of the cardholder's payment card account prior to submission of the transaction to the banks for processing. An example of a converted transaction is a dynamic currency converted transaction. An example of a dynamic currency conversion system is described in W001/0486.
In the exemplary scheme shown, each of the POS devices 1 is adapted to handle conventional and/or converted payment card transactions. For each transaction conducted on a POS device, a transaction record is created and stored on the POS
device.
An exemplary conventional transaction record 100 is shown in figure 1. The transaction record identifies the date of the transaction 3, the name of the cardholder 4, the card number of the cardholder 5, the expiry date of the card 6, the name of the merchant 7, the merchant code 8 and the transaction amount 9. The transaction record may include other information and fields.
An exemplary converted transaction 200 is shown in figure 2.Fields that are the same as those fields described previously for a conventional transaction are given the same reference numerals. The converted transaction has a number of fields corresponding to the fields contained in a conventional transaction, such as the name of the cardholder 4, the card number of the cardholder 5, the expiry date of the card 6, the name of the merchant 7, the merchant code ~ and the transaction amount 9 etc.
The converted transaction record may also include other information and fields 10 present in conventional transaction records. In addition, to these fields the converted transaction record contains data in a number of additional fields, which identify the transaction as being a converted transaction. These fields may include a field to store the transaction amount in the currency of the cardholder 11 and/or a field to store the exchange rate used in the conversion 10. Other fields that may be provided include a currency identifier field for identifying the currency of the cardholder.
It will be appreciated that the same field structure may be used for converted and unconverted transactions with an identifier or other means used to distinguish between the two types of transaction. For example, a conventional transaction could be distinguished from a converted transaction by the absence of data (or the presence of null values) in fields relating to converted transactions, e.g. the converted amount field or exchange rate field.
The individual transaction records are uploaded to the intermediate host 2, for example as a batch process at the end of each day or at any time during or at the end of the transaction creation and capture cycle.
To facilitate the uploading of transaction records, the POS devices 1 are suitably adapted to communicate with the intermediate host using appropriate communication means, typically by modem over a telephone line.
The intermediate host 2 is adapted to receive the transaction records from the POS devices 1 and to process. The intermediate host 2 subsequently forwards the transaction records onto the computer systems associated with acquiring banks, which are ultimately responsible for the processing of the payment card transactions.
Upon receipt of the individual transaction records, the intermediate host 2 may perform some checks and verification routines to ensure the accuracy of the records submitted. The intermediate host 2 may then separate the converted transactions from the conventional transactions. The conventional transactions are forwarded for processing in accordance with the methods of the prior art to the merchant's acquiring bank 12, which in turn forwards the transaction to the payment card schemes 13. The card payment schemes 13 ensure that the correct charges are applied to appropriate cardholders' accounts.
In the prior art, the converted transactions were forwarded directly to the currency conversion scheme 14 or an associate of the currency conversion scheme to facilitate transactions to be processed through a mufti-currency bank 15. The multi-currency bank 15 in turn forwards the transactions to the payment card schemes 13., who in turn apply the charges to appropriate cardholder's accounts.
In the present invention, an exemplary implementation of which is shown in Figure 4, a number of new transaction records are created from each convertible transaction record generated from a POS device, and at least one of these new transaction records is submitted for processing to the merchant's acquiring bank.
The exemplary method, illustrated in Figure 4, will now be described with reference to the exemplary converted transaction record 200 shown in Figure 2, which identifies a record for a converted payment card transaction between a merchant and a cardholder for an amount. This converted payment card transaction record may be received by a host from the POS device of the merchant.
Once the convertible payment card transaction record is received by a host 400, the host commences generating a number of payment transaction records.
In particular, a first transaction record is created 401 between the merchant and a second cardholder for the same amount as the received transaction record.
This first transaction record identifies an unconverted transaction between the merchant and a second cardholder. An exemplary resulting first transaction record 500 is shown in Figure S. This newly created first transaction record may be created by amending the received record.
The second cardholder identified in the first transaction record 500 is a cardholder account or pseudo cardholder of an intermediary possibly for example the operator or an associate of the operator of the currency conversion scheme.
Thus the resulting transaction created, effectively creates a debit from the intermediary cardholder to the merchant. This first transaction may subsequently be submitted to the acquiring bank 12 of the merchant for payment processing in the same way as the conventional (unconverted) transaction records. A record will thus exist in the acquiring bank 12 of the merchant showing a credit to the merchant's account. This credit will appear as a conventional payment card transaction between the merchant and a second cardholder (which in the present example is the operator or an associate thereof of the currency conversion scheme).
Accordingly, charges, reports and calculations for the merchant may be performed without any requirement for alteration of the software of the acquiring banks or the posting and subsequent removing or "fixing" of ghost transactions.
In addition, to the creation of the first transaction record 500, a host creates 402 a second transaction record, illustrated for example in Figure 6. This second transaction record 600 identifies a transaction between a second merchant and the first cardholder.
In the present example, the second merchant is a merchant account associated with the intermediary, which may for example be the operator or an associate of the operator of the currency conversion scheme. The second transaction record 600 is a converted transaction record and thus contains a second transaction amount in a second currency (that of the cardholder) equating to the first transaction amount converted into the second currency. Thus, a payment card transaction is effectively created which credits an intermediary or pseudo merchant, possibly, for example, an operator or an associate of the operator of the currency conversion scheme, and debits the cardholder.
This second transaction record 600 may be submitted for payment processing, as in the prior art, to the currency conversion scheme 14 for onward submission via a multi-currency bank 15 and subsequently the card schemes 13.
As the cardholder is effectively replaced by a second (intermediary) cardholder in the first transaction record, the subsequent processing of the second transaction by a dynamic currency conversion will not cause a double debit in respect of the first cardholder. Thus the necessity of re-writing an acquirer's software to avoid any such related double debit is avoided. Similarly, from the perspective of the acquirer and/or its merchant handling of transactions processed for the merchant, the acquirer systems do not have to be amended to introduce, cater and/or receive ghost transactions for the purposes of amalgamation and/or calculating service charges for the merchant.
The above described method in effect creates two transactions, the net result of which is a debit from the cardholder and a credit to the merchant, with a third party acting as an intermediary and having a merchant account and a cardholder account.
It will be appreciated that the merchant account of the intermediary will accumulate funds (credit), whilst the cardholder account of the intermediary will be debited. To prevent inconsistencies arising in the operation of the acquiring banks systems, it may be necessary to offset the balances in the intermediary's merchant account against those in the intermediaries cardholder account. This could for example be implemented using a daily transfer from the intermediary's merchant account to the intermediary's cardholder account. Such a transfer could be implemented at the end of each day for the outstanding account balance as a payment card transaction between the intermediaries cardholder and the intermediaries merchant account, in effect a refund.
Another approach is to effectively perform a transfer between the intermediary's merchant account and the intermediary's cardholder account for each converted transaction. Thus, in addition, to the creation of the two transaction records described above, a third transaction 700 may be created 403 as shown by example in Figure 7.
This transaction represents a conventional payment card transaction between the intermediary's merchant account and the intermediary's cardholder account.
This third transaction 700 may be submitted, for example to the merchant's acquiring bank for processing 404. As shown in Figure 7b the merchant numbers need not be the same in this invention. In other words the pseudo merchant should be one and the same, but not the merchant number.
Although the present invention has been described with reference to an intermediate host, it.will be appreciated that the crux of the present invention is the conversion of a single payment card transaction into two or more separate payment card transactions (as appropriate) using an intermediary as the join between the two or more separate transactions. It will further be appreciated that this concept may be applied in a number of different ways to achieve the desired end result. For example, the splitting into two or more transactions may be performed at the POS terminal, the intermediate host or a combination of the two Although dynamic currency conversion offers significant advantages to foreign customers of merchants, some merchants nonetheless receive a portion of the resultant additional revenue in handling dynamic currency converted transactions.
Accordingly, there is a general need to settle merchants additional revenue based on the value of dynamic currency transactions conducted. Similarly, the multi-currency banleing partner member card scheme processor (MBPMCSP) which is responsible for processing the mufti-currency payment transactions into the payment card systems generally charges an additional fees for the extra work required in processing a mufti-currency transaction as compared to a conventional unconverted transaction.
It will thus be appreciated that for any one transaction there are a number of settlement measures required to ensure that the requisite funds are distributed appropriately and that appropriate balances occur. The present invention may be modified by the inclusion of one or more further payment card transactions to achieve one or more of these objectives as described below.
In particular, to settle individual merchants their proportion (where applicable) of any additional revenue in handling dynamic currency converted transactions, a further 10 transaction record may be created. The amount of this further transaction, herein after referred to as a merchant additional revenue card transaction, would represent the additional revenue to be settled to the merchant. The merchant additional revenue card transaction would be between the second cardholder (described above) or another pseudo cardholder of the operator or an associate of the operator of the currency 15 conversion scheme and the first merchant. For convenience, the individual additional revenue to be settled to a merchant may be amalgamated into a single merchant additional revenue card transaction record for example at the end of each day, week or month. The merchant additional revenue card transaction record may be posted for processing by the card schemes as a conventional card transaction. A less preferred alternative method would be for the first merchant to have their own cardholder account to which their additional revenue may be settled as described above as a refund from the second merchant or an associated merchant thereof.
Similarly, an additional transaction record may be created to pay the MBPMCSP
their fee for handling the transaction. This transaction, hereinafter referred to as the MBPMCSP transaction, would represent the fee payable to the MBPMCSP. The MBPMCSP transaction may be between the second cardholder (described above) or another pseudo cardholder of the operator or an associate of the operator of the currency conversion scheme and a merchant (account) associated with the MBPMCSP . For convenience, the individual fees payable to the MBPMCSP may be amalgamated into a single MBPMCSP card transaction for example at the end of each day, week or month.
A less preferred alternative method would be for the MBPMCSP to have their own cardholder account to which their fees may be paid as described above as a refund from the second merchant or an associated merchant thereof.
In addition, it is accepted that the primary driving factor for implementing dynamic currency conversion is that the operator of the dynamic currency conversion scheme benefits financially from additional revenue. The presence of additional revenue does however create an imbalance between the various transactions described above.
This may best be explained by way of an example. Consider the case where a nominal ~100 transaction is conducted at a point of sale for a Japanese cardholder.
This transaction may, for example, be quoted to the cardholder at a rate of 119~/~
or ~11,900.
However, when the ~11,900 transaction is processed and returned from the Card Schemes via the MBPMCSP to the dynamic currency conversion scheme operator, it may be converted to say ~103 by the dynamic currency conversion scheme operator. Of this total amount, ~100 is effectively routed to the merchant as payment in respect of the transaction whereas the ~3 additional revenue is routed to/through the dynamic currency conversion scheme operator.
To operate this scheme successfully requires the dynamic currency conversion scheme operator to set up effective ring-fenced accounts in the relevant currencies as well as a further central account in the real merchant's currency, which in the European Eurozone would be the Euro.
Although the above method has been described with respect to the operator of the dynamic currency conversion scheme being associated with the second cardholder account and second merchant account, an alternative approach would be for these accounts to be associated accounts of the MBPMCSP, i.e. for the intermediary accounts to be the MBPMCSP. This may advantageously be employed to cleanly efficiently and effectively delineate the dynamic currency conversion scheme operator additional revenue for the transaction from the substantive transaction. In particular, this may be achieved by reducing the amount of the third transaction 700 (described above) by an amount equating to the additional revenue and creating a further transaction for an amount equating to the additional revenue. This further card transaction would be between the second (intermediate) merchant and a cardholder account associated with the dynamic currency conversion scheme operator. Alternatively, the transaction could be performed as a refund from the cardholder account of the second merchant to a merchant account associated with the dynamic currency conversion scheme operator.
It will be appreciated that a number of suitable combinations of the methods described above are possible and a number of variants may be implemented, with suitable amendment, without deviating from the scope of the present invention.
For example, in one embodiment the intermediary merchant and/or cardholder may represent the same entity but with distinct merchant\cardholder accounts for each.
The words "comprises/comprising" and the words "having/including" when used herein with reference to the present invention are used to specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.
Claims (24)
1. A method for effecting the performance of a payment card transaction for a first transaction amount in a first currency, between a first merchant and a first payment card holder, the method comprising the steps of:
a) creating a first payment card transaction record between the first merchant and a second cardholder for the first transaction amount, b) creating a second payment card transaction record between a second merchant and the first cardholder, wherein the second transaction record identifies a second transaction amount in a second currency which equates to the first transaction amount converted into the second currency, and c) submitting the first transaction record and the second transaction record for processing as payment card transactions.
a) creating a first payment card transaction record between the first merchant and a second cardholder for the first transaction amount, b) creating a second payment card transaction record between a second merchant and the first cardholder, wherein the second transaction record identifies a second transaction amount in a second currency which equates to the first transaction amount converted into the second currency, and c) submitting the first transaction record and the second transaction record for processing as payment card transactions.
2. A method for effecting the performance of a payment card transaction according to claim 1, wherein the step of submitting the first transaction record and the second transaction record for processing comprises the step of submitting the first transaction record for processing as an unconverted payment transaction.
3. A method for effecting the performance of a payment card transaction according to claim 1 or claim 2, wherein the step of submitting the first transaction record and the second transaction record for processing comprises the step of submitting the second transaction record for processing as a converted payment transaction.
4. A method for effecting the performance of a payment card transaction according to any preceding claim, further comprising the steps of creating a third payment card transaction record between the second cardholder and the second merchant for an amount in the first currency, which is the negative equivalent of the first amount and submitting the third transaction for payment processing.
5. A method for effecting the performance of a payment card transaction according to claim 4, wherein the third transaction is submitted as an unconverted payment card transaction.
6. A method for effecting the performance of a payment card transaction according to any preceding claim, further comprising the initial step of determining whether a transaction is a dynamic currency convertible transaction prior to performing the steps of creating the one or more transaction records.
7. A method for effecting the performance of a payment card transaction according to any preceding claim, further comprising the step of posting the first and/or second and/or third transactions to the host computer system associated with an acquiring and/or multi-currency bank.
8. A method according to any preceding claim, further comprising the step of creating a merchant additional revenue card transaction record between the second or a related cardholder and the first merchant, wherein the merchant additional revenue card transaction record identifies a transaction amount which equates to additional revenue to be settled to the first merchant in respect of performing at least one transaction using dynamic currency conversion.
9. A method according to any one of claims 1 to 7, further comprising the step of creating a merchant additional revenue card transaction record between a cardholder account of the first merchant and the second merchant or an associated merchant thereof, the transaction record representing a refund which equates to additional revenue to be settled to the first merchant in respect of performing at least one transaction using dynamic currency conversion.
10. A method according to any preceding claim, further comprising the step of creating a card transaction record between the second or a related cardholder and a merchant associated with the MBPMCSP, wherein the MBPMCSP transaction record identifies a transaction amount equating to the fees payable to the MBPMCSP
for processing at least one dynamic currency transaction.
for processing at least one dynamic currency transaction.
11. A method according to any one of claims 1 to 9, further comprising the step of creating a MBPMCSP card transaction record between a cardholder account of the MBPMCSP and the second (or an associated) merchant thereof, the transaction record representing a refund which equates to the fees payable to the MBPMCSP for processing at least one dynamic currency transaction.
12. A system adapted to effect the performance of a payment card transaction, the system comprising:
means for receiving details of a transaction for a first transaction amount in a first currency, between a first merchant and a first payment card holder, means for creating a first payment card transaction record between the first merchant and a second cardholder for the first transaction amount, means for creating a second payment card transaction record between a second merchant and the first cardholder, wherein the second transaction record identifies a second transaction amount in a second currency which equates to the first transaction amount converted into the second currency, and means for submitting created transaction records to a host for processing as payment card transactions.
means for receiving details of a transaction for a first transaction amount in a first currency, between a first merchant and a first payment card holder, means for creating a first payment card transaction record between the first merchant and a second cardholder for the first transaction amount, means for creating a second payment card transaction record between a second merchant and the first cardholder, wherein the second transaction record identifies a second transaction amount in a second currency which equates to the first transaction amount converted into the second currency, and means for submitting created transaction records to a host for processing as payment card transactions.
13. A system adapted to effect the performance of a payment card transaction according to claim 12, wherein the means for submitting created transaction records is suitably adapted to submit the first transaction record for processing as an unconverted payment transaction.
14. A system adapted to effect the performance of a payment card transaction according to claim 12 or claim 13, wherein the means for submitting created transaction records is suitably adapted to submit the second transaction record for processing as a converted payment transaction.
15. A system adapted to effect the performance of a payment card transaction according to anyone of claims 12 to 14, further comprising means for creating a third payment card transaction record between the second cardholder and the second merchant for an amount in the first currency, which is the negative equivalent of the first amount and submitting the third transaction for payment processing.
16. A system adapted to effect the performance of a payment card transaction according to claim 15, wherein the means for submitting created transaction records is suitably adapted to submit the third transaction record for processing as an unconverted payment transaction.
17. A system adapted to affect the performance of a payment card transaction according to anyone of claims 12 to 16, further comprising means for determining whether a transaction is a dynamic currency convertible transaction prior to performing the steps of creating the one or more transaction records.
18. A system adapted to effect the performance of a payment card transaction according to anyone of claims 12 to 17, wherein the system comprises a payment card terminal.
19. A system adapted to effect the performance of a payment card transaction according to anyone of claims 12 to 18, wherein the system comprises an intermediate or other host computer system adapted to receive payment transaction records from a payment card terminal or other device and route them for processing as either converted or unconverted transactions.
20. A system adapted to effect the performance of a payment card transaction according to anyone of claims 12 to 19, further comprising means for creating a merchant additional revenue card transaction record between the second or a related cardholder and the first merchant, wherein the merchant additional revenue card transaction record identifies a transaction amount which equates to additional revenue to be settled to the first merchant in respect of performing at least one transaction using dynamic currency conversion.
21. A system adapted to effect the performance of a payment card transaction according to anyone of claims 12 to 20, further comprising means for creating a merchant additional revenue card transaction record between a cardholder account of the first merchant and the second merchant or an associated merchant thereof, the transaction record representing a refund which equates to additional revenue to be settled to the first merchant in respect of performing at least one transaction using dynamic currency conversion.
22. A system adapted to effect the performance of a payment card transaction according to anyone of claims 12 to 21, further comprising means for creating a MBPMCSP
card transaction record between the second or a related cardholder and a merchant associated with the MBPMCSP, wherein the MBPMCSP transaction record identifies a transaction amount equating to the fees payable to the MBPMCSP for processing at least one dynamic currency transaction.
card transaction record between the second or a related cardholder and a merchant associated with the MBPMCSP, wherein the MBPMCSP transaction record identifies a transaction amount equating to the fees payable to the MBPMCSP for processing at least one dynamic currency transaction.
23. A system adapted to effect the performance of a payment card transaction according to anyone of claims 12 to 22, further comprising means for creating a MBPMCSP
card transaction record between a cardholder account of the MBPMCSP and the second (or an associated) merchant thereof, the transaction record representing a refund which equates to the fees payable to the MBPMCSP for processing at least one dynamic currency transaction.
card transaction record between a cardholder account of the MBPMCSP and the second (or an associated) merchant thereof, the transaction record representing a refund which equates to the fees payable to the MBPMCSP for processing at least one dynamic currency transaction.
24. A computer program product having code embodied therein which when implemented on a computer effects the methods of any one of claims 1 to 11.
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| IES2002/0579 | 2002-07-12 | ||
| IE20020579A IES20020579A2 (en) | 2002-07-12 | 2002-07-12 | Methods and systems for effecting payment card transactions |
| PCT/IE2003/000002 WO2004008372A2 (en) | 2002-07-12 | 2003-01-10 | Methods and systems for effecting payment card transactions |
| IEPCT/IE03/00002 | 2003-01-10 | ||
| PCT/IE2003/000101 WO2004008399A2 (en) | 2002-07-12 | 2003-07-14 | Methods and systems for effecting payment card transactions |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2494549A1 true CA2494549A1 (en) | 2004-01-22 |
Family
ID=30117184
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002494549A Abandoned CA2494549A1 (en) | 2002-07-12 | 2003-07-14 | Methods and systems for effecting payment card transactions |
Country Status (6)
| Country | Link |
|---|---|
| EP (1) | EP1535249A2 (en) |
| JP (1) | JP2005533308A (en) |
| AU (1) | AU2003250508A1 (en) |
| CA (1) | CA2494549A1 (en) |
| NZ (1) | NZ537683A (en) |
| WO (1) | WO2004008399A2 (en) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7660768B2 (en) | 2002-11-07 | 2010-02-09 | Planet Payment, Inc. | Time-of-transaction foreign currency conversion |
| AP2239A (en) | 2004-07-12 | 2011-05-27 | Fexco | Direct currency conversion. |
| US7933835B2 (en) | 2007-01-17 | 2011-04-26 | The Western Union Company | Secure money transfer systems and methods using biometric keys associated therewith |
| US8818904B2 (en) | 2007-01-17 | 2014-08-26 | The Western Union Company | Generation systems and methods for transaction identifiers having biometric keys associated therewith |
| US8504473B2 (en) | 2007-03-28 | 2013-08-06 | The Western Union Company | Money transfer system and messaging system |
| MY180197A (en) * | 2008-11-26 | 2020-11-24 | Einnovations Holdings Pte Ltd | Credit provision system and method |
| GB2478993A (en) * | 2010-03-26 | 2011-09-28 | Global Blue Currency Choice Holdings Bv | Dynamic currency conversion |
| CN103548047A (en) * | 2010-12-30 | 2014-01-29 | 拉尔斯·奥洛夫·康恩葛尔迪 | Terminal authenticity verification |
| GR20220100628A (en) | 2022-08-01 | 2024-03-12 | Παπαδοπουλος Νικολαος-Ξαφακης Σωτηριος Ομορρυθμη Εταιρεια, | Method of developing resistant anti-pollution nano-coating systems exhibiting additional strong anti-microbial action |
-
2003
- 2003-07-14 WO PCT/IE2003/000101 patent/WO2004008399A2/en active Application Filing
- 2003-07-14 AU AU2003250508A patent/AU2003250508A1/en not_active Abandoned
- 2003-07-14 JP JP2004521047A patent/JP2005533308A/en active Pending
- 2003-07-14 NZ NZ537683A patent/NZ537683A/en not_active IP Right Cessation
- 2003-07-14 CA CA002494549A patent/CA2494549A1/en not_active Abandoned
- 2003-07-14 EP EP03764094A patent/EP1535249A2/en not_active Ceased
Also Published As
| Publication number | Publication date |
|---|---|
| NZ537683A (en) | 2007-04-27 |
| JP2005533308A (en) | 2005-11-04 |
| AU2003250508A1 (en) | 2004-02-02 |
| WO2004008399A8 (en) | 2005-04-07 |
| WO2004008399A2 (en) | 2004-01-22 |
| EP1535249A2 (en) | 2005-06-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ZA200500239B (en) | Method and systems for effecting payment card transactions | |
| US6826544B1 (en) | Automated loan repayment | |
| US7930229B2 (en) | Debit card billing system and method | |
| US20170200140A1 (en) | System and method for updating merchant payment data | |
| US20020032653A1 (en) | Method and system for payment over the internet | |
| HU219257B (en) | Electronic bill pay system, method and network | |
| RU96117523A (en) | CALCULATION CARD, TERMINAL (OPTIONS), SYSTEM AND METHOD OF CASHLESS CASH | |
| CA2397936A1 (en) | Consumer-directed financial transfers using automated clearinghouse networks | |
| US8892468B1 (en) | Customer refunds by a merchant agent | |
| EP0995174A1 (en) | Automated loan repayment | |
| CA2498672C (en) | A method and system for transferring funds | |
| US20020002537A1 (en) | Simplified bill paying method | |
| US6889200B2 (en) | Rapid tax collection system and method for debit-type transactions | |
| CA2494549A1 (en) | Methods and systems for effecting payment card transactions | |
| US20070088611A1 (en) | Effecting ancillary actions on a transaction network | |
| IE20020579U1 (en) | Methods and systems for effecting payment card transactions | |
| IES83309Y1 (en) | Methods and systems for effecting payment card transactions | |
| WO2006119558A1 (en) | Effecting ancillary actions on an established transaction network | |
| IE20020712U1 (en) | A method and system for transferring funds | |
| TW200404242A (en) | Methods and systems for effecting payment card transactions | |
| IES83415Y1 (en) | A method and system for transferring funds | |
| JP2012178172A (en) | Method and system for transferring funds |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |
Effective date: 20150210 |