GB2483051A - Ordering and paying for goods over a network using a mobile device - Google Patents

Abstract

A user places the goods from a merchant website he wishes to order in a basket and sends a message comprising the basket from his mobile device to a transaction gateway. The gateway verifies the identity of the user, transmits the order to the merchant site, sends a message to the user in response to a reply message from the merchant site, communicates with a payment service provider associated with the merchant to ascertain the status of a payment request from the merchant and to generate a message for the user based on a reply message from the payment service provider. This permits the number of entries required from the user to be significantly reduced, typically to very few, very simple ones, and to avoid any direct exchange between the user and the merchant, whose visual display is not optimized for mobile screens, and where the repeated calls will result in a high likelihood of a failed transaction.

Description

Transaction Gateway for mobile devices The invention relates to a transaction gateway which gateway facilitates payment with e-commerce merchants for users of any web enabled mobile device, such as a mobile telephone, within accepted payment industry security standards.

The electronic funds transfer (EFT) network is one of the most widely adopted point of sale equipment and is found in most small retail stores and businesses, and now at most e-commerce retailers. The electronic funds transfer network operates in compliance with international standards, currently, ISO/IEC 78 121:2000 and ANSI X4.13. Traditionally, the payment system was controlled by the major banking groups in any given country but in recent years a large number of payment service providers (PSP's) have been established to increase competition and facilitate merchant integration in this area.

A payment service provider is the link between a merchant and the merchant's bank.

Some payment service providers can provide payment terminals to brick-and-mortar businesses, whereas other PSP's exist purely as online operations processing payments for e-commerce websites. The execution of an online transaction therefore involves three active participants: the customer, the merchant and the PSP (and through the PSP, the transaction processor and the card issuer), in addition to the interactive digital communication streams between them.

Due to industry standards, communication between a retailer and a PSP is limited to a relatively short and simple sequence of data exchanges, in which each one-way exchange, or "call", can only generate a limited number of alternative replies, and each "reply" can only trigger a specific, pre-set next action. In short, "calls" between the merchant and its PSP consist of data exchanges expressed in a very universal programming language between two computers, without the need for any on-the-spot logic, or "intelligent" real time decision-making to ever intervene in the process. If a data exchange falls outside of the possible preset actions, the payment process will terminate as a failed transaction.

In striking contrast, a user placing an online order with a merchant, and then executing payment, will engage in a much more complex process.

1. Successfully completing a typical order and transaction usually requires a sequence of anywhere between 4 and 8 or more "calls" from the user to the merchant and back, depending on the merchant's payment platform and the type of goods purchased. The sheer number of calls makes online payment from a mobile device impractical, with too many pages to send and download even using a fast connection. This even without taking into account the likelihood of a signal drop if a user is attempting to make a transaction when moving on, for example, a train where signals are often dropped for a variety of reasons. This will result in a failed transaction.

2. Each call will send information entered by the user in several fields, most of which carry non-numeric data, i.e. words, which are more prone to incorrect entries.

3. Most importantly, placing an order and executing a transaction is a "dynamic" process, in which each step needs to be successfully completed and acknowledged as such by the merchant before the user can access the next step. Incomplete or non-conforming entries will trigger calls back from the merchant requesting corrections, and on-the-spot, "intelligent" decision making is required from the user throughout the process. However, due to the inherent limitations in payment industry standard software if a user shows too much initiative in correcting mistakes before being prompted by the merchant's payment software, such as going back one step, an error message will usually result and often frustratingly for the user at the very end of the process.

4. Finally, an extremely difficult barrier to executing transactions from a mobile device has recently been added in the form of 3D Secure Verification for online transactions by card issuers working with the Visa, MasterCard or JCB International networks.

With regards to how complex and how many data entries making an online purchase involves, various solutions have already been adopted for greater ease-of-use in online transactions on a PC, which partially address this problem. Users who complete a profile as they execute their first order with a merchant will usually have much less to do when they come to shop for a second time. Such a solution is disclosed in US5960411. This, of course, will be of no help when a user sets out to transact with a different merchant. Browsers now contribute as well by storing data entries from previous visits, which will often speed up filling in of fields. Browsers also ask users as a matter of routine if they want their password to be remembered for future visits on various sites.

Browser-generated help for payment information is unlikely to be part of the mobile internet future. 3G and WI-Fl transmission are not considered to be as secure, for both real and perceived reasons, as fixed line transmission. However mostly, it is much easier to forget or have one's mobile device stolen than a desktop computer or even a laptop, and allowing the browser-or the device itself-to remember too much is an inherently undesirable for payment security. The same consideration applies to merchants' storage of users' payment information, and it is worth noting here that current payment data storage practices at a great number of online merchants are not compliant with PCI (Payment Card Industry) security standards.

The dimension of the problem in offering an easy-to-use, fast and secure payment process for mobile users is illustrated by the large U.K. retailer Comet. Comet is one of the largest online merchant in the UK and launched in 2009 a mobile version of its website, without a payment solution. At launch, users were shown a phone number to call to order once they had selected an item; Comet now asks users to pick up the item in one of its brick-and-mortar stores and pay for the purchase there and then.

As for the 3-D Secure process, it involves one last, additional identity verification done by the issuer of the card and this request is delivered to the user in a window on the merchant checkout page that cannot be captured and/or re-formatted. This operation is impossible to perform on a mobile device that is not capable of zooming and scrolling in and across a non-optimized merchant page, and very difficult to perform, at best, on a device that can. It is the merchants decision to participate in these "Issuer Verified" programs (the incentive to participate is high though, as it affects the banks' guarantees on fraud).

Merchants have the option to "switch off' the verification and are compelled to do it for certain types of transactions, such as call centre transactions. At present most mobile device originating transactions happen on a switched off mode, and many large merchants even routinely switch off 3-D Secure on their website, as it lowers transaction conversion significantly.

Most existing mobile browsers present particular problems for 3-D Secure, due to the common lack of certain features such as frames and pop-ups. Even if the merchant has a mobile Web site, unless the issuer is also mobile aware, the authentication pages may fail to render properly, or even at all. Frames and pop-ups should gradually become the norm on mobile browsers, but as for issuers being mobile aware, this could take longer. A fully mobile 3-D interface is unlikely to come from the networks anytime soon, as 3-D Secure is only a very recent development, barely off the ground in many countries, and the focus for networks is still very much on having it implemented by issuers and merchants and adopted as a standard for online transactions.

The present invention seeks to provide a transaction gateway for use with a mobile telephone that overcomes the foregoing problems.

According to the invention there is provided a transaction gateway, which gateway is adapted to communicate with a payment service provider, merchant website and a mobile device, wherein when a user wishes to order goods from a merchant site, which order is placed in a basket, a message comprising the basket for the order is sent from the mobile device to the transaction gateway, which gateway is adapted to verify the identity of the user, wherein the gateway is adapted to transmit the order to the merchant site and to send a message to the user in response to a reply message from the merchant site and wherein the gateway is further adapted to communicate with a payment service provider associated with the merchant to ascertain the status of a payment request from the merchant and to generate a message for the user based on a reply message from the payment service provider.

The problem is solved with this three-way interactive gateway. This solution lies in the creation of a payment Gateway, which can be hosted in a PCI certified environment that holds interactive, dynamic exchanges with all three participants in the process and takes over most of the user's tasks. This permits the number of entries required from the user to be significantly reduced, typically to very few, very simple ones, and to avoid any direct exchange between the user and the merchant, whose visual display is not optimized for mobile screens, and where the repeated calls will result in a high likelihood of a failed transaction.

In contrast to other known online payment methods that implement an alternative payment method to facilitate the transaction, the invention facilitates online payment from mobile devices using existing payment routes and methods.

Exemplary embodiments of the invention will now be described in greater detail with reference to the drawings in which: Fig. 1 shows a schematic of a first customer transaction using the invention without 3D secure Fig. 2 shows a schematic of a first customer transaction with 3D secure verification Fig. 3 shows an alternative schematic for registration on the Gateway without making a purchase Fig. 4 shows a schematic for a further order with a merchant who does not support 3-0 secure Fig. 5 shows an alternative schematic for a further order with any merchant using a card that has been processed through the Gateway and 3-D verified.

The transaction gateway is agnostic to the interface used to search for and initiate an order. Examples of possible interfaces include using a third-party optimized-for-mobile search and display interface such as the one offered by Gofone Ltd. or Usablenet, or the user could have made use of the crude mobile optimization for display that comes with a very good smartphone that offers zoom and scroll functionalities over regular web pages, or it could have happened on the merchant's own mobile interface, such as is the case with Comet.

The Gateway is activated when a user first attempts to save an item in the basket that is integrated with the mobile search and display interface, or when a mobile user attempts to start a payment process from the merchant's basket, in which case the user is re-routed from the merchant's website to the Gateway for the whole payment process. The Gateway itself features two mobile interfaces for users. One for first time usage, where the user will enter all his relevant payment and shipping information, including one or several credit card numbers-credit card is to be understood in a generic sense as credit or debit card, PayPal account, bank account.

In a first example, the user uses an optimized for mobile search and display interface. This interface is integrated with the merchant's site as described below.

Figure 1 shows the process for first time use or use without registration for a site without 3D secure and in which the merchant places the calls to the payment service provider.

In the first step, once the customer has selected his items and been re-routed to the transaction gateway, he or she is invited to enter their customer details and the billing and delivery details in a conventional manner. These are then transmitted from the mobile device over SSL to the transaction gateway, which registers the order and saves the details in a database in step 4. The database should be PCI compliant as it holds payment details. The transaction gateway then transmits details of the order to the merchant.

The merchant then converts the basket, customer details and wallet into a receipt in the known manner. If the order is placed successfully, an order successful message is transmitted to the transaction gateway and a pre-authorisation request is sent to the PSP. If the order is unsuccessful, an order failed message is generated and sent to the transaction gateway. The successful message is also saved to the gateway database. Unsuccessful messages will be relayed to the user for potential adjustment to the order.

The gateway then requests the status of the pre-authorisation from the PSP and records the response in the database. If the pre-authorisation request fails, then an appropriate message will be sent to the customer.

In the event of a successful order message and a successful pre-authorisation being received, the gateway sends an appropriate order confirmed message to the customer with an order ID.

Figure 2 shows an alternative solution to Figure 1 in which the transaction is 3D secure and the transaction gateway makes all the calls to the PSP.

In the first step, once the customer has selected his items and been re-routed to the transaction gateway, he or she is invited to enter their customer details and the billing and delivery details in a conventional manner. These are then transmitted to the transaction gateway, which registers the order and saves the details in a database in step 4. The database should be PCI compliant as it holds payment details. The transaction gateway then transmits details of the order to the merchant.

The merchant then converts the basket, customer details and wallet into a receipt in the known manner. If the order is placed successfully, an order successful message is transmitted to the transaction gateway. If the order is unsuccessful, an order failed message is generated and sent to the transaction gateway. The successful message is also saved to the gateway database. Unsuccessful messages will be relayed to the user for potential adjustment to the order.

The transaction gateway then performs a 3D secure enrolment check to determine if the customer's card has been set up to use 3D Secure and logs this information in the database. The Transaction Gateway then requests a 3D Secure pre-authorisation message, which is sent to the customer's mobile device and causes a 3D Secure frame to open and request the 3D Secure password. The Gateway controls the size of the frame, and will optimize it for the device being used. The customer then enters their 3D Secure password, which is then returned to the Transaction Gateway, which carries out a 3D Secure pre-authorisation. If this is successful, the Transaction Gateway sends an Order successful message to the merchant and to the customer. The merchant site will then update its payment transaction status for the order.

Figure 3 shows an alternative embodiment in which the customer carries out a first time registration with no purchase to perform 3D Secure transactions, in which the transaction gateway calls the PSP.

In this embodiment, the customer enters their details including credit card details as well as billing details, which are then logged by the transaction gateway and stored in the PCI compliant database 4. The Gateway then performs a 3D Secure enrolment check for a one pound transaction at the PSP for the card details. If the check is successful, then the transaction gateway generates a 3D Secure frame on the mobile device and requests that the password is entered. When the password is returned to the gateway, the gateway requests a 3D secure pre-authorisation from the PSP and if this is successful, logs the details in the database. The Payment Gateway then cancels the transaction at the PSP but sends a registration successful message to the customer.

Once this data has been entered, the user will be presented with the second interface for any subsequent purchase. When using the second interface, users will see this information delivered back to them, with all the fields pre-filled and "collapsed" into clusters, for economy of display purposes. Users can "open" clusters to verify information, or to change a shipping address for example, and enough information will be visible to the user for those purposes, but part of the information will remain in the Gateway.

Figure 4 shows an exemplary embodiment of the process schematic for a registered customer with non 3D secure and where the merchant makes all the calls to the PSP and in which the transaction gateway checks the PSP for pre-authorisation failure and the reasons therefor.

In this embodiment, the customer has browsed the merchant site, selected goods and been directed to the transaction gateway as previously described. The transaction gateway then requests that the customer logs on to the gateway. The Gateway then verifies the customer logon and if successful, requests the contents of the basket, and the card expiry date and security number that the user has been asked to enter after login. The contents of the basket are then saved in the database and also transmitted to the merchant along with the payment information. The merchant then undertakes the order validation as previously described and sends the response back to the transaction gateway and sends a payment pre-authorisation to the PSP.

The Transaction gateway then requests the status of the transaction from the PSP and in the event of a successful message logs this in the database and sends an order successful message to the customer.

Figure 5 discloses an alternative embodiment in which the transaction gateway makes all calls to the PSP for subsequent orders. Whether the process described in figure 4 or figure 5 is used is determined by the fact that the first transaction, or the registration, performed a 3D Secure enrolment check or not.

In this embodiment, the customer has browsed the merchant site, selected goods and been directed to the transaction gateway as previously described. The transaction gateway then requests that the customer logs on to the gateway. The Gateway then verifies the customer logon and if successful, requests the contents of the basket, and the card expiry date and security number that the user has been asked to enter after login. The contents of the basket are then saved in the database and also transmitted to the merchant. The merchant then undertakes the order validation as previously described and sends the response back to the transaction gateway.

The gateway then sends a pre-authorisation request along with the card details to the PSP and if this is successful generates an order confirmed message and sends this to the mobile device. The gateway will then also send a transaction status update to the merchant site.

From the second purchase on, irrespective of who the merchant is, sensitive information relative to the credit card will never be exchanged, nor between the user and the Gateway, nor between the user and the merchant. Sensitive payment information will only be exchanged between the Gateway and the PSP, and between the Gateway and the merchant, where both environments and data exchange formats meet (Payment Card Industry) PCI standards, using the same secure channels as present online transactions.

In this embodiment for any future purchase with any merchant integrated with the Gateway, the user will only need to fill in four simple fields from the moment the checkout button is activated to the moment the confirm transaction button is finally pressed: User ID, Password, expiry date and security code on the card (with variations for other registered types of payment). This particular aspect of the design of the Gateway will allow it to work with the smallest displays, including 2G devices, or devices operating in on a 2G network.

Resolving the difficulties involved in allowing 3-D Secure transactions requires a more fundamental change in the way the transaction authorization is requested and routed, and also greater responsiveness in the gateway's capability of evaluating users' devices and routing the transaction accordingly. With respect with the 3-D Secure procedure, users will be presented with one of three possible situations as they complete their transaction. A) Their transaction will be processed by the merchant exactly as described above because either their issuer or the merchant has not implemented 3-0 Secure yet, or because the merchant has opted to switch it off for mobile transactions, which is his prerogative and is mandated by the networks for telephone (call centre) transactions. B) Their device will be deemed too limited to execute 3-0 and users will see a message on their screens at the beginning of the transaction advising them to first register for the Gateway service and 3-D Secure Validation from a PC before attempting to execute a transaction. C) Their device will be deemed good enough and the payment authorization process will be taken over by the Gateway.

