GB2482665A

GB2482665A - On-board vehicle payment system

Info

Publication number: GB2482665A
Application number: GB1012812.2A
Authority: GB
Inventors: Ciaran Bernard
Original assignee: MAKALU TECHNOLOGIES Ltd
Current assignee: MAKALU TECHNOLOGIES Ltd
Priority date: 2010-07-30
Filing date: 2010-07-30
Publication date: 2012-02-15
Also published as: GB201012812D0

Abstract

An on-board vehicle payment system configured for processing payments conducted on an aircraft is described. The system is configured to associate a passenger identifier, for example a booking reference or boarding card, with authorized credit to enable and facilitate cashless transactions conducted on a flight. The authorized credit may be pre-paid 405 by the user or given to the user in a reward mechanism. The passenger identifier is stored in association with the authorized credit value. When a payment request, including an identifier and a payment value, is received from an on-board POS, the received identifier is compared 460 to the stored passenger identifier(s). Upon identification of the passenger, the value of the payment is deducted from the authorized credit value.

Description

System and method for secure wireless payment transactions

Field

The present application relates to security and more particularly to improving the security associated with payment transactions. The invention more particularly relates to improving the security associated with the use of cashless financial instruments in an aviation environment.

Background

A typical non-airline specific credit card transaction is shown in Figure 1. In step 100 a customer presents their credit card in payment for the authorisation to a merchant. The information relating to the credit card may be extracted from the credit card using an electronic point of sale (POS) device which is configured to read at least one of a magnetic stripe provided on the credit card or a chip that is embedded in chip-and-pin credit cards. The POS device may be provided as a portable device that either transmits the extracted data wirelessly back to a docking station or on re-docking the portable device with the docking station initiates a transfer of the extracted information. Typical information that is unique to each card and which is extracted is the combination of the credit card number, the expiry date of the card and the credit card CCV number which is used for Card/Cardholder Not Present' (CNP) type transactions. In addition to this transaction specific information such as the cost or value of the transaction being conducted is associated with the transaction.

In step 120 the authorisation process is initiated whereby the merchant submits the details of the transaction to the clearing house. The clearing house may be considered the financial institution that accepts payments on behalf of the merchant or resellers of those services. The clearing house verifies the credit card number, the transaction type and the amount with the issuer -typically the card-issuing bank-and if there is available credit associated with that specific account for the value of the transaction reserves that value for the merchant. An authorization will then be generated which may be in the form of an approval code which then may be stored or associated with the transaction by the merchant. The receipt of an authorisation code typically is sufficient to conclude the transaction from the perspective of the customer. The merchant is also satisfied in that the presented card has been authenticated against a third party.

At periodic intervals, step 130, authorised transactions which have been concluded by the merchant with one or more customers are processed in a batch arrangement. This process is known as batching and involves the transmission of a plurality of authorized transactions from the merchant to the clearing house. Such periodic intervals are typically at the end of the business day or some other pre-set interval.

The clearing and settlement process is then initiated by the clearing house (step 140) whereby the batch transactions are entered into a process whereby the issuing bank of the credit card pays the clearing house for the transaction where the payments are then associated with the merchant account.

It will be appreciated that steps 120-140 can be effected after the conclusion of the transaction but in order for authorisation to successfully provide the necessary security to the merchant, the authorisation process should occur prior to the handing over of the goods or service being paid for.

However, the provision of such a real-time authorisation requires a communication channel between the merchant and the clearing house at the time of purchase. When providing products or services in-flight, the requirement for such a communication channel has traditionally deterred the airlines from implementing such credit card payment solutions and the airline merchant was reimbursed through the use of cash paid by the passenger. However cash-based transactions have associated problems and a need therefore arose for a credit card and debit card solution for in-flight payments.

In many implementations, airlines accept credit card payments whereby a passenger will present their credit card during the flight for payment of the goods received. Many of these known solutions are implemented without implementing real-time authorisation of the transaction. As a result while there is a desire to adopt the efficiencies of using card based payments, credit card fraud, disputed transactions and passengers unintentionally defrauding the airline by spending beyond their credit limits are costing the airline industry between 450 and 600 million per year. To counter these problems most airlines impose a limit on credit card transactions to minimise the potential losses from fraud, and most aren't in a position to accept payments from debit cards.

