CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of, and priority to, Singapore Patent Application No. 10201702676U filed on March 31, 2017. The entire disclosure of the above application is incorporated herein by reference.

BACKGROUND OF THE INVENTION

The present invention relates to a system and method for use in facilitating at least one transaction between a user and one or more merchants, and in one example to a system and method whereby the at least one transaction is performed using a proxy account of an entity such as a hotel or travel agency that is linked to a user account.

DESCRIPTION OF THE PRIOR ART

The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that the prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.

When travelling for business or holiday, a person typically makes many purchases using their personal debit/credit cards, including, but not limited to hotels and accommodation, food and dining, shopping, activities, taxis, tours etc. In some countries, not all cards are accepted for payment which can lead to difficulties, particularly if the person is not carrying local currency. Even if cards are accepted, in some countries, there are elevated security risks in using personal cards with foreign merchants which can make people reluctant to want to use their personal cards.

For business travel, a person is normally reimbursed for most of their expenditure while travelling. Typically, to be reimbursed, the person must save all of their receipts, and also remember to ask for receipts from every merchant at time of purchase. This does not always happen and often receipts are lost which can make reimbursement difficult. Also, when in a foreign location (including another city in a person's home country), a person will not typically be aware of any benefits or offers available for shopping, dining etc. during their stay. The person will also not typically be aware of merchants which they should avoid, for example those which have a reputation of taking advantage of foreigners etc. This can lead to customer's travel expenditure being a lot greater than it should otherwise be.

For a hotel, there are instances of fraudulent "room signing" situations, for example when a guest eats a meal or buys a drink in a hotel and puts the expense against another guest's room. This type of fraud is typically not detected until check-out when the other guest realises that fraudulent charges have been put against their room.

It is against this background, and the problems and difficulties associated therewith, that the present invention has been developed.

SUMMARY OF THE PRESENT INVENTION

In a broad form, the present invention seeks to provide a method for use in facilitating at least one transaction between a user and one or more merchants, the method including, in one or more electronic processing devices:

a) receiving for each transaction, a transaction request from a merchant terminal, the transaction request including:

i) an indication of a processing code for a purchase transaction; ii) an indication of a purchase transaction amount; and,

iii) an indication of a proxy account identifier;

b) determining an indication of a user account linked to a proxy account using the proxy account identifier and link data indicative of associations between proxy accounts and user accounts;

c) sending an incremental pre-authorisation request to a user account issuer in accordance with the purchase transaction amount and the user account; and, in response to successful pre-authorisation from the user account issuer, causing the transaction with the merchant to be processed using account information associated with the proxy account.

Typically, the method further includes, in the one or more electronic processing devices, modifying the transaction request by: replacing the indication of the proxy account identifier with an indication of a user account identifier associated with the user account; and,

replacing the indication of the processing code for a purchase transaction with an indication of a processing code for an incremental pre- authorisation.

Typically, the method further includes, in the one or more electronic processing devices, further modifying the transaction request by including:

e) an indication of a transaction identifier; and,

f) an indication of the linked proxy account.

Typically, the modified transaction request is the incremental pre- authorisation request sent to the user account issuer.

Typically, the transaction identifier is sent to the user account issuer with each incremental pre-authorisation request to enable the user account issuer to identify each request as being associated with an initial pre-authorisation request.

Typically, the transaction identifier is created when an initial pre- authorisation request is sent to the user account issuer.

Typically, the initial pre-authorisation request is generated by an entity associated with the proxy account.

Typically, causing the transaction with the merchant to be processed includes:

g) sending a transaction purchase request to a proxy account issuer; and, h) in response to successful authorisation from the proxy account issuer, sending an authorisation approval message to a merchant acquirer.

Typically, the transaction purchase request sent to the proxy account issuer includes:

i) an indication of the proxy account identifier;

j) an indication of the processing code for a purchase transaction; and, k) an indication of the transaction identifier.

Typically, the method further includes, in the one or more electronic processing devices:

1) receiving a completion request from the entity associated with the proxy account, the completion request being indicative of the total expenditure made by the user on the proxy account; m) determining that the completion request is a final pre-authorisation completion request for all of the incremental pre-authorisations made on the user account;

n) sending the completion request to the user account issuer: and,

o) in response to successful completion authorisation from the user account issuer, causing payment to be made from the user account issuer to an acquirer of the entity associated with the proxy account.

Typically, the payment is indicative of completion of all o the incremental pre-authorisations and is processed as part of a single transaction.

Typically, the completion request includes:

p) an indication of the user account identifier:

q) an indication of an incremental pre-authorisation;

r) an indication of a final amount payable;

s) an indication of the transaction identifier;

t) an indication of the proxy account linked to the user account: and, u) an indication of an approval code generated by the user account issuer during the initial pre-authorisation made against the user account.

Typically, after the pre-authorisation completion has been processed, the user account is de-linked from the proxy account by updating the link data and removing association between the proxy account and the user account.

In another broad form, the present invention seeks to provide a system for use in facilitating at least one transaction between a user and one or more merchants, the system including, one or more electronic processing devices that: v) receive for each transaction, a transaction request from a merchant terminal, the transaction request including:

i) an indication of a processing code for a purchase transaction; ii) an indication of a purchase transaction amount: and,

hi) an indication of a proxy account identifier;

w) determine an indication of a user account linked to a proxy account using the proxy account identifier and link data indicative of associations between proxy accounts and user accounts;

x) send an incremental pre-authorisation request to a user account issuer in accordance with the purchase transaction amount and the user account: and, y) in response to successful pre-authorisation from the user account issuer, cause the transaction with the merchant to be processed using account information associated with the proxy account.

In another broad form, the present invention seeks to provide a method for use in facilitating at least one transaction between a user and one or more merchants, the method including, in one or more electronic processing devices:

z) receiving for each transaction, a transaction request from a merchant terminal, the transaction request including:

i) a first data element indicative of a proxy account identifier; ii) a second data element indicative of a processing code for a purchase transaction; and,

iii) a third data element indicative of a purchase transaction amount;