In this case, the merchant will receive only the basket and shipping information, will process the order as described above, and will call back the Gateway with the appropriate success or failure message. Failure will be taken care of as described above; success will trigger the pre-authorization call directly from the Gateway to the PSP. The pre-authorization request should be initiated by the Gateway and while the user is on a Gateway served page that is optimised for his device and browser because this is the page users will receive the 3-D Secure instructions on; the Gateway will then also optimize the size of the window within which the issuers verification fields will be displayed and users will be able to complete their first 3-0 verification process. Users going through the Gateway registration process from a PC will accomplish the same through a one pound transaction going through 3-D verification, then reversed.

The Gateway stores all the information it is authorized to keep from this first transaction and verification, including the record of the 3-D verification. From the second transaction on, users whose transaction should go through the merchant, as per case A above will still have their transaction processed by the merchant himself, but B and C users will continue to see their transaction processed directly by the Gateway, but they will not be repeatedly routed to the 3-D secure verification, unless the Gateway is instructed to do so by the merchant or unless there the transaction is unusual. Once the Gateway receives the authorization and transaction number from the PSP, it passes it along to the merchant, who'll proceed to shipping and final transaction authorization in the usual way.

To make use of its mobile payment capabilities, merchants need to integrate with the Gateway, a relatively simple process performed through the use of a hub. The hub can be a self contained software system which interfaces with any system, is language and platform indifferent.

