Essential Mobile-Commerce Technology (part 3) - MOBILE COMMERCE PAYMENT METHODS

3/12/2013 7:10:42 PM


Among the many issues that arise with mobile commerce security, mobile payment methods are probably the most crucial. These are the methods used to pay for goods or services with a mobile handheld device. A typical mobile payment scenario is as follows:

  1. A user registers for the services via an Internet-enabled mobile handheld device.

  2. The user submits his/her payment for the services he/she has received.

  3. The service/content provider deals with the request by authenticating and authorizing the user and then contacting a wireless service provider and a financial institution.

  4. A confirmation of the completed transaction is delivered to the user.

This section examines the issues involved and describes a set of standards for mobile payments. With the development of commerce, there has been a tremendous evolution in the methods of payment, from the seashell of ancient times to coins and notes, from writing checks to on-line banking. The emergence of e-commerce has revolutionized the traditional methods of payment. With the help of mobile devices, the dream of "transaction without cash on the move" is now possible. Mobile payment enables the transfer of financial value and corresponding services or items between different participators without the need for any actual physical contact between them. The mobile device can be a wireless communication device, such as a mobile phone, a PDA, a wireless tablet, or a mobile computer. Mobile payment can be divided into two categories, generally according to the amount of transaction value. One is micro-payment, which defines a mobile payment of approximately $10 or less, often for mobile content such as video downloads or gaming. The other is macro-payment, which refers to larger value payments.

Mobile Payment Scenarios

The global spread of mobile telecommunications has been so successful that the number of mobile subscribers had risen to one billion worldwide by the end of 2002. In 2003, 60 million users spent more than $50 billion on mobile services. One survey predicted that combined e-commerce and m-commerce volumes would grow from $38 billion in 2002 to $128 billion in 2004. Accompanying this increase in subscriptions has been an evolution in the sophistication level of mobile devices, encouraging the emergence of new applications such as enhanced messaging services (EMS) and multimedia messaging services (MMS). In these applications, consumers are presented with more options, such as the download of images, streaming video, and data files as well as the addition of global positioning systems (GPS) in mobile phones, which will facilitate location-based mobile commerce and make mobile payment methods more feasible.

There are four participants in a mobile payment transaction. The mobile consumer (MC) subscribes to a product or service and pays for it via their mobile device. The content provider/merchant (CP/M) provides the appropriate digital content, physical product, or service product to the consumer. The payment service provider (PSP), which may be a network operator, a financial institution, or an independent payment vendor, controls the payment process. The trusted third party (TTP) administers the authentication of transaction parties and the authorization of the payment settlement. In fact, several of these roles can be merged into one organization, e.g. a network bank, which is capable of acting as CP/M, PSP, and TTP at the same time. In a more general sense, a PSP and TTP can be performed by the same organization.

Content Download

In this scenario, the consumer orders the content he or she wants to download from a content provider. The content provider then initiates the charging session, asking the PSP for authorization. The PSP authorizes the CP/M, and then the download starts. The transaction can be settled by either a metered or pricing model. Metered content includes streaming services, where consumers are charged according to the metered quantity of the provided service, e.g., the interval, the data volume or the number of game sessions. In a pricing model, the consumer is charged according to the items downloaded completely. A content purchase is also available via a PC Internet connection, where the mobile device can be used to authorize the payment transaction and authenticate the content user.

Point of Sale

In this scenario, services or the sale of goods are offered to the mobile user using a point of sale location instead of a virtual site, e.g., a taxi service. The merchant (e.g. the taxi driver) will initiate the payment at the point of sale. The PSP asks the mobile user to directly authorize the transaction via a SMS PIN, or indirectly via the taxi driver through a wireless Bluetooth link. The process is also applicable to purchases from a vending machine.

Content on Device

In this payment scenario, the user has the content preinstalled in his/her mobile device, but he or she must be granted a license to initiate the usage of the content, e.g., the activation of an on-demand game playing service. The license varies with usage, duration, or number of users, and determines the value that the consumer must pay for the desired content.

Mobile Payment Methods

Two common kinds of mobile commerce payment methods are

  • Macropayments: This kind of payments is commonly used by traditional electronic commerce and involve significant amounts of money, for example more than US $10.00. Payments by credit cards are the most common method for macropayments.

  • Micropayments: These usually involve small amounts of below about US $10.00, which are too small to be economically processed by credit cards.