aa) determining a user account identifier indicative of a user account linked to a proxy account using the proxy account identifier and link data indicative of associations between proxy accounts and user accounts;

bb) modifying the transaction request by:

i) updating the first data element by replacing the indication of the proxy account identifier with an indication of the user account identifier; and, ii) updating the second data element by replacing the indication of the processing code for a purchase transaction with an indication of a processing code for an incremental pre-authorisation;

cc) sending the modified transaction request to a user account issuer;

dd) in response to receiving a successful pre-authorisation response from the user account issuer, causing the transaction with the merchant to be processed using account information associated with the proxy account.

Typically, the modified transaction request includes one or more of: ee) a fourth data element indicative of a transaction identifier that enables the user account issuer to identify the transaction; and,

fit) a fifth data element indicative of the linked proxy account.

Typically, causing the transaction with the merchant to be processed includes:

gg) sending a transaction purchase request to a proxy account issuer; and, hh) in response to successful authorisation from the proxy account issuer, sending an authorisation approval message to a merchant acquirer.

Typically, the transaction purchase request sent to the proxy account issuer is indicative of the transaction request received from the merchant terminal and further includes the fourth data element indicative of the transaction identifier.

In a further broad form, the present invention seeks to provide a system for use in facilitating at least one transaction between a user and one or more merchants, the system including, one or more electronic processing devices that:

ii) receive for each transaction, a transaction request from a merchant terminal, the transaction request including:

i) a first data element indicative of a proxy account identifier; and, ii) a second data element indicative of a processing code for a purchase transaction;

iii) a third data element indicative of a purchase transaction amount;

jj) determine a user account identifier indicative of a user account linked to a proxy account using the proxy account identifier and link data indicative of associations between proxy accounts and user accounts;

kk) modify the transaction request by:

i) updating the first data element by replacing the indication of the proxy account identifier with an indication of the user account identifier; and, ii) updating the second data element by replacing the indication of the processing code for a purchase transaction with an indication of a processing code for an incremental pre-authorisation;

11) send the modified transaction request to a user account issuer;

mm) in response to receiving a successful pre-authorisation response from the user account issuer, cause the transaction with the merchant to be processed using account information associated with the proxy account.

In yet a further broad form, the present invention seeks to provide a method of linking a user account to a proxy account to enable transactions to be performed between a user and one or more merchants using the proxy account, the method including in one or more electronic processing devices:

nn) receiving a request to link the user account with the proxy account, the link request being indicative of the user account and the proxy account; oo) requesting approval for linking the accounts from the user account issuer; and,

pp) in response to receiving approval from the user account issuer, generating link data indicative of the association between the user account and the proxy account.

Typically, the method further includes:

qq) receiving a transaction request from an entity associated with the proxy account, the transaction request including:

i) an indication of a user account identifier;

ii) an indication of a processing code indicative of an incremental pre- authorisation;

iii) an indication of an initial value pre-authorisation; and,

iv) an indication of a proxy account identifier;

rr) generating a transaction identifier;

ss) modifying the transaction request to include the transaction identifier; tt) sending the modified transaction request to a user account issuer as an initial pre-authorisation for the initial value;

uu) receiving a pre-authorisation approval response from the user account issuer including:

i) an indication of an approval code;

ii) an indication of the transaction identifier; and,

iii) an indication of the link between the proxy account and the user account; w) sending the pre-authorisation approval response from the user account issuer to a proxy account issuer;

ww) receiving an authorisation from the proxy account issuer; and, xx) sending the authorisation to an acquirer of the entity associated with the proxy account.

Typically, the initial value is zero.

It will be appreciated that the broad forms of the invention and their respective features can be used in conjunction, interchangeably and/or independently, and reference to separate broad forms is not intended to be limiting. BRIEF DESCRIPTION OF THE DRAWINGS

A non-limiting example of the present invention will now be described with reference to the accompanying drawings, in which: -

Figure 1 is a flow chart of an example of a method for use in facilitating at least one transaction between a user and one or more merchants;

Figure 2 is a schematic diagram of an example of a system for use in facilitating at least one transaction between a user and one or more merchants;

Figure 3 is a schematic diagram of an example of a merchant terminal;

Figure 4 is a schematic diagram of an example of a link server that stores link data indicative of associations between proxy accounts and user accounts;

Figure 5 is a schematic diagram of an example of a payment processing system;

Figure 6 is a schematic diagram of an example of the interactions involved in processing a merchant transaction using the system of Figure 2;

Figure 7 is a schematic diagram of an example of the interactions involved in processing a hotel transaction using the system of Figure 2;

Figures 8A to 8C is a flowchart of an example of a specific process of performing one or more merchant transactions using a hotel card and performing a single pre-authorisation completion transaction with a hotel using a user card;

Figures 9A to 9B is a flowchart of an example of a specific process of performing a transaction between a user and a merchant using a hotel card;

Figures 10A to IOC represent examples of messages used in a payment processing system for performing an initial pre-authorisation on a user card; and,

Figures 11 A to 11C represent examples of messages used in a payment processing system for performing a purchase transaction with a merchant using a hotel card; and,

Figure 12 represents an example of a pre-authorisation completion message used to finalise the pre-authorisations with the hotel.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

An example of a method for use in facilitating at least one transaction between a user and one or more merchants shall now be described with reference to Figure 1. For the purpose of illustration, it is assumed that the process is performed at least in part using one or more electronic processing devices forming part of one or more processing systems, such as servers, which are in turn connected to one or more merchant terminals, such as POS devices, mobile phones, portable computers or the like, via a network architecture, as will be described in more detail below.