One of the simplest software additions brought to the merchant's platform through the hub is also the first to enter into play in the mobile payment process. A few lines of code will be added to the merchant's first order processing page or to the merchant's home page if mobile search and display such as Gofone is to be used that identifies the browser and even the device of the user. Several merchants already have that capability. With the browser identified, the user will be re-routed to an interface optimized for this browser, and the checkout process can begin.

The following describes the process tied to using the Gateway's second interface, or second usage interface. The "wallet" refers to the personal, shipping and payment information captured and retained by the Gateway through the first time usage interface, part of which will be served to the user for verification/change purposes, part of which will be used to get the transaction authorized. The basket, again, can be the merchant's basket, or the Gateway's basket as offered on Gofone Ltd's search and display interface. In both cases, the content of the basket will be transferred to the Gateway: if coming from the mobile search and display basket, because it needs to first be saved in the Gateway's basket for the order to be placed, if coming from the merchant, because the Gateway needs to know the exact content of the order for further treatment.

Having selected an item(s) to purchase, the user chooses to complete the purchase, and pushes the check out button, which places the order in the known manner. The placing of the order generates a data packet comprising wallet information, basket information and a temporary transaction l.D., which data packet is generated by the Gateway. The information is saved as "associated" in a local database, and then forwarded from the Gateway to the merchant. The merchant can then initiate an order based on the shipping details and the basket. If the order is successful then the Merchant requests a pre-authorisation (with transaction l.D.) payment message from the PSP and sends its own transaction l.D. and order l.D. back to the Gateway. A pre-authorisation is a standard payment message with a flag set requiring a redemption message before payment is authorised. They are commonly used by hotels to cover incidental costs of a guest on check-in. Final payment authorisation is then processed after the item(s) have been processed by the merchant for shipping.