Some known solutions replace the conventional wired or land-line communication to the clearing house through the use of a data channel provided using a satellite phone. However, the use of a satellite communication channel between the airplane and the financial clearing house to implement a conventional clearing transaction in-flight while potentially reducing the losses adds significant cost to each transaction.

There is therefore a need for improving the security associated with cashless transactions conducted in-flight.

Summary

These and other problems are addressed in accordance with the present teaching by providing a system and method that interfaces with a conventional credit card transaction and segments the data that is conventionally distributed such that reduced amounts of data are transmitted during periods of narrowband only interface between the aircraft and the clearing house. By reducing the number of times that data that needs to be transmitted using satellite communication channels, the usage of the satellite channel may be reduced. Another benefit that arises is that real-time authorisation can be achieved for the transaction being conducted. Additional data transfers between the aircraft and the clearing house may be postponed till periods where larger capacity data communication channels are available.

Accordingly, the present teaching provides a system as claimed in the independent claim. Advantageous embodiments are provided in the dependent claims.

Brief Description Of The Drawings

The present application will now be described with reference to the accompanying drawings in which: Figure 1 is a typical process flow involved in credit card authorisations Figure 2 is a schematic showing functional network components and communications between same in accordance with a system and methodology provided in accordance with the present teaching.

Figure 3 shows a process flow associated with another embodiment in accordance with the present teaching whereby two transactions are compared against one another for authentication purposes.

Figure 4 shows a schematic for loading credit for subsequent use in accordance with the present teaching.

Detailed Description Of The Drawings

Figure 1 has been described with reference to prior art methodologies.

Figure 2 shows in schematic form a network architecture configured in accordance with the present teaching for effecting cashless or card-based payment transactions within the airline environment. The present teaching is particularly related to the authorisation process that is used at the time of sale for ensuring that a presented card for a transaction is a valid card for that transaction. The definition of valid may include one or more of that card being a legitimate card (i.e. not stolen or fabricated) or having a sufficient credit limit necessary for the transaction in situ. Other similar parameters that will be necessary for authorisation of a transaction will be appreciated by those of skill in the art.

Within the aircraft, a point of sale (POS) terminal (200) is used to capture details of a credit card for payment purposes. Such POS terminals will be appreciated by those of skill in the art and can be provided as fixed or wireless devices capable of reading data from a presented credit card. As part of the transaction process, the POS device on the aircraft captures the credit card details in a traditional fashion. The specific information relating to this one transaction are then relayed from the POS terminal 200 to a processing server 210 provided on-board the aircraft. On receipt of these details, the aircraft server 210 may be configured to generate a hash of the transaction for use when the response is received from the clearing house. This hash if generated is stored as a key along with the POS identifier with a datastore associated with the server 210. It will be appreciated that by associating the hash of the transaction with the POS identifier that the server 210 may trace the transaction back to the specific POS device that was used to capture the card details initially.

The processing server is configured to generate a data packet from the presented information relating to the transaction into a form suitable for transmission over a narrowband network such as a satellite data communication channel. The generation of such a condensed data file, typically having a size of about 30 bytes or the like may be effected in accordance with the present teaching by having within that data packet the least amount of information necessary to identify that transaction including for example credit card number, expiry date, card holder name, CCV and the value of the transaction. The data is compressed using different compression techniques depending on the data field and may also be optionally encrypted using encryption algorithms such as 3DES.

The processing or aircraft server includes a data modem 211 configured for transmission and receipt of data over a satellite communication protocol. It will be appreciated that such a modem 211 will typically be uniquely identifiable through provision of an International Mobile Equipment Identity (IMEI) number that is specific to that satellite modern. Any other unique identifier could also be used to link and data originating from that modem.

The modem is configured on generation of the data packet described above to transmit that data packet in a first transaction 1 over the wireless channel provided by the satellite transceiver. As the data volume is reduced through inclusion of only specific information relating to the card and the transaction, the size of this packet is also reduced. In contrast to prior art authorisation techniques the transmitted data packet is not routed directly to the clearing house for the traditional authorisation steps but rather is transmitted to a dedicated land-based or ground server 220 where the content of the data packet is processed further-step 2.