Figure 2. A typical macropayment scenario

The amounts are usually charged to users' phone bills or accounts.

A typical macropayment/micropayment scenario proceeds as follows, as illustrated in Figures 2 and 3 for macro and micropayments, respectively, where the number is the order of steps taken:

  1. A mobile user submits his/her credit-card or personal information to the mobile content via a handheld device.

  2. A third-party processor verifies and authorizes the transaction.

  3. The third-party processor routes verification and authorization requests to the card issuing bank or mobile carrier.

  4. The user pays his/her monthly credit-card or phone bill.

  5. The bank pays the mobile content provider or the mobile carrier pays the mobile content provider directly or through a bank after deducting a transaction fee.

Mobile Payment Operations

In a card transaction, there are usually four stages, including set-up and configuration, the initiation of the payment, authentication of the user, and completion of the payment. In the mobile payment environment, the payment methods can share the same dynamics. Within the four stages, there are certain kinds of operations among the four parties, although not all the operations may be needed, depending on the stages and scenarios.

  • Registration. There is a communication between the MC and CP/M that ensures that the content is accessible. During this stage, the MC uses a personal identification number (PIN) for identification and authentication. The MC obtains service details such as the category of payment, the characteristic of the content, as well as the confirmation of the payment after the service. During this operation, an identity number is allotted to the consumer, which uniquely defines the identity of the CP/M during each transaction and a service is initiated. In general, this operation ensures the security of the payment.

    Figure 3. A typical micropayment scenario
  • Charging. Once the registration is completed, the CP/M submits the authentication and authorization requests to the PSP, initiating the charging session. At the end of every service or time interval, the content provider asks for a charging operation. The PSP settles the payment according to the default scheme, notifying both parties. This is usually presented to mobile consumers in the form of a receipt.

  • Request authorization and authentication. Before the start of a charging session, the mobile consumers must confirm that they are willing to pay for the service. This authorization request is often sent from the PSP in the form of a contract. The contract will describe the conditions and agreements between the MC and the CP/M. The charging session is initiated by the customer's acceptance of the contract. The MC is also requested to authorize the PSP. This can be settled by submitting the PIN from the MC. Authorization and authentication are completed using the same request. Authorization includes the authentication by PIN.

  • User authentication. The PSP will notify the authentication result of the MC to the CP/M. If the return of authorization request from the MC is positive, the PSP sends the CP/M a session ID, signaling the initiation of a charging session. It is vital to distinguish between micro- and macro-payments, since the security required in the two types is distinctly different. For example, authentication for every macro-payment transaction through a trusted financial entity is extremely important, whereas network authentication, such as SIM, may be sufficient for micro-payments that only use the operator's infrastructure.

Out-of-Band Payment Method

In the "out-of-band" model, content and operation signals are transmitted in separate channels, e.g., a credit card holder may use their mobile device to authenticate and pay for a service they consume on their fixed line Internet or interactive TV. This model usually involves a system controlled by a financial institution, sometimes collaborating with a mobile operator. There are two typical cases:

  • Financial institutions. Many banks are conducting research designed to turn an individual mobile unit into a disbursing terminal. Payments involved in the financial transaction are usually macro-payments, and various methods can be deployed to ensure the authentication of payment transactions. In credit card payments, a dual slot phone is usually adopted, while other approaches include PIN authentication via a SIM toolkit application or the use of a digital signature based on a public key infrastructure (PKI) mechanism, which requires 2.5G (or higher) technology.

  • Reverse-charge/billed SMS. In reverse-billed premium rate SMS, the CP/M deliver content to mobile telephone handsets (ICSTIS, n.d.). Customers subscribe to a service and are charged for the messages they receive. This payment model allows consumers to use SMS text messages to pay for access to digital entertainment and content without being identified. In this application, however, it is the SMS message receiver who is charged, instead of the sender of the SMS message. There are a considerable number of vendors who use reverse-charge/billed MSM service payment models.

"Inband" Payment Method

In this method, a single channel is deployed for the transfer of both content and operation signals, for example for a chargeable WAP service over GPRS. Two models of this in-band payment are in common use, namely subscription models and per usage payment models, with the amount of the payment usually being micro-payments. In-band transactions include applications such as video streaming of sports highlights or video messaging.