Final authorisations are often processed in batches once a day.

Two things can go right or wrong with this type of transaction: the order itself, and the transaction authorisation. After receiving the merchant (successful) order number, the Gateway will call the PSP at regular intervals to check the order status. During all these steps the customer is waiting on the user interface. The final status is shown to the customer. If an order failure is due to some items out of stock or an increased shipping cost, the customer can be given the opportunity to try and place the order again with the re-calculated basket. That transaction will start at the beginning again and be treated as a new transaction. If the pre-authorisation doesn't go through, the user will receive a message specifying that this is the reason for the transaction aborting. If the order has been successful, and the transaction pre-authorised, then the customer will be shown the order confirmation and ID from the merchant and will be sent a confirmation email from the Gateway.

In cases where users have come to the Gateway using mobile search and display interface such as Gofone, they will have used the Gateway's basket to save an item.

In a further embodiment, the basket can function as a multi-merchant basket as it is possible to store the merchant ID with the Order. In other words, the gateway saves items for the user across multiple merchants and saves them permanently at the end of a session. The gateway can place an order at anytime with any merchant integrated with the Gateway by populating the merchant's basket and initiating the order and transaction.

This allows users to purchase items from more than one merchant in a single checkout process. The number of merchants the Gateway will allow a user to regroup into a single payment process is more a function of the device used than of the Gateway itself, where it is virtually unlimited. The Gateway will allow users to execute a simultaneous checkout with as many merchants as the size of the display on the device they use will comfortably allow, this on account of the fact that users could and unavoidably will receive simultaneous messages requesting their confirmation on the different transactions. For the purpose of clarity, if a user grouped three items from three different merchants into the same checkout process, the respective items remain each merchant's respective transaction, with three different transaction numbers, routed by the merchant or the Gateway to as many as three processing destinations, and the user will have to confirm each transaction, as the final step of the checkout process, from three different messages received on the device. Again, this limitation is a function of the limitation of display space on mobile devices and reasonable expectations of how many simultaneous messages users should handle; Alternatively as the Gateway itself can handle unlimited multiple simultaneous merchant transaction in a single checkout process from the user.