As part of this processing the packet is decompressed and decrypted as necessary. Additional information such as orderid, terminalid, datetime, card type (if not included in the original message received from the aircraft server), currency, terminal type, transaction type are then loaded into the packet. As the ground server can identify the origin of the data packet through for example the IMEI number of the device used to transmit the data file from the aircraft, the ground server may be configured to use this information through a look up routine or the like to embed into the new larger data packet specific information relating to the merchant. This is particularly useful where the same ground server is used to process transactions from a plurality of different aircraft or airlines. By extracting stored specific information relating to the merchant from an identifier associated with the data packet received, the ground server 220 can then integrate this additional information into a new data packet for relay onto the clearing house. As shown in Step 3, this new data packet is then sent to the bank payment gateway (Step 3) for processing in the usual fashion, similar to conventional processing of card not present payments. The activities within this clearing house will typically be conventional in type as will be appreciated by those of skill in the art. Once a transaction is authorized, the transaction is sent back to the ground server (Step 4).

Once received back at the ground server, the packet is processed again to reduce the size of the packet for relay back to the aircraft server. A hash function may also be generated similar to that executed by the aircraft server discussed above. This processing of the packet-Step 5-results in a reduced payment authorization packet being then sent back to the aircraft (Step 6) which may optionally also include the newly generated hash function to provide the authorization necessary. The generated message may be compressed and encrypted prior to transmission over the satellite channel to the aircraft server.

The destination is determined using the IMEI code or the other unique identifier if that was used, associated with the originally received message from the aircraft server.

On receipt back at the aircraft server, the message is decompressed and decrypted. The received hash function is checked against the previously stored hash function to determine which of the plurality of available POS devices originated the transaction and once determined, the authorisation (or failure to authorise) is transmitted back to that POS device for completion of the transaction. If there is only one POS device within a specific aircraft the hash identifiers may be dispensed with for selection of an appropriate POS device albeit it can still be useful as a tracking or log of the transactions conducted. It will be appreciated that by reducing the size of the data packet that is sent between the aircraft server and the ground server such that transmission times over the available narrowband communication channel that is available on a satellite link that the round trip authorisation time may be reduced. Typical time that are achievable using a system in accordance with the present teaching is less than 30 seconds for complete authorisation which will be appreciated is an acceptable time for concluding a transaction.

It will be appreciated that the ground server acts as an intermediary between the aircraft server 210 and the traditional clearing house 230. Being located within the communication path between the two, the ground server is configured to receive and route communications between the two. However as opposed to providing a simply routing function, the ground server processes the data packets prior to its relay in one or both of the two directions. By modifying the data that is included within the packets-either by inclusion or reduction of the information that forms part of that packet, the ground server ensures that the size of the packet that is sent from and received at the aircraft server over the available narrowband communication channel can be kept to a minimum.

This reduction in size increases the speed of transmission and also reduces the chance of the data being dropped in transit. This can be used to ensure that the authorisation process that is used to conclude a transaction being put through the POS device can be efficient as possible with the amount of data transmitted and kept as quickly as possible.

As will be appreciated from Figure 1 and its discussion of additional steps that are included as part of a credit card transaction, typically at periodic intervals authorised transactions which have been concluded by the merchant with one or more customers are processed in a batch arrangement. This process is known as batching and involves the transmission of a plurality of authorized transactions from the merchant to the clearing house. Such periodic intervals are typically at the end of the business day or some other pre-set interval. Within the context of the present teaching the aircraft server 210 may be configured to store the authorised transactions for relay to the clearing house at time periods when the communication channels available between the aircraft are of higher capacity than available using the satellite based communication channel. For example at times when the aircraft is land based during for example refuelling or when the aircraft is laid up, the aircraft server may be configured to use a separate communication channel to that of the satellite communication used for communications 1 and 6, such a wireless GSM link or a wireless internet link to initiate the transfer of data relating to the batch process to one or both of the ground server 220 or clearing house 230. If a direct communication 7 is effected to the ground server then that could subsequently process that batch data file and relay it to the clearing house for processing in a traditional fashion. As these channels 7,8 are of higher capacity than the satellite channel the stripping of data out prior to dispatch from the server is not necessary.

Figure 3 shows an alternative process flow that may be used in improving the security of credit card transactions that are conducted on an aircraft. This process flow can be used independently or in combination with the process flow described above with regard to Figure 2. In this exemplary arrangement a previously authorised credit card transaction is then used to authenticate a later transaction.

As shown in Figure 3 a user presents a credit card for payment of an airline ticket (step 300). As the transaction is land based, the receipt of the credit card details allows the airline at the time of processing the ticket to authorise the credit card in a usual fashion (step 310)-such as what was described in Figure 1 with reference to steps 100 and 120. On receiving an authorisation from a clearing house that the presented card is authorised for the transaction, the server-which may be the ground based server 220 of Figure 2, creates a 1-way hash function of the details of the credit card (step 320). It will be appreciated that a 1-way hash function is exemplary of the type of mathematical function that generates a unique identifier output from an input string.

This unique identifier -which in itself bears no visual resemblance to the originating card details and as such whose transmission does not compromise card integrity-can then be relayed to the airline server 330 of Figure 2 for storage (Step 330).

During a flight, a passenger who has booked and paid for a ticket using a credit card, presents their credit card for payment of goods on the aircraft-such as for example food or drink or duty free products (step 340). In order to authenticate that card as being a legitimate card associated with that person, the details of the card are then processed to generate a 1-way hash function of that card (Step 350). This may be effected at a suitably configured POS device that has been enabled in accordance with the present teaching to generate this processing of the card details. In another configuration the details are relayed from the POS device to the aircraft server where the hash function is generated.

Two 1-way hash functions generated from the same input string using the same mathematical function should produce the same identical output. In this way comparison of the generated 1-way hash function of an authorised card that has been relayed to and stored at the aircraft server (step 330) with the newly presented card can be used to provide an indicator that the newly presented card is a legitimate card (Step 360).

It will be appreciated that as part of this authentication process that as opposed to trying to authenticate against a ground based clearing house, the presented teaching uses hash functions of cards presented at two different times and authenticates a transaction based on a later generated card on determining that that card matches a previously authorised transaction effected using the same card. It will be appreciated that this match allows a determination as to whether to authorise the later transaction or not. If there is no match-which may arise for example in scenarios where the user uses two different cards for the two different transactions, then a methodology in accordance with Figure 2 could be implemented to effect a ground based authorisation process for that later presented card. It will be appreciated that where a methodology in accordance with Figure 3 is implemented prior to one in accordance with Figure 2, then the volume of traffic that needs to be effected using the satellite communication channel in flight can be reduced.

Figure 4 shows an alternative process flow that may be used in conducting cashless payments on an aircraft. This process flow can be used independently or in combination with the process flow described above with regard to Figure 2 and/or Figure 3. This process flow addresses two specific problems associated with in-flight credit card transactions. One is how to authorise a cashless payment that is effected in-flight. The other is how to minimise the number of authorisations required by the airline where a specific card is used for multiple transactions.

In this exemplary arrangement a booking reference or boarding card that is uniquely associated with a specific flight and user may be associated with credit that was for example pre-paid for by that user when paying for their flight or has been given to the user as a reward mechanism (for example as part of a frequent flyer program). In an exemplary configuration discussed with reference to Figure 4, at the time of booking a flight (Step 400) the user is prompted as to whether they wish to pre-purchase credit for subsequent use (Step 405). On receiving confirmation that they would like to do so, the dual transaction is combined as part of a single authorisation process (Step 410). This reduces the requirement to conduct multiple authorisations between the merchant (in this case the airline) and the clearing house for the same credit card.

On receiving authorisation that the payment is authorised, the system is configured to associate this additional amount with the boarding card that would be uniquely associated with that user and flight. The system-which may be implemented as a component or module on the ground server 220-is configured to de-personalise the personal information associated with the transaction by providing a 1-way hash function of the passenger details and booking details together with a value amount associated with the credit pre-purchased (Step 420). In another configuration the credit card details that were used for the transaction could be used as the input string for the 1-way hash function.