Proximity payments involve the use of wireless technologies to pay for goods and services over short distances. Proximity transactions develop the potential of mobile commerce, e.g., using a mobile device to pay at a point of sale, vending machine, ticket machine, market, or for parking. Through short range messaging protocols such as Bluetooth, infrared, RFID, and contactless chips, the mobile device can be transformed to a sophisticated terminal that is able to process both micro and macro payments .

Mobile Payment Standardization

Common Issues of Mobile Payment Standards

Mobile payment enables users to globally conduct payment transactions without physical contact. Unfortunately, regional distinctions and market dynamics often impose barriers that impede its development. A set of standards is required that are shared by all four of the parties involved, but dominant corporations are competing for the acceptance of their own standards, which will give them an advantage in their competition with their rivals. Among the different standards that are currently being proposed, the common issues being addressed include:

  • Security. Fraud deters usage and damages the trust of consumers and merchants in the integrity of the payment network. In addition, it adds considerably to the cost of operation. Therefore, increased security is vital for the development of mobile payment methods to address these issues. The main security elements include:

    • Authentication: This allows the payment service provider to determine that the person using the payment product is the authorized user.

    • Confidentiality: This ensures that unauthorized parties cannot gain access to sensitive payment data.

    • Data integrity: This ensures that payment data is not altered.

    • Non-repudiation: This binds the parties to the transaction so that they cannot later deny that they participated in it.

  • Interoperability. This strengthens any global payment system, ensuring that any participating payment product can be used at any participating merchant location.

  • Usability. According to studies of consumers' consumption behavior, they do not like to change their established habits and tend to opt for products that are user-friendly. This observation underlies the requirement for usability.

Standardization of the Payment Lifecycle

In support of uniform payment standards, the MPF (Mobile Payment Forum) is working on standardizing the phases in the mobile payment lifecycle, namely device set-up and personalization, payment initiation, authentication and payment completion:

  1. Set-up and configuration. When a mobile device is used to make a purchase, the owner who wants to get access to the mobile services should be able to set up the payment mechanism in the mobile environment. Set-up and configuration could take place over a mobile network or the Internet, or they could be done physically.

  2. Payment initiation. In this step, payment information is transmitted to the merchant over a network.

  3. Authentication. The authentication of the user is essential for any payment transaction. The MPF is considering two-way messaging authentication and SAT (SIM Alliance/Application Toolkit) authentication applications. The SAT authentication standardization includes defining a set of minimum requirements for authenticating, hence the cost of the bandwidth can be considerably reduced.

  4. Payment completion. This process takes place after the cardholder's details have been authenticated and the transaction is authorized. In a normal physical transaction, this involves the printing of a receipt for the user to confirm that the money has been transferred. In the mobile environment, the MPF is currently studying issues concerning the format and storage of digital receipts, together with the necessary redirection mechanisms.

SET (Secure Electronic Transaction)

Developed by Visa International and MasterCard International, the Secure Electronic Transaction (SET) protocol (SET Secure Electronic Transaction Specification, Version 1.0, 1997) is likely to become the global standard in the domain of electronic commerce over the Internet. This is a technical standard designed to provide security for payment transactions among cardholders, merchants, payment gateways, and certification authorities in wired networks. The SET mechanism is complex, and thus is mostly used in desktop computers and servers.

An SET transaction typically involves a communication between four parties: the customer, the merchant, the customer's bank, and the merchant's bank. Each of these entities needs to know certain information in order to perform its part of the transaction, but none need to know all the details of the transaction. Neither bank, for instance, needs to know what the customer is buying. The merchant doesn't need to know the customer's credit card number. He just needs to know that the customer has enough credit to pay for the order. The customer doesn't need to know who the merchant banks with. Assuming that the customer has an SET-enabled browser and that the transaction provider (bank, store, etc.) has a SET-enabled server, the process works as follows.