For the purpose of the example of Figure 1, it is assumed that the processing devices are utilised by a card service provider (i.e. card network such as Mastercard ^® , Visa ^® and the like) in order to allow payments to be processed on behalf of a merchant, and these will therefore be referred to as one or more provider processing devices. The one or more provider processing devices may interact with other processing devices operated by an acquirer or an issuer and these will therefore be referred to as acquirer processing devices and issuer processing devices. The acquirer and the issuer are typically entities such as financial institutions, banks or the like. The acquirer processes and settles a merchant's credit or debit card transactions with the help of the issuer, which is the entity that has issued the credit or debit card to the customer to allow the customer to make credit or debit card payments. In this example, a proxy entity has a credit or debit card issued by a proxy account issuer. A customer temporarily links a personal credit or debit card issued by a user account issuer to the proxy card to enable them to perform transactions with merchants using the proxy card (i.e. a proxy for their own personal card). The entity referred to as the proxy could be any suitable entity but in a preferred example is a hotel (or travel agency) that for example provides a hotel credit or debit card to each room guest for the duration of their stay at the hotel.

In the following description, the terms "user account" is used interchangeably with "user card" and "proxy account" or "hotel account" is used interchangeably with "proxy card" or "hotel card".

In this example, at step 100, the one or more electronic processing devices receive for each transaction, a transaction request from a merchant terminal including an indication of a processing code for a purchase transaction, an indication of a purchase transaction amount, and, an indication of a proxy account identifier. The proxy account identifier may for example be a proxy account number, proxy credit or debit card number or the like. The transaction request is typically sent by the merchant terminal, via a merchant acquirer at the point of sale when the user presents a proxy card to the merchant to make a purchase, for example food, drinks, shopping, tour booking or the like.

At step 110, the method includes determining an indication of a user account linked to a proxy account using the proxy account identifier and link data indicative of associations between proxy accounts and user accounts. The link data indicative of associations between proxy accounts and user accounts is typically stored on a link server or database when users (for example hotel guests) check-in to the hotel and are given hotel cards for the duration of their stay to make purchases with. The link data includes for example the proxy account number and user account information such as user credit/debit card number, name on card, expiry date, card verification value (CVV) etc. When the payment provider processing device receives a transaction request including the proxy account identifier, it looks up the proxy account identifier on the link server or database and retrieves the associated user account information.

After the indication of the user account has been determined, the method includes sending an incremental pre-authorisation request to a user account issuer in accordance with the purchase transaction amount and the user account. This request is to ensure that the user has sufficient funds in their account to cover the purchase transaction amount. The request is an incremental pre-authorisation request for each merchant transaction as each new transaction request is effectively a "top-up" of the previous pre-authorisation.

At step 130, the method further includes, in response to successful pre- authorisation from the user account issuer, causing the transaction with the merchant to be processed using account information associated with the proxy account. Once the user account issuer indicates that sufficient funds are available in the user account, the transaction proceeds as normal between the proxy account issuer and merchant acquirer. The transaction is completed when the proxy account issuer approves the transaction and funds are transferred from the proxy account to the merchant acquirer which eventually makes payment to the merchant.

It will be appreciated that the above described method provides a number of benefits. For example, in the context of a hotel guest, the guest is able perform merchant transactions using a hotel credit or debit card during their stay with the hotel, with each transaction being processed as an incremental pre-authorisation on their personal credit or debit card. As will be described in further detail below, at check-out from the hotel, the guest will perform a single pre-authorisation completion for their personal card resulting in the hotel being paid for the multiple purchases on the hotel card in a single transaction. In other words, the user can perform multiple transactions with multiple merchants during their travel or stay at the hotel but only have to perform a single transaction with the hotel and thereby receive a single bill and receipt for their trip which makes reimbursements easier for business.

As the hotel's card is used for each merchant transaction, the user will have more confidence in performing transactions with unknown merchants as they are not using their personal card for the transactions and therefore risk of credit card fraud, theft and the like is reduced. The user can also be made aware of promotions or offers that they can receive with merchants while using the hotel card.

The method is also beneficial for the hotel or travel agency or the like as every transaction performed by the guest or customer during their trip is actually performed by the hotel or travel agency and their transaction acquirer which can lead to increased accumulation of points and other benefits for the cardholder. The hotel can also promote the benefits of the card system which may lead to increased business and bookings. Instances of "room signing" fraud will also be reduced as guests would make in-house purchases with their hotel card. The hotel may also have the ability to control the transaction limits as well as merchants where purchases are not allowed.

Finally, there are additional benefits to the issuing banks as more cards will be issued to hotel, travel agencies and the like to accommodate their guests and customers and more profits will be made through transaction fees and the like. Every guest of the hotel or customer of the travel agency essentially becomes a customer of the issuing bank of the hotel or travel agency cards. The card service providers will also benefit from increased number of transactions using credit or debit cards instead of cash.

A number of further features will now be described.

Typically, the method further includes, in the one or more electronic processing devices, modifying the transaction request by replacing the indication of the proxy account identifier with an indication of a user account identifier associated with the user account, and replacing the indication of the processing code for a purchase transaction with an indication of a processing code for an incremental pre- authorisation. In this way, the card service provider is responsive to receiving the transaction request to generate the incremental pre-authorisation request to be sent to the user account issuer. As part of this process, the account numbers are switched (from proxy to user) and the type of request is changed from purchase to incremental pre-authorisation so that the card service provider can verify the user has sufficient funds to make the purchase.

Typically, the method further includes, in the one or more electronic processing devices, further modifying the transaction request by including an indication of a transaction identifier, and an indication of the linked proxy account. The transaction identifier is sent to the user account issuer with each incremental pre- authorisation request to enable the user account issuer to identify each request as being associated with an initial pre-authorisation request. In this way, the user account issuer is able to track and recognise that each new incremental pre-authorisation is part of a single transaction that is finally completed with the hotel at check-out. The indication of the linked proxy account is also provided to the user account issuer so that whenever the user account issuer receives a request having the linked proxy account indication and modified processing code for pre-authorisation it will recognise that incremental pre-authorisation is being requested.

The transaction identifier is typically created when an initial pre- authorisation request is sent to the user account issuer. In one example, the initial pre- authorisation request is generated by an entity associated with the proxy account. For example, this will typically be performed by a hotel at check-in when a user is given a hotel card and links it to their personal card. The initial pre-authorisation request validates the user's card and establishes a number of parameters such as approval codes, terminal and acquirer identifiers and the like that need to be included in the final completion message at check-out.