This data string is then sent to an aircraft server 210 for use during the flight (Step 430). The data link can use broadband or similar technology to effect the transfer to the grounded aircraft at any time prior to the flight. When the passenger desires to purchase a product during the flight they present their boarding card or credit card or debit card as an alternative identifier (Step 440) and a similar 1 way hash function generates a key (Step 450) that can be compared with the stored server data (Step 460) to ascertain whether that passenger has preloaded credit. If they do, that can be deducted from their preloaded amount to effect payment. The use of the hash de-personalises the data that is transmitted. It will be appreciated that when the credit card details are used that the subsequent presentation of the credit card is not used as part of a conventional credit card transaction but rather as a unique identifier associated with the user to retrieve preloaded credit that was previously paid using that card.

Similarly to that described with regard to Figure 3, the second generation of the hash function may be effected at a suitably configured POS device that has been enabled in accordance with the present teaching to generate this processing of the input string. In another configuration the details are relayed from the POS device to the aircraft server where the hash function is generated.

The two 1-way hash functions generated from the same input string using the same mathematical function should produce the same identical output. In this way comparison of the generated 1-way hash function of the data presented during the flight can be compared with that previously relayed to and stored at the aircraft server to determine whether that passenger has authorised credit or not. If they do then the aircraft server maybe configured to deduct that credit by the amount associated with the transaction and to store the new amount for subsequent use.

To ensure the user has the full use of the credit that they have pre-loaded the aircraft server may be configured to relay the updated amounts associated with that user to the ground server when the two are back in broadband or similar communication. This can then be relayed to another aircraft server for subsequent use by the same passenger during another flight.

It will be appreciated that by using the credit card or debit card to both load credit and then retrieve that credit, a system configured to implement the methodology in accordance with Figure 4 could be used in combination with the methodology described with reference to Figures 2 or 3. In the determination that a presented card is not preloaded with credit or has insufficient credit for the transaction, the aircraft server may be configured to implement an in-flight transaction authorisation per the teaching of Figure 2 or 3.

It will be appreciated that examples of a system and method for improving the security associated with payment transactions have been described. In accordance with the present teaching it is possible to improve the security associated with the use of cashless financial instruments in an aviation environment and provide an in-flight authorisation of payment cards used in transactions on that flight. By providing a payment server on board the aircraft, the system is configured to reduce number of times it is necessary to effect an in-flight communication to a clearing house for authorisation purposes of a payment card. It will be understood that while the present teaching has benefit and application in an aviation environment that it can be used in the context of any vehicle where communication channels are limited.

The words comprises/comprising when used in this specification are 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