The customer opens a Mastercard or Visa account with some issuer (a bank) of credit cards and receives a digital certificate, which represents that customer/card combination in online purchases. The certificate contains both a public key and an expiration date.

  1. Merchants also receive certificates from the credit card issuer. These certificates include the merchant's public key and the public key of the merchant's bank.

  2. The customer places an order over a web page by computer, phone or PDA.

  3. The customer's browser requests and receives the merchant's certificate and confirms that the merchant is valid.

  4. The customer's browser sends the order and payment information (as two separate components) in a message that also contains the customer's certificate. The payment information is encrypted with the merchant's bank's public key and can't be read by the merchant. The order information is encrypted with the merchant's public key and can't be read by the bank. Additional information in the message ensures the payment can only be used with this particular order.

  5. The merchant verifies the customer by checking the customer's digital certificate. This may be done by referring the certificate to the bank or to a third-party verifier.

  6. The merchant sends a message to the merchant's bank which contains the customer's payment information, and the merchant's certificate.

  7. The merchant's bank verifies the identity of the merchant and the identity of the customer's bank, which is embedded in the payment information.

  8. The merchant's bank requests a payment authorization from the customer's bank. The customer's bank sends this (if the transaction is approved) and the merchant's bank relays this back to the merchant.

  9. The merchant completes the transaction with the customer, fills the order, and tells the merchant's bank (who relays this confirmation to the customer's bank) that this order has been completed.

  10. The customer's bank generates billing information for the customer and settles accounts with the merchant's bank.

Because SET relies on public key encryption to verify the identities of the customer, merchant and financial institution, as well as the symmetric encryption of an SSL or S-HTTP session, its computational demands are significant.

In a mobile commerce system, a WAP client device normally does not have sufficient processing and memory capability to utilize SET software. A "thin" SET wallet approach has thus been proposed to adapt the SET protocol for WAP clients. Under the "thin" SET wallet model, most of the functionality of current "fat" SET wallets is moved to the wallet server. To support a SET payment, a WAP client installed with only a "thin" wallet securely connects with a wallet server, which communicates with other SET entities. When SET purchase requests arrive from the "thin" wallet, the wallet server takes over the responsibility of routing requests and managing digital keys and certificates.

Wireless cellular system operators have an advantage as they become primary mobile payment system providers, because their existing service infrastructures already contain mature subscriber authentication and billing subsystems such as SIM. They can thus act as middlemen, charging an extra service fee, when transactions between merchants and users take place using their network systems. The i-mode model is one of this type.

Another approach is referred to as the "dual-chip" solution. This uses a Wireless Identity Module (WIM) card holding cryptographic keys as a second authentication module for the WAP security service. WIM can be apart of a SIM smart card issued by a cellular system operator or it can be provided by a third party, such as a bank or a financial institution. Motorola's Star Tac Dual Slot handset is capable of reading a third-party WIM card. The mobile payment standardization currently in use was developed by several organizations, as follows:

  • Mobey Forum (n.d.): Founded by a number of financial institutions and mobile terminal manufacturers, Mobey Forum's mission is to encourage the use of mobile technology in financial services.

  • Mobile Payment Forum (n.d.): Sponsored by credit card companies, including American Express, MasterCard International and Visa International, the Mobile Payment Forum is dedicated to developing a framework for standardized, secure, and authenticated mobile commerce using payment card accounts.

  • Mobile electronic Transactions (MeT) Ltd. (n.d.): Sponsored by key handset manufacturers such as Ericsson, NEC, Nokia, Panasonic, Siemens and Sony Ericsson, MeT's objective is to ensure interoperability of mobile transaction solutions. Its work is based on existing specifications and standards, including WAP.

Mobile Security Risk Management

Whenever there are risks or dangers, it is advisable to find ways of dealing with that risk. It is possible, of course, to pretend the risk does not exist and ignore it, but that is not wise when the potential consequences are great. The three main categories into which protective measures can be placed are (i) policies and procedures, (ii) awareness, education and training, and (iii) technology. Risk management also requires an examination of the cost/benefit ratio and a decision to be made as to whether or not the risk justifies the expense. Some protective measures, though desirable, will not be implemented because of the cost or the cost/benefit ratio.

Policies and Procedures