Typically, after the user account issuer has approved the incremental pre-authorisation request, the step of causing the transaction with the merchant to be processed includes the card service provider processing device sending a transaction purchase request to a proxy account issuer, and, in response to successful

authorisation from the proxy account issuer, sending an authorisation approval message to a merchant acquirer. The merchant is then paid and the transaction is completed.

Typically, the transaction purchase request sent to the proxy account issuer includes an indication of the proxy account identi fier, an indication of the processing code for a purchase transaction, and, an indication of the transaction identifier. This enables the proxy account issuer to debit the proxy account and track the amount payable by the user in accordance with the transaction identifier.

The method further includes in the one or more electronic processing devices receiving a completion request from the entity associated with the proxy account, the completion request being indicative of the total expenditure made by the user on the proxy account. The processing device then determines that the completion request is a final pre-authorisation completion request for all of the incremental pre- authorisations made on the user account. The completion request is sent to the user account issuer and in response to successful completion authorisation from the user account issuer, the processing device causes payment to be made from the user account issuer to an acquirer of the entity associated with the proxy account.

It is to be appreciated that the above-mentioned payment is indicative of completion of all of the incremental pre-authori sations and is processed as part of a single transaction between the user and the entity associated with the proxy account (e.g. hotel). In this way, the user pays a single bill with his personal card and receives a single receipt for the duration of his travel.

Typically, the completion request includes a number of parameters including, but not limited to: an indication of the user account identifier; an indication of an incremental pre-authorisation; an indication of a final amount payable; an indication of the transaction identifier; an indication of the proxy account linked to the user account; and. an indication of an approval code generated by the user account issuer during the initial pre-authorisation made against the user account. These parameters assist the card service provider and user account issuer to identify this message as being the final completion for all of the prc-authorisations made against the user account.

After the pre-authorisation completion has been processed, the user account is de-linked from the proxy account by updating the link data and removing association between the proxy account and the user account. In a broad form, there is also provided a system for use in facilitating at least one transaction between a user and one or more merchants, the system including, one or more electronic processing devices that receive for each transaction, a transaction request from a merchant terminal, the transaction request including: an indication of a processing code for a purchase transaction; an indication of a purchase transaction amount; and, an indication of a proxy account identifier. The processing devices further determine an indication of a user account linked to a proxy account using the proxy account identifier and link data indicative of associations between proxy accounts and user accounts, send an incremental pre-authorisation request to a user account issuer in accordance with the purchase transaction amount and the user account; and, in response to successful pre-authorisation from the user account issuer, cause the transaction with the merchant to be processed using account information associated with the proxy account.

In yet a further broad form there is provided a method for use in facilitating at least one transaction between a user and one or more merchants, the method including, in one or more electronic processing devices: receiving for each transaction, a transaction request from a merchant terminal, the transaction request including: a first data element indicative of a proxy account identifier; a second data element indicative of a processing code for a purchase transaction; and, a third data element indicative of a purchase transaction amount. The method further includes determining a user account identifier indicative of a user account linked to a proxy account using the proxy account identifier and link data indicative of associations between proxy accounts and user accounts. The transaction request is then modified by updating the first data element by replacing the indication of the proxy account identifier with an indication of the user account identifier; and, updating the second data element by replacing the indication of the processing code for a purchase transaction with an indication of a processing code for an incremental pre- authorisation. Finally, the method includes sending the modified transaction request to the user account issuer and in response to receiving a successful pre-authorisation response from the user account issuer, causing the transaction with the merchant to be processed using account information associated with the proxy account.

Typically, the modified transaction request includes one or more of: a fourth data element indicative of a transaction identifier that enables the user account issuer to identify the transaction; and, a fifth data element indicative of the linked proxy account.

The step of causing the transaction with the merchant to be processed includes sending a transaction purchase request to a proxy account issuer; and, in response to successful authorisation from the proxy account issuer, sending an authorisation approval message to a merchant acquirer. The proxy account issuer then debits the proxy account and sends payment to the merchant acquirer which transfers payment to the merchant.

Typically, the transaction purchase request sent to the proxy account issuer is indicative of the transaction request received from the merchant terminal and further includes the fourth data element indicative of the transaction identifier.

In another broad form there is provided a method of linking a user account to a proxy account to enable transactions to be performed between a user and one or more merchants using the proxy account, the method including in one or more electronic processing devices: receiving a request to link the user account with the proxy account, the link request being indicative of the user account and the proxy account; requesting approval for linking the accounts from the user account issuer; and in response to receiving approval from the user account issuer, generating link data indicati ve of the association between the user account and the proxy account . The user is typically able to at least partially link their user account to the proxy account via an online proxy account that they are given temporary user rights to access.

Alternatively, the linking may occur when the hotel or other proxy performs an initial pre-authorisation for the user account and inputs proxy account details to the hotel terminal.

In this regard, the method may further include receiving a transaction request from an entity associated with the proxy account, the transaction request including: an indication of a user account identifier: an indication of a processing code indicative of an incremental pre-authorisation; an indication of an initial value pre-authorisation; and, an indication of proxy account identifier. The transaction identifier is then generated and the transaction request is modified to include the transaction identifier. The method then includes sending the modified transaction request to a user account issuer as an initial pre-authorisation for the initial value; receiving a pre-authorisation approval response from the user account issuer including: an indication of an approval code; an indication of the transaction identifier; and. an indication of the link between the proxy account and the user account. Finally, the method includes sending the pre-authorisation approval response from the user account issuer to a proxy account issuer; receiving an authorisation from the proxy account issuer; and. sending the authorisation to an acquirer of the entity associated with the proxy account. Typically, the initial pre-authori sation has a zero dollar value and made for the purposes of generating the transaction identifier and storing this optionally as link data associating the proxy account and user account.

In one example, the process is performed by one or more processing systems operating as part of a distributed architecture, an example of which will now be described with reference to Figure 2.

In this example, a number of processing systems 220. 230, 240, 250, 260 are coupled to one or more merchant terminals 210.1. 201 .2, via one or more communications networks 202, 204, such as the Internet, and/or a number of local area networks (LANs). The processing devices are typically operated by parties, such as acquirers, card service providers and issuers, and it will therefore be appreciated that any number of processing systems and any number of merchant terminals 210.1 , 210.2 could be provided, and the current representation is for the purpose of illustration only. For the purpose of this example, the processing devices include a link server 220. a card service provider processing device 230, a proxy account issuer processing device 240. a user account issuer processing device 250. and a merchant acquirer processing device 260. The configuration of the networks 202. 204 is also for the purpose of example only, and in practice the processing systems 220. 230, 240. 250. 260 and merchant terminals 21 .1. 210.2 can communicate via any appropriate mechanism, such as via wired or wireless connections, including, but not limited to mobile networks, private networks, such as an 802.1 1 networks, the Internet, LANs, WANs, or the like, as well as via direct or point-to-point connections, such as

Bluetooth, or the like.

In use, the processing systems 220. 230, 240, 250, 260 are adapted to perform various data processing tasks forming part of a payment process, and the particular functionality will vary depending on the particular requirements. For example, the processing systems can be adapted to determine transaction details, determine linked account details, generate transaction messages, implement payment services, perform payments, or cause further payment systems (not shown), such as servers of financial institutions, payment gateways or the like, to perform payments, as will be appreciated by persons skilled in the art.

Whilst the processing systems 210 are shown as single entities, it will be appreciated they could include a number of processing systems distributed over a number of geographically separate locations, for example as part of a cloud based environment. Thus, the above described arrangements are not essential and other suitable configurations could be used.

The merchant terminals 210.1, 210.2 may include any suitable processing device, such as a computer system, server(s), personal computer, POS terminal, or the like. In the example shown, merchant terminal 210.1 is a proxy terminal (such as a hotel or travel agency terminal) whilst merchant terminals 210.2 represent any merchant with whom the user performs a purchase transaction other than the entity associated with the proxy account.

As shown in Figure 3, in one example, the merchant terminal 210 includes at least one microprocessor 300, a memory 301, an input/output device 302, such as a keyboard and/or display, an external interface 303, and typically a card reader 304, interconnected via a bus 305 as shown. In this example the external interface 303 can be utilised for connecting the merchant terminal 210 to peripheral devices, such as the communications networks 202, 204, databases, other storage devices, or the like. Although a single external interface 303 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (e.g. Ethernet, serial, USB, wireless or the like) may be provided. The card reader 304 can be of any suitable form and could include a magnetic card reader, or contactless reader for reading smartcards, or the like.

In use, the microprocessor 300 executes instructions in the form of applications software stored in the memory 301, and to allow communication with one of the processing systems 220, 230, 240, 250, 260.

Accordingly, it will be appreciated that the merchant terminals 210 may be formed from any suitable processing system, such as a suitably programmed PC, Internet terminal, lap-top, or hand-held PC, and in one preferred example is either a POS terminal, or a tablet, or smart phone, with integrated or connected card reading capabilities. However, it will also be understood that the merchant terminals 210 can be any electronic processing device such as a microprocessor, microchip processor, logic gate configuration, firmware optionally associated with implementing logic such as an FPGA (Field Programmable Gate Array), or any other electronic device, system or arrangement.

An example of a suitable processing system 220 is shown in Figure 4.

In this example, the processing system 220 includes at least one microprocessor 400, a memory 401, an optional input/output device 402, such as a keyboard and/or display, and an external interface 403, interconnected via a bus 404 as shown. In this example the external interface 403 can be utilised for connecting the processing system 220 to peripheral devices, such as the communications networks 202, 204, databases 221, other storage devices, or the like. Although a single external interface 403 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (e.g. Ethernet, serial, USB, wireless or the like) may be provided.

In use, the microprocessor 400 executes instructions in the form of applications software stored in the memory 401 to allow the required processes to be performed such as storing link data indicative of associations between proxy accounts and user accounts and sending link data to the card service provider processing device to enable the merchant transaction to be performed. The applications software may include one or more software modules, and may be executed in a suitable execution environment, such as an operating system environment, or the like.

Accordingly, it will be appreciated that the processing system 220 may be formed from any suitable processing system, such as a suitably programmed merchant device. PC, web server, link server, network server, or the like. In one particular example, the processing system 220 is a standard processing system such as an Intel Architecture based processing system, which executes software applications stored on non-volatile (e.g., hard disk) storage, although this is not essential.

However, it will also be understood that the processing system could be any electronic processing device such as a microprocessor, microchip processor, logic gate configuration, firmware optionally associated with implementing logic such as an FPGA (Field Programmable Gate Array), or any other electronic device, system or arrangement. The a card service provider processing device 230, proxy account issuer processing device 240, user account issuer processing device 250, and merchant acquirer processing device 260, of any of the examples herein may be formed of any suitable processing device, and one such suitable device is shown in Figure 5. In this example, a processing device is provided by a server 500 in communication with a database 501, as shown in Figure 5. The computer system 500 is able to communicate with the merchant terminals 210.1, 210.2, link server 220 and database 221, and any one of the processing devices in the payment system, as required, over a communications network 202 using standard communication protocols.

The components of the system 500 can be configured in a variety of ways. The components can be implemented entirely by software to be executed on standard computer server hardware, which may comprise one hardware unit or different computer hardware units distributed over various locations, some of which may require the communications network 202 for communication. A number of the components or parts thereof may also be implemented by application specific integrated circuits (ASICs) or field programmable gate arrays.

In the example shown in Figure 5, the computer system 500 is a commercially available server computer system based on a 32 bit or a 64 bit Intel architecture, and the processes and/or methods executed or performed by the computer system 500 are implemented in the form of programming instructions of one or more software components or modules 502 stored on non-volatile (e.g., hard disk) computer-readable storage 503 associated with the computer system 500. At least parts of the software modules 502 could alternatively be implemented as one or more dedicated hardware components, such as application-specific integrated circuits (ASICs) and/or field programmable gate arrays (FPGAs).

The computer system 500 includes at least one or more of the following standard, commercially available, computer components, all interconnected by a bus 505: 1. random access memory (RAM) 506;

2. at least one computer processor 507, and

3. external computer interfaces 508: a. universal serial bus (USB) interfaces 508.1 (at least one of which is connected to one or more user-interface devices, such as a keyboard, a pointing device (e.g., a mouse 509 or touchpad), b. a network interface connector (NIC) 508.2 which connects the computer system 500 to a data communications network, such as the Internet 550; and c. a display adapter 508.3, which is connected to a display device 510 such as a liquid-crystal display (LCD) panel device.

The computer system 500 includes a plurality of standard software modules, including:

1. an operating system (OS) 511 (e.g., Linux or Microsoft Windows);

2. web server software 512 (e.g., Apache, available at http://www.apache.org);

3. scripting language modules 513 (e.g., personal home page or PHP, available at http://www.php.net, or Microsoft ASP); and

4. structured query language (SQL) modules 514 (e.g., MySQL, available from http://www.mysql.com), which allow data to be stored in and retrieved/accessed from an SQL database 501.

Together, the web server 512, scripting language 513, and SQL modules 514 provide the computer system 500 with the general ability to allow users of the Internet 250 with standard computing devices equipped with standard web browser software to access the computer system 500 and in particular to provide data to and receive data from the database 501. It will be understood by those skilled in the art that the specific functionality provided by the system 500 to such users is provided by scripts accessible by the web server 512, including the one or more software modules 502 implementing the processes performed by the computer system 500, and also any other scripts and supporting data 515, including markup language (e.g., HTML, XML) scripts, PHP (or ASP), and/or CGI scripts, image files, style sheets, and the like.

The boundaries between the modules and components in the software modules 502 are exemplary, and alternative embodiments may merge modules or impose an alternative decomposition of functionality o modules. For example, the modules discussed herein may be decomposed into submodules to be executed as multiple computer processes, and, optionally, on multiple computers. Moreover, alternative embodiments may combine multiple instances of a particular module or submodule. Furthermore, the operations may be combined or the functionality of the operations may be distributed in additional operations in accordance with the invention. Alternatively, such actions may be embodied in the structure of circuitry that implements such functionality, such as the micro-code of a complex instruction set computer (CISC), firmware programmed into programmable or

erasable/programmable devices, the configuration of a field- programmable gate array (FPGA), the design of a gate array or full -custom appl icati on-speci tic integrated circuit (ASIC), or the like.

Each of the steps of the processes performed by the computer system 500 may be executed by a module (of software modules 502) or a portion of a module. The processes may be embodied in a non-transient machine-readable and/or computer-readable medium for configuring a computer system to execute the method. The software modules may be stored within and/or transmitted to a computer system memory to configure the computer system to perform the functions of the module.

The computer system 500 normally processes information according to a program (a list of internally stored instructions such as a particular application program and/or an operating system) and produces resultant output information via input/output (I/O) devices 505. A computer process typically includes an executing (running) program or portion of a program, current program values and state information, and the resources used by the operating system to manage the execution of the process. A parent process may spawn other, child processes to help perform the overall functionality of the parent process. Because the parent process specifically spawns the child processes to perform a portion of the overall functionality of the parent process, the functions performed by child processes (and grandchild processes, etc.) may sometimes be described as being performed by the parent process.

In other examples, such as described above, the payment processing device is formed of multiple computer systems interacting, for example, via a distributed network arrangement. As distributed networking is known in the art. it will not be described further in more detail. A specific example of the interactions involved in processing a merchant transaction using the system of Figure 2 will now be described with reference to Figure 6. For the purpose of this example, the proxy account or card issuer is a hotel and at check-in, guests are provided with a hotel card which is then linked to a personal card of the user for the duration of their stay at the hotel.

In this example, the parties involved include a merchant 600, a merchant acquirer 610, a card service provider in the form of a payment network 620, a user card issuer 630, a hotel card issuer 640 and a customer 650. The merchant acquirer 610 is a bank that processes and settles a merchant's credit or debit card transactions with the help of the card issuers 630, 640 which represent financial institutions, banks, credit unions or companies that issue or help issue cards to cardholders, such as customers and hotels. The payment network 620 is typically a card network, such as Visa ^® , MasterCard ^® or other similar network that act as an intermediary between the acquirer and the issuer to authorize credit card transactions.

It will be appreciated that the merchant will utilise a merchant terminal

210.2, whilst the acquirer 610. a payment services provider network 620 and issuers 630, 640 will each have a number of typically networked processing systems, in the form of respective servers 230, 240, 250, 260. For the purpose of the following explanation, it will be assumed that actions performed by each of the parties are performed at least in part by the relevant terminal or server.

An example transaction process typically commences with the merchant 610 and customer 640 agreeing on a transaction, typicall in response to a customer purchase of goods or services, with the merchant entering details into the merchant terminal 210.2, before reading the customer's credit card (which in this example is a hotel card). At this point, an authorisation process is performed, with an authorisation request being transferred from the merchant terminal 210.2, via the acquirer 610 to the payment network 620. The payment network 620 then modifies the authorisation request so that it is first routed to the user account issuer 630 instead of the hotel account i ssuer 640 as would occur in a normal transaction process involving payment on the hotel card. The modified authorisation request is changed from a purchase authorisation request to an incremental pre-authorisation request for the purchase amount. The user account issuer 630 then approves the incremental pre- authorisation request and sends an approval message back to the payment network 620. The payment network 620 then proceeds to send an authorisation request to the hotel account issuer 640 along with a transaction identifier. Assuming the transaction meets relevant criteria, the hotel account issuer 640 returns an authorisation code to the merchant terminal 210.2, via the payment network 620 and acquirer 610, allowing the transaction to proceed.

Once approved, the transaction is performed, with details of the completed transaction being added to a payment batch, which in general is processed on a daily basis. The batch is forwarded to the acquirer 610, which then generates payment files, including a payment file for the hotel account issuer. The payment file is transferred to the hotel account issuer 640, via the card network 620, allowing the hotel account issuer 640 to pay the acquirer.

Once the payment has cleared, the acquirer pays the merchant by crediting the merchant account the transaction amount less the merchant services fee.

A customer may perform multiple transactions using the provided hotel card with multiple merchants during their stay with the hotel. Each individual merchant transaction is processed as an incremental pre-authorisation on the customers' personal card which is settled at check-out from the hotel when the customer returns their hotel card. The interactions involved in processing a completion transaction between the hotel and customer will now be described with reference to Figure 7.

In this example, the parties involved include a hotel 700, a hotel acquirer 710, a card service provider in the form of a payment network 720, a user card issuer 730, a hotel card issuer 740 and a customer 740.

Typically, the customer 750 will present their user card to the hotel 700 who will read the user's card at a hotel terminal 210.1 and enter completion details into the terminal. A pre-authorisation completion request for the total amount spent using the hotel card will be sent to the user card issuer 730 via the hotel acquirer 710 and card network 720. The user card issuer 730 will recognise that the request is a final completion request for all of the incremental pre-authorisations made against the user card. The user account issuer 730 will then send an approval message to the payment network 720. The payment network 720 then proceeds to send the completion request to the hotel account issuer 740 who returns an authorisation code to the merchant terminal 210.1, via the payment network 720 and acquirer 710, allowing the transaction to proceed.

Once approved, the transaction is performed, with details of the completed transaction being added to a payment batch, which in general is processed on a daily basis. The batch is forwarded to the acquirer 710, which then generates payment files, including a payment file for the user account issuer 740. The payment file is transferred to the user account issuer 740, via the card network 720, allowing the user account issuer 740 to pay the acquirer 710 or alternatively the hotel account issuer 740.

Once the payment has cleared, the hotel acquirer or hotel account issuer pays the hotel by crediting the hotel account the transaction amount less the merchant services fee.

An example of a specific process of performing one or more merchant transactions using a hotel card and performing a single pre-authorisation completion transaction with a hotel using a user card shall now be described with reference to Figures 8A to 8C.

In this example, at step 800, a user checks in at a hotel and is provided with a hotel credit or debit card for the duration of their stay for use in making purchases with. The hotel card may have an associated online account that the user is granted access rights to for the purpose of linking the hotel card to a user card, viewing offers available with merchants, making online purchases and viewing transactions made.

At step 805, the hotel card is linked to a user card. In one example, this is done through the online account or alternatively is facilitated by the hotel. Link data is typically created during the linking process and stored on a link server 220 or database 221 along with link data for all of the other hotel cards linked to guest's personal cards. In one example, a database 221 stores account information including account numbers, name on card, expiry date of card, CVV number etc. for each of the hotel card and user card.

At step 810, the user card issuer 250 approves the linking for example by verifying that the user card is not lost or stolen. As part of the linking process or subsequent thereto, the hotel may perform an initial pre-authorisation on the user card, typically a zero-value pre-authorisation for the purpose of obtaining parameters such as approval codes and a transaction identifier that will be used for subsequent merchant transactions and/or final completion.

At step 815, the user performs a purchase with a merchant using the hotel card. The merchant and user agree on a transaction, typically in response to a user purchase of goods or services, with the merchant entering details into the merchant terminal 210.2, before reading the hotel card. At step 820, the merchant acquirer 260 sends the transaction request to the payment network 820 which then determines a link between the hotel card and user card. The payment network 820 will typically look up the hotel card in the link server 220 or database 221 and retrieve details of the linked user card. After retrieving the linked card details, the payment network 820 will modify the transaction request to be an incremental pre- authorisation request which is routed to the user card issuer 250 at step 830.

The user card issuer 250 then verifies that the user account has sufficient funds to cover the transaction amount and sends a pre-authorisation approval back to the payment network 230 at step 835. The payment network 230 then sends a purchase transaction request to the hotel card issuer at step 840. The hotel card issuer 840 will then approve the transaction request and return an authorisation code to the merchant terminal 210.2, via the payment network 230 and acquirer 260, allowing the transaction to proceed. At step 850, the transaction is completed in accordance with the standard settlement and clearing processes and the merchant is paid.

The process then repeats and returns to step 815 each time the user performs a transaction with a merchant. At check-out from the hotel, the user returns the hotel card and a pre-authorisation completion is performed with the user card at step 855. The user card issuer 250 will approve the pre-authorisation completion and route an approval back to the card network 230 who then sends the completion request including an indication of the user card issuer approval to the hotel card issuer 240. The hotel card issuer 240 then sends an approval to the hotel terminal 210.1 via the payment network 230 and hotel acquirer which causes funds to be transferred to the hotel from the user account issuer 250 via the hotel acquirer.

An example of a specific process of performing a transaction between a user and a merchant using a hotel account shall now be described with reference to Figures 9 A to 9B. In this example, the method is performed by card service provider processing system (i.e. card network) 230. At step 900, the method includes receiving a transaction request from a merchant. The transaction request will be typically be generated by a merchant terminal 210.2 and be routed through a merchant acquirer 260 to the payment network 230. The transaction request will be indicative of a purchase transaction request for a transaction amount and will include a hotel card identifier.

The card network 230 will determine the hotel card identifier from the transaction request at step 905 and in response will use the hotel card identifier to retrieve user account information from a server 220 or database 221 as previously described where card linking data resides. In this way, the card network 230 recognises that the hotel card is linked to a user card. At step 915, the card network 230 modifies the transaction request so that it is first routed to the user account issuer 250 at step 920 instead of the hotel account issuer 240. The modified transaction request is changed from a purchase transaction request to an incremental pre- authorisation request for the purchase amount and will include a transaction identifier so that the user card issuer 250 can recognise that the transaction is related to a previous pre-authorisation.

At step 925, the card network 230 receives a pre-authorisation response from the user account issuer 250 and at step 930 the card network 230 determines whether the pre-authorisation request was approved or declined by the user card issuer 250. If the request is declined then the transaction is declined at step 935 and a declined response will be sent back to the merchant terminal 210.2. If approved, then the method proceeds to step 940 whereby the card network 230 sends a purchase request to the hotel account issuer 240. At step 945, an approval is received from the hotel account issuer 945 and in response the card network 230 sends an approval response to the merchant acquirer 260 who in turn sends the response to the merchant terminal 210.2. The transaction is then completed at step 955 and the merchant will be paid by the hotel account issuer in accordance with standard payment processing as previously described.

In one example, the above described system involves changes to standard payment processing messages sent between acquirer, card network and issuer entities involved in the transactions. Examples of such modified transaction requests are provided in Figures 1 OA- I OC. Figures 11 A-l 1C and Figure 12.

Figures 1 OA- IOC relate to an initial pre-authorisation request made by the hotel on the user card. In Figure 1 OA, there is shown a pre-authorisation request generated by the hotel terminal and including data element DE-002 which represents a user card identifier (such as the user card number), DE-003 which is assigned a value of 16 to represent incremental pre-authorisation, DE-004 which represents a zero dollar initial pre-authorisation and DE-126 which represents a hotel card identifier (such as the hotel card number). The payment network 230 then creates a transaction identifier which is included in the pre-authorisation request at DE-063 as shown in Figure 10B and this request is sent to the user card issuer 250.

The pre-authorisation response sent by the user card issuer 250 is shown in Figure IOC and this response includes DE-003, DE-063, DE-126 and an approval code at DE-038. This response is sent to hotel card issuer and back to the hotel terminal. When the final completion is sent, the hotel acquirer 260 needs to include the approval code at DE-038 from the response shown in Figure 10B along with DE-032, DE-041, DE-063 and DE-037. If not otherwise defined, these data elements are as defined in the IS08583 standard for message formats used in payment transactions.

Figure 11 A to 11C relate to transaction messages involved in a purchase transaction between a user and merchant using a hotel card. In Figure 1 1 A, there is shown a purchase transaction request originating from a merchant terminal 210.2. The purchase transaction request includes data elements DE-002 which represents a hotel card identifier such as a hotel card number, DE-003 which represents a purchase transaction and DE-004 which represents the transaction amount. The payment network 230 receives this request and then generates a modified transaction request shown in Figure 1 IB. This is a request for incremental pre-authorisation that is sent to the user card issuer 250. In this request, DE-002 is modified so as to represent a user card identifier, DE-003 is modified and assigned the value 16 so as to represent an incremental pre-authorisation, DE-063 is included which represents the transaction identifier and DE-126 is also included which represents the hotel card identifier. This is a new technical solution to implement incremental pre-authorisation so that whenever the user card issuer receives this request with processing code DE-003 as 16 and with DE-126, it will identify it as a request for incremental pre-authorisation.

Once the card network 230 receives an approval from the user card issuer 250, it will send the purchase transaction request as shown in Figure 1 IC to the hotel card issuer. In this request, data element DE-002 represents the hotel card identifier, DE-003 represents a purchase transaction, DE-004 represents the transaction amount and DE-063 is included which represents the transaction identifier. Once the hotel card issuer approves this transaction, an approval response is sent to the merchant via the card network 230. For every merchant transaction, the card network 230 will include the transaction identifier at DE-063 so that the user account issuer 250 recognises that the request is a further incremental pre- authorisation request that is associated with all previous requests. In this way, all of the pre-authorisations form part of the same final transaction which is settled with the hotel so that the user only pays a single bill at the end of his stay.

Finally, in Figure 12 there is shown a completion message (0120) generated by the hotel acquirer 260 which is sent to the user card issuer 250 via the card network 230. The completion message is for all of the incremental pre- authorisations made against the user card. The completion message will include data elements DE-002 which represents the user card identifier, DE-003 processing code 16 which represents incremental pre-authorisation, DE-004 which is the final amount of the bill which represents the sum of all of the pre-authorisations, DE-038 which is the approval code generated by the user account issuer during the initial pre- authorisation request from the hotel, DE-063 which represents the transaction identifier along with DE-126 which represents the hotel card identifier. The DE-003 processing code 16 and the DE-126 hotel card identifier will help the card network 230 and user account issuer 250 identify this request as being the final completion for all of the pre-authorisations.

It is to be appreciated that in at least one example, the above described method and system enable customer's of a hotel or travel agency and the like to make multiple merchant transactions with a proxy card whilst pre-authorisations are being processed on their own personal card linked to the proxy card. In this regard, the customer can perform multiple transactions with multiple merchants during their travel or stay at a hotel but only have to perform a single transaction with the hotel or travel agent and thereby receive a single bill and receipt for their trip which makes reimbursements easier for business and the like. Customers are also more likely to perform card transactions owing to the reduced risk of card fraud on their own card and potential offers that may be made available by merchants to customers who have a proxy card. The hotels and travel agencies will attract more customers and every transaction performed by the customer will be a transaction performed on one of their cards which provides certain benefits such as accumulation of points and the like.

Furthermore, there are additional benefits to the issuing banks as more cards will be issued to hotel, travel agencies and the like to accommodate their guests and customers and more profits will be made through transaction fees and the like. Every guest of the hotel or customer of the travel agency essentially becomes a customer of the issuing bank of the hotel or travel agency cards. The card service providers will also benefit from increased number of transactions using credit or debit cards instead of cash.

Whilst the above examples have focussed on hotel and travel agency scenarios where proxy cards may be used during travel, particularly in foreign countries, it is to be understood that the method and system could also be

implemented locally by suitable entities who wish to act as a proxy between the customer and merchant.

Throughout this specification and claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated integer or group of integers or steps but not the exclusion of any other integer or group of integers.

Persons skilled in the art will appreciate that numerous variations and modifications will become apparent. All such variations and modifications which become apparent to persons skilled in the art, should be considered to fall within the spirit and scope that the invention broadly appearing before described.