WO2012046005A1

WO2012046005A1 - Universal transaction gateway

Info

Publication number: WO2012046005A1
Application number: PCT/GB2011/001454
Authority: WO
Inventors: Jean Duval
Original assignee: Mpower Payment Limited
Priority date: 2010-10-07
Filing date: 2011-10-07
Publication date: 2012-04-12
Also published as: GB2484653A; GB201016934D0

Abstract

A transaction gateway (UTG) or router comprising a Transaction Rule Engine (TRE), a local Payment Card Industry certified (PCI certified) database, an Order Management Service (OMS), a Merchant Service (MS) and a PSP service wherein the OMS sends information to a user through a web interface, while the MS sends and receives payment messages from merchants integrated with the gateway and the PSP service sends and receives data from different payment service providers. In use, a user generates a transaction request on a merchant's website which sends it to the UTG via the OMS. The gateway enables integration of different payment systems and loyalty schemes to provide a universal solution to payment standard incompatibilities in a certified environment. Thus, when an order is successful, an order ID is created and sent to the UTG. The certified database is checked by the TRE which then sends a request for payment to the PSP service. The PSP service recognises the destination of the payment message and formats the payment message in accordance with the payment service provider requirements.

Description

UNIVERSAL TRANSACTION GATEWAY

The invention relates to a transaction gateway, in particular for an e-commerce website, which gateway is adapted to facilitate the use of a plurality of payment service providers and types of payment solutions for the e-commerce merchant.

The electronic funds transfer (EFT) network is one of the most widely adopted point of sale equipment and is now even found in most small retail stores and businesses. 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 but in recent years a large number of payment service providers have been established, largely to service the ever growing number of online merchants. The banking groups fulfil the role of an acquirer (also known as a merchant acquirer), which is effectively the router (or a third party processor designated by the acquirer) for the payment messages. As the acquirer will also require the merchant to have a bank account with them, payment service providers are used, particularly by small and medium size businesses to intermediate with the acquirer and the merchant systems.

A payment service provider (PSP) is therefore the link between a customer and the bank of the business. Some payment service providers can provide payment terminals to businesses, whereas other companies exist purely as online operations processing payments for e-commerce websites. Many e-commerce websites are now configured using standardised software to work with particular payment service providers. However, in order to differentiate themselves in the market, many payment service providers are offering new services or business models, different payment solutions, which are not necessarily compatible with other PSP's offerings.

For example, Paypal ®, the popular web based payment system, allows users to pay for online purchases from a PayPal account that can be pre-loaded with funds for payment and seamlessly linked to their credit/debit card or bank account. Most PSP's more straightforwardly facilitate for merchants the processing of credit and debit cards payment through merchant acquirers and/or payment processors, reproducing online the brick-and-mortar merchant to acquirer/processor payment set-up. PayPal became a widespread payment solution amongst online users because it enabled peer-to-peer payment on eBay®, the auction site. A high proportion of PayPal users prefer to use it as an alternative to card payment online because they perceive it to be a safer payment solution. In Europe, surprisingly few large online merchants are integrated with PayPal for payment, which keeps millions of online customers from using their preferred payment channel. Merchants are deterred from integrating with PayPal because of the substantial technical problems that need to be addressed and solved. Paypal uses an e-mail based system in contrast to the ISO/IEC 78 121 :2000 and ANSI X4.13 standards.

