IES980562A2 - Method and system for the prepayment of a mobile telephone account - Google Patents

Abstract

A system for the prepayment of credit into a mobile phone account comprises a point of sales (POS) terminal which incorporates a card reader and is connected to a POS network. The system further includes means for forwarding a credit request message from the terminal to a transaction management system, and a mobile phone accounting system connected to the transaction management system. The accounting system is adapted to authorise requests processed by the transaction management system and to credit user accounts on receipt of a valid request, so that requests from the POS terminal are forwarded to the accounting system and, if valid, an authorisation is transmitted back to the terminal and the user account is updated. The mobile phone netweork then sends a message to the user's phone confirming that the account has been updated.

Description

"Method and System for the Prepayment of a Mobile Telephone Account This invention relates to methods and systems for the prepayment of a mobile telephone account.

At present, mobile telephone accounts can be conveniently divided into two groups, namely prepayment accounts and postpayment accounts. The latter are traditional accounts which are billed at regular intervals to customers in respect of the amount of telephone usage in the preceding billing period (and thus credit is extended to the'customer). Prepayment accounts differ in that the customer must buy credit in advance before the account has been used.

A known method of administering a prepayment account is to sell cards which "carry" fixed amounts of credit and without which a particular mobile phone model is inoperable. The phone can be used until the remaining credit is exhausted, following which the phone requires a fresh card to operate on the network.

This system is disadvantageous in that the customer is compelled to physically buy and install a creditcarrying card every time credit is exhausted.

A further known prepayment system utilises credit card payments which are authorised by the customer telephoning the telephone company, requesting the purchase of credit (or "airtime"), and quoting credit card details. The telephone company employee then uses standard credit card authorisation procedures to charge the customer for the requested amount of airtime and credits the customer's account accordingly. Yet a further system allows a customer to use an ATM card to place funds in a mobile phone account from a bank account.

Both of these systems are limited to customers who have credit card and banking facilities respectively.

It is an object of the present invention to provide an improved system and method which allows for the prepayment of credit into a mobile phone account.

The invention provides a system for the prepayment of credit into a mobile phone account comprising a point of sale (POS) terminal optionally incorporating a card reader and connected to a POS network, means for forwarding a credit request message from the terminal to a transaction management system, and a mobile phone accounting system connected to the transaction management system and adapted to authorise requests processed by the transaction management system and adapted to credit user accounts on receipt of a valid request, wherein requests from the POS terminal are forwarded to the accounting system and, if valid, an authorisation is transmitted back to the terminal and the user account is updated.

Optionally, the mobile phone accounting system causes a message to be sent by the mobile phone network to the customer's phone confirming the updated account status, so that a mobile phone which was inactive due to zero credit in the account is activated automatically.

Preferably the card for use with the scheme is a loyalty card such as may be issued e.g. by a store or airline. In another aspect the card may be a bank or credit card. It may hoLd information on a magnetic strip or a microchip, for example.

Brief description of drawings \Figure 1. Main components of Architecture Figure 2. Electronic POS interaction with Processing Centre, Side 1 of the architecture Figure 3. Phone Company integration, Side 2 of the architecture In what follows, a typical system and method according to the invention will be described illustrating the use of a loyalty card for a store. In this scenario, the customer when paying a checkout bill requests the purchase of airtime. The operator swipes the card, enters the required value into the system, and receives payment from the customer (this payment is subsequently transferred from the store to the phone company.

The following description outlines the technical requirements to support an electronic payment system for loyalty card scheme members utilising prepaid mobile services on the mobile phone network · There are two distinct components to the supporting architecture. The first is the infrastructure that interacts with the retail Point of Sale (POS) devices located throughout all branches of the store operating the loyalty card scheme. This part of the infrastructure will utilise standards and components normally found in a POS type application (e.g. credit card authorisation).

The other significant part of the infrastructure will integrate with the mobile network's internal prepayment systems. The specific interface to be used will depend on the technical architecture of the deployed prepayment system used by the mobile phone company.

The main components of this system are outlined in Figure 1. The design and development of this infrastructure requires the integration of a number of different systems and components. All of the systems used for in this architecture are in use in other applications today. The following are highlights of the architecture : • Existing links between the store and the Banks remains unchanged • The store's POS devices require application changes which will be facilitated by the Banks acting under instruction from the store.

• All loyalty card transactions involving prepaid airtime will be sent real-time to the Processing Centre, which will immediately communicate with the phone company's prepaid system.

• The communications architecture and message flow between each store outlet and the processing centre will be based on the APAC$-30 standards.

• The communications architecture and message flow between the processing centre and the phone company are dictated by whatever open Application Programming Interfaces (ΑΡΊ/s) or similar facilities are employed in the phone company's system.

Figure 2 outlines the major components supporting the integration between each store outlet and the Processing Centre. Preferably, major components outlined within the Processing Centre will all be based on a product called Base-24 supplied by ACI. This software product is used by most financial institutions world-wide to manage real-time transactions with POS and Automated Teller Machine (ATM) devices. The phone company's Transaction Manager component will depend on the links available within the particular system used.

The following is a summary of the functions performed by each component: APACS-30 All communications with POS devices and servers will be facilitated by this component. It is responsible for supplying and receiving APACS-30 formatted messages.

EPS Transaction Manager This is the main processing engine within the centre.

It receives and communicates with APACS-30 regarding customer prepayments at the POS. It also communicates with the phone company's Transaction Manager to provide updated account balance information. Finally, it interacts with the settlement system for provision of settlement information.

Settlement Manager All transactions are monitored and recorded within the Settlement Management System. It provides full accounting information to facilitate the settlement of cash transactions that have taken place between the phone company's customers and the store branches.

Phone company's Transaction Manager This system is responsible fpr all communications with the mobile phone network.

Figure 3 outlines the major components involved in the interaction between the phone company network and the Processing Centre. In most cases the best architecture for the integration of the Transaction Manager may be to utilise the Interactive Voice Response (IVR) procedures which are normally used with token based prepaid systems of this nature.

Functionally, the Electronic Payment System is similar to the token based (scratchcard) system at the account authorisation level. While the origin of the account update request is different (IVR call-script interaction vs. card-swipe device), the requirement to successfully .update the account and notify the customer is identical.

The following is a diagrammatic description of the message flow between the point of sale terminal (via server or direct) and the Processing Centre.

The message transactions described below will be encoded and exchanged as per the APACS-30 specification Appendix L (Message Protocols and Formats for Credit Authorisation Transactions). In the following message descriptions, the first field is for design purposes only and will not appear in the transaction flow. The naming convention is TRM=Terminal, HST=Host followed by a unique number (e.g. TRM-01 is the message number one, generated by a terminal).

Message TRM-01 Message ID Type Dunnes Value Card Number Value of airtime required Message TRM-02 Message ID Type Dunnes Value Card Number Value of airtime refund Message HST-01 Message ID Type App specific code Same format as for CC Exception Handling There are a number of exceptions to the normal transaction flow that must be catered for. The following list attempts to identify all of the possible exceptions that may occur and the strategy for dealing with them.

Exception 1 - Communications Link Failure There are two types of failure here. Firstly (Type 1), the in-store network could fail, disabling the POS from communicating with the in-store server. This failure would cause all credit/debit, as well as this value card application to fail. Solutions are based in many cases on the existing process for handling such errors.

Secondly (Type 2), the in-store controller may fail to make a connection to the remote host. This causes other applications (e.g. credit card authorisations) to batch up the individual requests. Again, solutions are based on the recognised methods of handling such failures.

Exception 2 - Operator Entered Incorrect Amount Unless the customer spots this on reading his receipt (or on seeing the operator input the incorrect amount), this will only become apparent to the customer at some later time. This can therefore be dealt with at the Customer Care Centre.

Exception 3 - Card Details are Keyed in Incorrectly The process' for handling this is similar to Exception 2. If spotted by the customer, it can be rectified there and then (refund req for the incorrect number, followed by auth req for the correct number).

Otherwise, it can. be dealt with at the Customer Care Centre.

Exception 4 - Auth Req amount is below Minimum Transaction Amount (MTA) A minimum transaction amount will be required by this service. However it is decided to deal with this exception, one must ensure that the limit can be easily changed. The result at the till will be a special "decline" message. This exception will be close to zero with good information to till operators and infrequently changing MTA.

Exception 5 - Operator completed Transaction before Payment and Payment failed If the transaction for airtime has been completed before payment and payment cannot be made (for whatever reason), then is will be up to the operator to initiate a Refund-Req, which will back out the transaction at the host.

Exception 6 - Operator initiates transaction with all details, Terminal fails (power failure, etc.) This is handled in the same way as with the existing loyalty card transactions.

Exception 7 - Customer presents incorrect card (valid for this transaction, but not his card).

The outcome of a successful transaction always results in a predefined valuecard customers mobile account being credited with a specified sum. There is no possibility of the card being used to credit a DIFFERENT mobile account. If the card presented is that of the customers spouse or other relations, it will not be spotted until after the transaction and it will then be dealt with by the Customer Care Centre.

If the card has been reported stolen, one will suitably follow the same procedures for stolen credit cards, even though there is no possibility of the thief abusing the account. (In fact the only "damage" the thief can do is to credit the victim's account).

Exception 8 - Abuse of Refund Request The rules for refunds are as follows: 1- At the point of sale, refunds can only be given against the specific card that was credited at the specific point of sale within the last 10 minutes. (All APACS-30 messages received by the Processsing Centre host will be time stamped.). If the time limit has expired (for whatever reason), the customer will be referred to the Customer Care Centre and asked to keep his original receipt. 2 - The amount of the refund must be less than or equal to the originally credited amount. 3 - Refunds can only be given under one of the following circumstances: a) customer believes the operator entered the incorrect amount (e.g. "I asked for £20 not £25"), or b) as a result of Exception 5, above.

Under either type of communications failure described in Exception 1, above, the customer will be referred to the Customer Care Centre. No automatic refund can be facilitated at the till.

All other refund issues will be dealt with at the Customer Care Centre.

Terminal Display _and Printing Receipts The receipt printed for the customer will be similar to that printed for a credit card customer. Important information that will be contained on the receipt: 1 - Authorisation Code 2 - Transaction Date and Time 3 - Store identification (and POS, if possible) 4 - (possible short text message - "please keep you receipt as proof of payment. This is also your VAT receipt") No special terminal (LCD/LED) displays are envisioned at this time.

General Notes The design of this application is such that a special key sequence be entered by the till operator before the card is wiped. This should be designed so that it is a 1 or 2 key sequence and that the same key descriptors are used across multiple vendors terminals. There should also be a cancel key identified.

To handle Exception 1 (Comms failure), the in-store server will be required to keep a list of valid account numbers. In Comms-Link-Down mode, the server will provide the Auth-Response only for those cards which appear on the list. The server will decline ALL refund requests in this mode.

Summary The software components that are used in this architecture are in use in other applications today (mainly within the financial services industry). The technical changes, scale and scope of the work required to develop the Processing Centre and the integration of the Processing Centre with each store outlet is well understood today and the proposed transaction flow and exception handling is merely exemplary of a single system, which can be modified to uit individual circumstances.

Although discussed in particular in relation to a store loyalty card, other cards can be used, as appropriate.