Claims 1. An on-board vehicle payment system configured for processing payments conducted on a vehicle, the system comprising: A data store configured to receive and store identifiers associated with one or more individual passengers of the vehicle and an associated authorised payment value for each of the one or more individual passengers; An input for receiving a payment request from a point of sale device located on the vehicle, the payment request comprising a presented identifier associated with an individual conducting a payment at the point of sale device and a value for the payment; A comparator for comparing the presented identifier with the stored identifiers to identify an individual user within the data store and on identification of that user deducting the value for the payment from the authorised payment value.
2. The system of claim 1 wherein the received and stored identifiers result from transactions conducted by those individuals at a prior occasion.
3. The system of claim 3 wherein the received and stored identifiers result from a payment effected by those individuals when paying for the ticket for the vehicle.
4. The system of any one of claims 1 to 3 wherein the stored identifiers are mathematical representations derived from at least one of a booking reference or payment card used by the user.
5. The system of any one of claims 1 to 4 wherein the vehicle is an aircraft and the system is configured to populate the data store during periods when the aircraft is grounded.
6. The system of any one of claims 1 to 5 wherein the system is configured on completion of a journey effected by the vehicle to transmit from the first data store details of transactions conducted during that journey.
7. The system of any preceding claim further configured for authorising a payment transaction effected at a point of sale device, the system comprising: Means for receiving details of a payment card for a first payment transaction; Means for authorising the first payment transaction; Means for creating a mathematical function output from details of the authorised payment card; Means for using the mathematical function output in authorising a subsequent payment transaction effected at the point of sale device.
8. The system of claim 8 configured on operable computation of the mathematical function output to store the mathematical function output in the data store within the vehicle.
9. The system of claim 8 configured on using the mathematical function output to: generate a second mathematical function output from the payment card used in the subsequent transaction; compare the second mathematical function output with the stored mathematical function output; and authorise the subsequent payment transaction on effecting a positive comparison between the second mathematical function output and the stored mathematical function output.
10. The system of any one of claims 8 to 9 wherein the mathematical function output is resultant from a hash function.
11. The system of any preceding claim further configured to authorise a payment transaction effected at a point of sale device within a vehicle using a payment card, the system comprising a first processing server configured to: receive from the vehicle a first data message comprising details of a card transaction conducted at the point of sale device; generate an authorisation request for the card transaction, the authorisation request comprising data from the first data message and additional data previously stored at the first processing server; forward the authorisation request from the first processing server to a clearing house and on receipt of a confirmation request back from the clearing house generate a second data message comprising an authorisation code; forward the second data message to the vehicle, the authorisation code being relayed to the point of sale device to effect the authorisation of the transaction.
12. The system of claim 11 wherein the first data message is received over a satellite communication channel.
13. The system of claim 11 or 12 wherein the second data message is forwarded over a satellite communication channel.
14. The system of any one of claims 11 to 13 wherein the authorisation request is not sent over a satellite communication channel.
15. The system of any one of claims 11 to 14 wherein the server is configured to use details of the first data message to identify the source of the first data message.
16. The system of claim 15 wherein the server is configured to use the source of the first data message in identifying the additional data previously stored.
17. The system of claim 15 or 16 wherein the first data message is associated with an IMEI identifier used in transmitting the first data message to the first processing server.
18. The system of any one of claims 11 to 17 wherein the server is configured, on receipt of the first data message to decompress the first data message.
19. The system of any one of claims 11 to 18 wherein the server is configured, on receipt of the first data message to decrypt the first data message.
20. The system of any one of claims 11 to 19 wherein the additional information comprises one or more of orderid, term inalid, datetime, card type, currency, terminal type, transaction type.
21. The system of any one of claims 11 to 20 wherein the first data message comprises data identifying the value of the transaction and at least one of card number, card type, expiry date, card holder name, and OW code.
22. The system of claim 21 wherein the first data message comprises two or more of card number, card type, expiry date, card holder name, and OW code.
23. The system of any one of claims 11 to 22 wherein the server is configured to generate a hash code from details associated with the transaction and include the hash code in the second data message.
24. The system of any one of claims 15 to 17 wherein the server is further configured to use the source of the first data message in determining the destination of the second data message.
25. The system of any one of claims 11 to 24 wherein the first vehicle is an aircraft.
26. The system of any preceding claim being further configured to authorise a payment transaction effected at a point of sale device within a vehicle using a payment card, the system comprising a vehicle processing server configured to: a) Receive from within the vehicle details of a card transaction conducted at the point of sale device; b) Generate a first data message, the first data message comprising details of the payment card used to conduct the transaction and the value of the transaction; c) Forward the first data message to a remote processing server, the remote processing server being operably configured to generate an authorisation request from the first data message for relaying onto a clearing house; d) Receive from the remote processing server a second data message comprising an authorisation code, e) Forward the authorisation code to the POS device for completion of the authorisation process.
27. The system of claim 26 further configured to compress the first data message prior to forwarding to the remote processing server.
28. The system of claim 26 or 27 further configured to decrypt the first data message prior to forwarding to the remote processing server.
29. The system of any one of claims 26 to 28 wherein the vehicle processing server is further configured to generate a hash code from details of the card transaction.
30. The system of any one of claims 26 to 29 further configured to store the hash code and a POS identifier for the POS from which the transaction originates.
31. The system of any one of claims 29 to 30 further configured, on determination that the second data message comprises a hash code, comparing the received hash code with the stored hash code to determine which POS device to forward the authorisation code.
32. The system of any one of claims 26 to 31 further configured, on determination that the second data message is compressed, to decompress the second data message.
33. The system of any one of claims 26 to 32 further configured, on determination that the second data message is encrypted, to decrypt the second data message.
34. The system of any one of claims 26 to 33 wherein the first data message does not include data relating to one or more of orderid, terminalid, datetime, card type, currency, terminal type, transaction type.
35. The system of any one of claims 26 to 34 wherein the first data message comprises data relating to one or more of amount, card number, card type, expiry date, card holder name, and OW code.
36. The system of any one of claims 26 to 35 wherein the vehicle processing server comprises a satellite transceiver, the generation of the first data message comprising including an identifier associated with the satellite transceiver.