For merchants, the number of payment options available to customers is basically a function of how many payment options its PSP offers. This, in turn, is very much a function of who are the dominant payment players in any given country, as most PSP's originated as agents for major acquirers. An example to illustrate this is the computer hardware company Dell's different websites in Europe. One of the largest international online merchants, Dell was for a long time a pure online merchant. Not surprisingly, a customer purchasing from Dell's website in Norway, Spain or Germany would go through an absolutely universal shopping experience with the same navigation, same products, same customization options, same steps all the way through to the payment page. Once there, a customer in France will be offered Visa®, MasterCard®, Aurora® and Carte Bleue® as Payment options. In the UK, Visa, MasterCard, American Express® and Maestro®, MasterCard's latest- technology debit payment product. In Germany, where Maestro is deployed as a product, Maestro is not offered as a payment option, but in its place Giropay® is offered, Giropay being the dominant debit scheme owned by a consortium of German banks and which doesn't use Visa or MasterCard's network. In Spain, only Visa and American Express, not MasterCard are offered. The payment options available at Dell in the Scandinavian markets also present a singular omission: Diners Club®, an ex-powerhouse in corporate card product in Europe and America that has retained a very strong franchise in Scandinavia, is not offered as a payment option. This leaves out a large portfolio of co-branded Eurobonus® (Scandinavian Airlines' loyalty program, by far the largest in Scandinavia)/Diners Club cards, a card portfolio that would normally hugely over-perform for Dell in the small business segment. But Diners Club has very low acceptance levels with online merchants in Scandinavia, which simply reflects the fact that few PSP's offer it as a payment processing option.

Not offering popular payment options, or payment cards tied to large loyalty programs, in any given market, reduces sales for merchants. It is therefore a non- trivial issue for most e-commerce businesses to use one specific payment service provider, as it will unavoidably result in cutting out certain groups of customers. Direct Mobile Billing, where the consumer's mobile account is charged for the purchase, is a new and rapidly-growing alternative payment method - especially in Asia and Europe. It is a true alternative payment method that does not require the use of credit/debit cards or pre-registration at an online payment solution such as PayPal, and it bypasses banks and credit card companies altogether. Mobile operators have a vested interest in its growth, but more importantly, it rates highly in customer satisfaction. Very few online retailers in Europe offer it as a payment option due to the technical challenges in integrating it into their systems while the vast majority of PSPs do not offer that option.

Loyalty currencies have been used for payment in the brick and mortar world for decades, in a crude non-technical format, and for that reason not much online. For example, Shell® operates a points based loyalty program in 22 countries, and is most of these markets is one of the largest loyalty programs. Members can redeem their points for petrol vouchers, mailed to them to use as partial payment at Shell retail stations. In the UK and in other Shell markets, points can also be redeemed for shopping vouchers, i.e. printed vouchers with a nominal value in pounds mailed to members to use as partial payment at large High Street retailers. Retailers sell their vouchers at a discount from their face value to Shell because it brings in affluent customers (some of whom are new customers) and a guaranteed sale. Enabling loyalty currencies as a seamless payment option at online merchants would allow merchants to target loyalty club members with opaque discounting, acquire new customers and increase sales. It would also greatly benefit loyalty members who notoriously leave points in their account (this is referred to as breakage for loyalty operators) due to lack of opportunities to use them. Loyalty payment is so radically different, technically speaking, from conventional payment that it is impossible to imagine that the payment industry would ever contemplate an overhaul of their existing technology to integrate it. Loyalty payment remains the exclusive domain of very few, massive brick and mortar retailers who operate it within a closed proprietary system, such as Boots. Even there, points payment is an option in store, but not online.

Due to the prescriptive nature of the payment standards, which requires that electronic payment messages have a prescribed form and any deviation from the prescribed form result in the payment request being rejected, the integration of different payment types is a significant technical problem for the payments industry. The alternative solutions such as PayPal or mobile telephone billing circumvent this problem by providing an alternative payment destination.

The standard on most websites is that the client is presented with a series of options for an ISO/IEC 78 121 :2000 or ANSI X4.13 compliant payment type. These will typically be Visa, MasterCard, Visa Debit or Maestro. However, there are an increasing number of alternative payment schemes. Examples of these include the payment options offered by Visa and MasterCard for customers with deposit accounts such as Electron or Solo in the United Kingdom. These options have a much lower acceptance than standard Visa or MasterCard transactions as they require modifications to the standard payment infrastructure of the merchant but they are increasingly popular with certain types of consumer, to whom credit is not available or who do not wish to risk becoming overdrawn. Although these schemes have a much reduced prevalence of fraud, where the risk would fall on the merchant, the additional expense of accepting the payment type due to the technical adaptations necessary has restricted their uptake. Again, the time and the expense of this are hard to justify even for larger retailers, let alone for smaller companies.

The present invention seeks to provide a technical solution to the technical problem of integrating various payment methods caused by the payment standards.

According to the invention there is provided a transaction gateway adapted to receive a transaction request and to route that request to a merchant and any return message from the merchant, wherein the gateway further comprises an engine adapted to form a payment message in dependence on the transaction request, which payment message is routed to a payment service provider for pre- authorisation, the return message from the payment service provider being routed to the merchant or the customer in dependence on the status of the PSP return message.

The problem of the invention is solved by a Universal Transaction Gateway, which can be hosted in a PCI certified environment. It is a transaction gateway, not a payment gateway, and is a new physical device in the payment processing environment.

The Universal Transaction Gateway (hereinafter UTG) enables integration with as many PSP's and payment solutions as deemed necessary in any given country, which, in turn, allows a merchant to accept most payment solutions. The technical integration (from the point of view of the merchant) with the Gateway is relatively simple, simpler than integrating directly with a PSP's and other payment solutions, let alone integrating with several of them because the gateway functions as a super router. This function is the pre-existing condition to more complex functionalities enabled by the Gateway, which are made possible by a Transaction Rules Engine (hereinafter TRE).

The TRE applies logic to transaction information collected from the merchant and the customer before the payment pre-authorization process initiates, assessing who the relevant parties could be in the transaction, such as a loyalty club a customer would belong to, and determining where and how payment should be routed before passing on the payment information for payment processing. The Transaction Rules Engine has an administrator interface that allows for easy creation of new rules and temporary rules

A second aspect provided by the transaction gateway is the facility to use alternative payment service providers. Each payment service provider is different and they have different ways of reporting statuses of transaction data including historical data. They broadly fall into two categories. Those with an API that allow the data to be retrieved and those that use a web based tool to generate reports. An example of the former is Paypoint® and an example of the latter is Commidea®.

An exemplary embodiment of the invention will now be described in greater detail with reference to the drawing, in which:

Fig. 1 shows a schematic of a payment process

The Transaction Gateway is a router, in other words a physical device and comprises five core parts: a Transaction Rule Engine (TRE), a local PCI (payment card industry certified) Database and 3 services: The Order Management Service (OMS), which communicates with the user through a web browser interface; the Merchant Service, which sends and receives information from merchants who have performed the integration with the Gateway, and the PSP service, which sends and receives data to and from Payment Service Providers. In use, the TRE receives information from one service, looks for rule-making data in fields associated with the merchant and the customer in the database, makes a decision, and passes on the information along with instructions to the next service, or back to the service the information came from in the first place.

The rule-making fields belong to three categories on both user and merchant side: group, benefit, payment. Fields on the user side partially populate or tag themselves automatically from data entered by users, i.e. payment card number and loyalty membership number; fields on the merchant side are populated by the Gateway administrator.

Groups are created by the Administrator. On the user side, groups association is determined when the user enters his payment card details. A user can belong to several groups if (s)he registers several cards with the Gateway, but (s)he will have to determine an order of preference, and only one group will be relevant to each transaction. The same logic applies to loyalty groups, considered separately. Customer-created hierarchy therefore determines which group is relevant to the transaction when many could be. On the merchant side, commercial agreements put in place separately allow the Administrator to tag each merchant as belonging to several groups. If there is a group match between merchant and user, the TRE will look for a benefit match at step 8 of the process illustrated in Figure 1A. There is a benefit match if the engine finds an identical benefit on both user and merchant side, for example: <10% discount for purchases above £100>.

The Gateway is activated when a customer initiates a checkout after having saved his items on a merchant's basket, which merchant has completed integration with the Universal Transaction Gateway (UTG). The user is then re-routed from the merchant's website to the Gateway for the whole payment process. On first time usage, the customer will enter all his relevant payment and shipping information, including one or several payment methods— credit or debit card, PayPal account, etc.— and indicate an order of preference. He will also be asked to enter membership numbers of loyalty clubs that he belongs to and indicate an order of preference. The customer would then go through an identical process to the one described here below, starting at step 5. In step 3, the UTG would capture the customer's details and save them in the local PCI database in step 4. Fig. 1 shows a second-time order through the UTG to simplify the schematic and better illustrate the Express Checkout benefit of the UTG. In both first and second- time usage, the UTG interfaces with all three participants in the payment process (customer, merchant, PSP), becomes the single point of contact between them, while taking over some of the merchant's tasks.

In the process illustrated here, a registered customer clicks on the checkout option from the merchant's basket page. From second usage on, the customer will benefit from an express checkout when purchasing with any merchant integrated with the UTG. The registered customer places the order and the UTG reunites the order with the payment information, before splitting them again to route the order to the relevant merchant. Once the merchant sends back a success for the order, the UPG processes payment, by using a customised "Transaction Rules Engine" which can route transactions to different PSPs as well as splitting payment across a PSP and a Loyalty account.

Steps 1 to 5

In the first step, a customer will login to his account. This will initiate a call to the Order Management Service (OMS) of the UTG, which will identify the user and retrieve his details from the PCI database. The Order Management Service (OMS) of the UTG sends back the payment wallet to the customer for verification purposes. Here the full sensitive details are not retrieved, only the last 4 digits of the card are given, enough to allow the customer to remember which card they have registered and verify the details.

Step 6

The authenticated customer with a basket of item(s) is also shown his default shipping address and the default shipping method and cost selected. The customer can then simply place the order by entering his expiry date and security code on the credit card. If a customer wishes he can update the wallet, the basket, the shipping address or the shipping method.

Steps 7 to 8

This is securely sent over SSL to the UTG, which checks with the Transaction Rules Engine (8A), which itself checks with the database to see if the customer belongs to a loyalty club relevant to the merchant based on a pre-existing commercial agreement. If there is such qualifying loyalty club in the customer profile, a message (8B) will be sent to the customer asking him if he wishes to make a partial payment with points and offer points payment level options and the customer will reply (8C). If not, the UTG will proceed directly from step 8A to update the database to set the order status and generate a unique token number for this order.

Matching benefit fields on both merchant and user side produces a rule and triggers a specific action. The message to the customer could be, for example: 'Would you like to use Shell points for this purchase?' followed by clickable buttons showing: £10 off: 100 points

£20 off: 200 points

Followed by a no thank you or confirm buttons. If the total for the purchase was below £20, only a £10 voucher would have been offered. The specific offer in the benefit field on the merchant side could also limit what percentage of the transaction the merchant wants to limit points payment to.

Step 9 to 11

The process then flows back in step 9 from the OMS to the Merchant service, which sends the order back to the merchant. This could seem redundant, as the basket initially came from the merchant and is then passed on to the UTG in step 7, but it is important that the UTG first reunites the order and payment information and saves it in the database, then splits order and payment information and passes back the order to the merchant for order processing. The Merchant Service sends the customer order without payment details to the merchant over SSL.

Step 12

The basket and customer shipping details are processed by the merchant and here the merchant checks the order to ensure he is able to fulfil it.

Step 13A

If the order is successful, the merchant creates an order ID and step 13A shows this. Step 13B

If the merchant fails the order due to incorrect shipping method or products out of stock, this is treated as a failed transaction and no order ID is created. The predefined failure cases are as below:

• Merchant not responding (merchant site could be unavailable or busy)

• Item out of stock (with a list of items that are out of stock and their Quantity in stock) • Item cost incorrect (when an item price has increased, information on the items that have changed in price together with their correct price is obtained and shown by the gateway)

• Shipping address not valid (merchant does not ship to the chosen address)

• Billing address not valid (some merchants may backlist certain billing addresses)

• Shipping value incorrect (if shipping value is inaccurate, the correct value for that shipping method is obtained and shown by the gateway)

• Shipping method incorrect (if the wrong delivery option is chosen for the order, the correct delivery option code to use is obtained and shown by the gateway)

Steps 14A, 14B & 15

The success response (14A) is then sent to the UTG over SSL with an order ID in step 15. If there is a failure in the order (14B) then this is also relayed back to the UTG in step 15 as a voided order with a reason code as per the descriptions in step 13B.

Step 16

Step 16 saves the MERCHANT ORDER SUCCESS response with the appropriate status in the database before proceeding to step 17. Step 16 also saves, alternatively, the MERCHANT ORDER FAILURE response to the database to progress the order status on the UTG. If the ORDER is VOIDED because the merchant is not responding, the process terminates follows with a MERCHANT NOT RESPONDING message to the customer. If the order is voided for any other reason, the user will be presented with the appropriate order error message. The order has been voided, and if the customer eventually changes the defective information or confirms the new cost, it will initiate a new order, although the customer is unaware of this. From a process standpoint this happens in a new step 6, which then goes through steps 7 to 15. If this new order is successful, it will be saved in the database with the merchant's ORDER ID then proceed to step 17. Step 17

If the response order status is set to MERCHANT ORDER SUCCESS, then the Merchant Service calls the Transaction Rules Engine to initiate pre-authorisation.

Step 18

The Transaction Rules Engine (TRE) checks the database for the information that will allow it to determine how the transaction should be routed. On the merchant side, payment rule-making fields show all specific payment options accepted by the merchant, associated with the routing instructions, usually to one PSP, sometimes two, in the combination of a primary PSP and PayPal, for example. On the user side, the UTG's database has listed all the payment options that are actually possible as a function of the UTG's integration to different PSPs and payment solution. All of these options are shown to the user if it is a first time transaction. In a second-time transaction, the customer's preferred payment option has been saved back in step 5, and if no change has been made by the customer in step 6, this payment option occupies the rule-making field on the user side. The user's choice supersedes the merchant's. If the user's payment option is actually one of the ones offered by the merchant, the payment information will be sent by the PSP service to the merchant's primary PSP. If not, the PSP service will route it to the PSP that processes this specific card, where the merchant will have opened a secondary account.

If a loyalty payment has been triggered in step 8, then the PSP service will route the transaction to the Loyalty Authorisation Module, where the transaction will be split before authorisation, as per step 21 D and 21 E.

Steps 19 & 20

The Transaction Rules Engine updates the database and sends the request for payment to the PSP service which then sends the payment to the relevant PSPs. The PSP Service recognises the destination of the received payment message and then formats that payment message so that it is in the appropriate format for its intended recipient and then transmits the message. The PSP Service uses the communication format specifically used by each PSP or Payment Solution to generate the payment authorisation request and pass along the payment information. Steps 21A & 21 B

Based on the rules a specific PSP will be called to pre-authorise the card. If successful the order status will be set to "PRE-AUTH SUCCESS" in the database in step 22, if not then the order status will be set to "PRE-AUTH FAILED"

Step 21C

The Gateway will route the transaction to PayPal, ClickandBuy, Direct Mobile Billing, or other payment solutions for pre-authorisation in the format they each specifically require, if they have been chosen by the customer. The merchant will have opened a secondary account with each payment solution they wish to accept, for direct settlement, or have the reporting and settlement flow through the UTG as per 21 D if the expected frequency of transaction is low. For certain cards or for international transactions, the transaction could be routed directly to a processor. The PSP Service will then wait for a PRE-AUTH Success or Failure message.

Step 2 ID

Transactions involving Loyalty point payments are routed to the Loyalty Authorisation Module. This module is really a UTG module, but it connects with each specific Loyalty database that it is servicing, usually in 24 hour batch feeds and also performs reporting and settlement functions, and for the sake of clarity the whole function is shown as "outside" the Gateway.

If a loyalty payment applies, the transaction will be split and the authorisation for the loyalty voucher(s) will be authorised by the module (the last updated balance in the customer's loyalty account will have been checked at step 8). The pre-authorisation request for the cash portion of the payment will then be routed to a PSP with which the UTG has an account in step 21 E and an authorization number will be sent back to the Loyalty Authorisation Module by the PSP if the card payment authorisation is successful. The Loyalty Authorization Module will then issue its own authorisation number and send the authorisation message and all details back to the PSP service.

The Loyalty Authorisation Module also has a reporting and settlement function to the merchant and to the Loyalty program, but this will happen after final authorization, but is not a core Gateway functionality and does not happen in real time, and usually days after step 25. Typically, there is a period of a few days before the merchant has shipped the goods and issuance from the merchant of the final authorisation request message. In this case, the request will follow the exact routing it did for the pre- authorisation. If more than 24 hours have passed, the Loyalty Authorisation Module will have taken the points payment from the customer's account when updating the Loyalty database. If less than 24 hours have passed, the authorisation request to the PSP will be delayed by a few hours. Authorisation from the PSP will flow back through the Loyalty Authorisation Module. Reporting to the merchant will come with the full details from the split transaction (PSP authorisation number, loyalty voucher(s) authorisation number(s) and the module's authorisation number).

Voucher codes from merchants could be used for loyalty vouchers, but not all merchant basket software present voucher code functionalities. Particularly, in certain markets such as Scandinavia where discounting is not as prevalent as it is in the UK, a large number of merchants do not have voucher code functionality. To make this feature truly universal in its implementation potential, the Loyalty Authorisation Module will simply process loyalty vouchers by replicating virtually what presently happens in the brick and mortar environment. The UTG will open a voucher account with merchants and pre-pay for a certain volume of vouchers at the negotiated discounted rate. This will be divided in nominal units, ten pounds for example, carrying a voucher number. Voucher numbers are included in the detailed report to merchants, associated with each specific transaction. The Loyalty Authorisation Module reports and settles to/with both merchant and Loyalty program: to the merchant, as just described; to the Loyalty program, it reports voucher redemption per specific transaction, invoices, receives payment and orders and settles new vouchers from merchants.

Step 22

In step 22, order status for successful pre-authorisation requests are set to "PRE- AUTH SUCCESS" in the database, unsuccessful ones to "PRE-AUTH FAILED". All transaction details will be saved in the database (PSP authorisation number, loyalty voucher(s) authorisation number(s) and the module's authorisation number. The PSP service will forward the Loyalty Authorisation Module's PRE_AUTH message and number to the Merchant Service and the Order Management Service, also in step 22, to aid legibility of the drawing; the relevant arrows have been omitted from the figure. Steps 23 to 25

In the case of the payment having been successfully pre-authorised, the Order Management service (step 23A) sends the result back to the customer with an order ID. Step 23B shows how the merchant is informed of the success by the Merchant Service if payment has been pre-authorised and passes on the authorisation number. Step 23C shows how the merchant then updates his own internal system to record a successful pre-auth. Step 24 shows how the customer is informed over SSL of the success of the transaction and receives an order ID.

If a "PRE-AUTH FAILED" status has be set in the database in step 22, then the merchant is updated accordingly via steps 23B and 23C so that the merchant can void the order on his systems and release the stock. In step 24, the customer would be then informed of the actual reason for failure (an example of which could be "insufficient funds to complete the transaction"). The PSP will have a predefined set of error codes which will be stored on a lookup database table on the UPG. The error codes are grouped to allow custom messages to be sent back to the customer as to the action he or she could take. In this example of "insufficient funds", the customer could be told to use another card as his credit limit on this card is not sufficient. As was the case for failed orders, this new attempt at payment will actually be treated as a new transaction.

The payment gateway is provided with an automated task that runs at a set interval to request a transaction based on the transaction which it needs to get updates on. The payments gateway can do this either through an API or through posting to the web based reporting system and extracting reports. In both cases, a comma separated value (CSV) list is generated, which can be saved into the local database. This enables the payments gateway to monitor the transaction status and check whether it was successful but ensures that the merchant will perform all of the pre- authorisation, authorisation, cancellations and refunds in its respective normal way. The payments gateway only retrieves the data in a read only fashion. A further advantage of the payment gateway is that it will facilitate merchants offering sales in multiple currencies as a significant number of acquirers will only process transactions in a single currency.

Claims

1. A transaction gateway adapted to receive a transaction request from a user and to route that request to a merchant and any return message from the merchant, characterised in that

the gateway is adapted to form a payment message in dependence on the transaction request, which payment message is routed to a payment service provider for pre-authorisation, the payment service provider generating a return message, which return message from the payment service provider being routed to the merchant or the user in dependence on the status of the payment service provider return message.

2. A transaction gateway according to Claim 1 , wherein the gateway comprises means to communicate with a user, means to communicate with a merchant site and payment service provider means adapted to communicate with payment service providers, wherein the payment service provider means is adapted to form and/or modify a payment message in dependence on its destination.

3. A transaction gateway according to Claim 1 or Claim 2, wherein the gateway further comprises a database adapted to store transaction data and user data, which data is used to generate the payment message and/or route the payment message.

4. A transaction gateway according to any one of Claims 1 to 3, wherein the gateway further comprises a rules engine adapted to receive information from the means to communicate with a user, means to communicate with a merchant site and payment service provider means adapted to communicate with payment service providers, wherein the rules engine is further adapted to transmit the information between said means or to return the information from the means from which it was received.

5. A transaction gateway according to Claim 4, wherein the rules engine compares benefit fields in the database and in the event that a match is found, generates a benefit redemption message and a payment message, wherein the payment service provider means then routes the benefit redemption message to a first destination and the payment message to a second destination.

6. A transaction gateway according to any one of Claims 1 to 5, wherein when a transaction request is received, the gateway combines the transaction information with payment information and stores the combined information in the database, wherein the gateway then splits the transaction information and the means to communicate with a merchant routes the information to the merchant.

7. A transaction gateway according to Claim 6, wherein the merchant then sends a further status message to the gateway, which is stored on the gateway and routed to the user.

8. A transaction gateway according to any one of claims 1 to 7, wherein the payment service provider is one of a payment service provider, mobile phone company or loyalty scheme provider.