A security policy is a statement of usage rules and principles that specifies which activities are allowed and which are not allowed on that system. Policies will also typically list the rights of the users, and the rights of the employer, legal notices about copyrights and system monitoring, and a statement of management's intent to prosecute misusers. These policies are created and/or approved by high-level management and are intended to be read and adhered to by all users. Procedures are specific processes, approved by management, providing implementations or implementation guidelines that aid in enforcing the policy. By following procedures, users are forced to exercise due diligence, which protects the system from unnecessary risks and careless oversights. However, procedures are followed voluntarily by users, so they will not offer any protection against a malicious user. What happens if a PDA containing important private information is lost or misplaced? A well-established security procedure may be available to ensure an appropriate response. What types of information should have been (or NOT have been) on that PDA? Again, a security procedure could have guide decisions as to what to upload/download between a PC and PDA.

Awareness, Education, and Training

It is not feasible to write policies and procedures that cover all future events. Some are impossible to foresee, others may occur so rarely that they are simply not worth worrying about. Others may just involve the use of common sense, which it is assumed that all users will have. Thus, policies and procedures need to be augmented with some efforts to develop users' knowledge of these procedures, insight and intuition, so that they are more likely to respond correctly. Educating users and raising awareness of security concerns is a responsibility of management.

Technological Tools

Sometimes, a technological solution is available to address a security concern. If so, it may not be necessary to trust users to do the right thing because it will be done automatically by an automated tool. Link-level encryption, for instance, ensures that all transmissions are encrypted and does not rely on users to encrypt their own files before transmitting them, nor does it require the user to safeguard an encryption key. Biometric devices such as fingerprint scanners can be used to implement authentication with a higher level of confidence. Special Publication 800-48, Wireless Network Security from the National Institute of Standards and Technology is a useful source of information and guidelines for securing systems with wireless components.

Special Risks Associated with Mobile Security

While most mobile commerce security risks are shared with non-mobile systems, there are a number of risks which are particularly associated with handheld systems and mobile commerce. Special risks that affect mobile handheld systems include:

  • Wireless devices broadcast signals may be easily intercepted.

  • Broadcast frequencies can be jammed. This is another technique often used in denial of service attacks.

  • Handheld devices, with limited processing capability, have modest capabilities for encryption and decryption.

  • There is no firewall.

  • Mobile handheld devices are easily misplaced or lost. Physical security is therefore more of a problem.

  • Limited storage on handheld devices means that some of a customer's private information may be stored at a WAP gateway. This makes the gateway an attractive target for attacks.

Mobile devices, as they become more powerful, will eventually fall prey to all the same types of malware that attack desktop systems and servers. This includes viruses, Trojan horses, worms and denial of service attacks. Some recent examples of such malware are described below:

  • Denial of Service attack: In the summer of 2000, the SMS Flooder sent a massive amount of spam mail in the form of SMS messages to cell phone targets in Europe. The effect on affected cell phone users was that they were constantly being paged. This large number of SMS messages caused a considerable amount of inconvenience and frustration and effectively became a denial of service attack.

  • Computer Worm: Cabir, reported in June 2004, is a worm that uses Bluetooth connectivity to infect smart phones running the Symbian OS and Nokia's Seris 60 software. It has been described as a nonmalicious "proof-of-concept virus". Cabir replicates itself across Bluetooth connections and arrives in a smart phone's messaging inbox as a file named caribe.sis. The phone user has to accept the message and then must allow the file (from an unknown source) to install itself before the infection is complete and Cabir can continue to spread itself. The Cabir worm can reach only mobile phones that support Bluetooth, have Bluetooth switched on, and are in discoverable mode.

Top 10
Extending LINQ to Objects : Writing a Single Element Operator (part 2) - Building the RandomElement Operator
Extending LINQ to Objects : Writing a Single Element Operator (part 1) - Building Our Own Last Operator
3 Tips for Maintaining Your Cell Phone Battery (part 2) - Discharge Smart, Use Smart
3 Tips for Maintaining Your Cell Phone Battery (part 1) - Charge Smart
OPEL MERIVA : Making a grand entrance
FORD MONDEO 2.0 ECOBOOST : Modern Mondeo
BMW 650i COUPE : Sexy retooling of BMW's 6-series
BMW 120d; M135i - Finely tuned
PHP Tutorials : Storing Images in MySQL with PHP (part 2) - Creating the HTML, Inserting the Image into MySQL
PHP Tutorials : Storing Images in MySQL with PHP (part 1) - Why store binary files in MySQL using PHP?
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
Popular Tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS