NFC Mobile Payment Architecture - Option 3
C. Third Architecture Option
Third option represents the architecture with an even bigger role of Mobile Device manufacturers and designers of Operating Systems (OS).
Apple will most probably present its NFC mobile payment architecture with the new iPhone in July 2011. The reason so much attention is given to Apple in the Option 3 architecture is that this exact architecture is what everyone expects Apple to introduce. Other possible players in this architecture are Nokia, Google with Android OS and Samsung and HTC as biggest supporting device manufacturers and RIM (Research in Motion) with Blackberry devices.
Google and Apple have been most persistent to entire the mobile payment market lately, and the question is whether they are ready to go into the game with companies like PayPal, which have been in the payment field for more then ten years. Apple is known to be strong on customer service, which is very important in payments, while Google is stronger in technology-driven risk management and has the experience from Google Checkout.
Third option Architecture is shown on Figure 3, and there are only a few, but important differences compared to the first option, shown on Figure 1. In a way the Online Service takes the role of Credit Card companies from the first option, and the joined role of Trusted Third party and Credit Card companies from the second option. This does not mean that Online Service will have exactly the same role like the mentioned parties. First, there is one significant difference in the Architecture Diagram: There is no need for Interface 7, because communication between mobile carrier and Online Service is not necessary here.
MNO will only play the role of providing Internet connection to the Customers Mobile Device in this architecture. This means that connection between Mobile Device and Online Service (Interface 3) is physically realized via Interface 1.
Some of basic principles of this architecture are already presented in the Introduction section of this document. The most important player is the company that owns the online store where customer has an account and connects using the NFC Mobile Device, which is in this case OS designer company. Customer needs a Mobile Device equipped with NFC chip and with online service application and a valid account in the online service connected to his credit card.
As presented in the Introduction section, online service can be Apples iTunes, Google’s Market Place or other. Application is to be provided by the online service company, which is the case of this architecture the OS designer company.
Typical payment process starts when user decides to pay for the service or product by Mobile Device using NFC technology and online service account. In order to do so, the first step is entering the application and connecting to online service using the existing account information, such as username and password via INT3. Users Mobile Device needs to have an existing connection to Internet, most probably provided by MNO, but in the case of this particular architecture other type of Internet connection is also allowed.
Once user is authenticated to the online service, he needs to read the payment information from the terminal NFC chip via INT2. Once the information is obtained, it gets forwarded to the online service for processing.
Before the user can proceed with the payment, online service needs to perform another authentication to confirm that the user who logged in was the one who requests the payment.
This step is pretty important, because simple PIN authentication might not be sufficient to qualify this system as secure payment method. Out-of-Wallet questions might be a good solution, unless the Mobile Device is equipped by some more reliable technology, such as fingerprint scanner.
Once the online service has the payment information and has authenticated the user, the required amount is charged from users credit card that is connected to online service account, starting by Issuing Bank determining that user has sufficient funds to perform the payment. "Hold" for the transaction amount is placed on the account.
When online service gets the positive response from the Bank, users Mobile Device gets the notification of the successful payment from the online service. The only step missing is notifying the company that provided the paid service or product about the transaction status. Just like in the Second Architecture there are a few options to realise the confirmation. First one is by establishing another NFC session between Mobile Device and the terminal, where the device would transfer signed confirmation provided by online service. Second option is that online service communicates directly to terminal, and notifies about the transaction status.
Mobile Network Operators provide the necessary standard data transfer services only, which means that additional security mechanism has to be implemented by online service for communication between Mobile Device and the service. Credit Card companies could maintain current roles in online services, such as iTunes and Market Place currently use, with the additional business provided by NFC payments. The problem of this architecture still remains determining the party that provides the payment terminals. One of the options is adding the feature to new models of credit card terminals, but this is the issue of accordance between online service, terminal manufacturers and Credit Card companies.
There is another possibility where the OS designers can actually avoid Credit Card companies and design a system where money is being transferred directly from customer’s bank accounts to service provider’s bank accounts. This concept might not be likely to be implemented in the dear future, having in mind security issues that companies like PayPal who have be doing payment services for more then 10 years have been trying to overcome. This means that credit card payments will continue to be a part of the process, which on the large scale means that this architecture also brings them a lot of profit. More cost effective solution for companies like Apple and Google would be a direct bank transfer, and it is likely that in time they will try to push Credit Card companies out of the game by implementing such a system. Even though their online services have many users, direct bank transfers are different, with a whole other set of issues. First problem is the lack of standard verification process, and lack of international coverage. Even bigger issue is the time banks take to confirm the payment. In certain EU countries, like Spain, it may last up to three weeks. On the other side, there is a possibility that Apple and Google will follow the example of DoCoMo in Japan and also design their own credit card ID and transaction system.
Third option represents the architecture with an even bigger role of Mobile Device manufacturers and designers of Operating Systems (OS).
Apple will most probably present its NFC mobile payment architecture with the new iPhone in July 2011. The reason so much attention is given to Apple in the Option 3 architecture is that this exact architecture is what everyone expects Apple to introduce. Other possible players in this architecture are Nokia, Google with Android OS and Samsung and HTC as biggest supporting device manufacturers and RIM (Research in Motion) with Blackberry devices.
Google and Apple have been most persistent to entire the mobile payment market lately, and the question is whether they are ready to go into the game with companies like PayPal, which have been in the payment field for more then ten years. Apple is known to be strong on customer service, which is very important in payments, while Google is stronger in technology-driven risk management and has the experience from Google Checkout.
Third option Architecture is shown on Figure 3, and there are only a few, but important differences compared to the first option, shown on Figure 1. In a way the Online Service takes the role of Credit Card companies from the first option, and the joined role of Trusted Third party and Credit Card companies from the second option. This does not mean that Online Service will have exactly the same role like the mentioned parties. First, there is one significant difference in the Architecture Diagram: There is no need for Interface 7, because communication between mobile carrier and Online Service is not necessary here.
MNO will only play the role of providing Internet connection to the Customers Mobile Device in this architecture. This means that connection between Mobile Device and Online Service (Interface 3) is physically realized via Interface 1.
Some of basic principles of this architecture are already presented in the Introduction section of this document. The most important player is the company that owns the online store where customer has an account and connects using the NFC Mobile Device, which is in this case OS designer company. Customer needs a Mobile Device equipped with NFC chip and with online service application and a valid account in the online service connected to his credit card.
As presented in the Introduction section, online service can be Apples iTunes, Google’s Market Place or other. Application is to be provided by the online service company, which is the case of this architecture the OS designer company.
Typical payment process starts when user decides to pay for the service or product by Mobile Device using NFC technology and online service account. In order to do so, the first step is entering the application and connecting to online service using the existing account information, such as username and password via INT3. Users Mobile Device needs to have an existing connection to Internet, most probably provided by MNO, but in the case of this particular architecture other type of Internet connection is also allowed.
Once user is authenticated to the online service, he needs to read the payment information from the terminal NFC chip via INT2. Once the information is obtained, it gets forwarded to the online service for processing.
Before the user can proceed with the payment, online service needs to perform another authentication to confirm that the user who logged in was the one who requests the payment.
This step is pretty important, because simple PIN authentication might not be sufficient to qualify this system as secure payment method. Out-of-Wallet questions might be a good solution, unless the Mobile Device is equipped by some more reliable technology, such as fingerprint scanner.
Once the online service has the payment information and has authenticated the user, the required amount is charged from users credit card that is connected to online service account, starting by Issuing Bank determining that user has sufficient funds to perform the payment. "Hold" for the transaction amount is placed on the account.
When online service gets the positive response from the Bank, users Mobile Device gets the notification of the successful payment from the online service. The only step missing is notifying the company that provided the paid service or product about the transaction status. Just like in the Second Architecture there are a few options to realise the confirmation. First one is by establishing another NFC session between Mobile Device and the terminal, where the device would transfer signed confirmation provided by online service. Second option is that online service communicates directly to terminal, and notifies about the transaction status.
Mobile Network Operators provide the necessary standard data transfer services only, which means that additional security mechanism has to be implemented by online service for communication between Mobile Device and the service. Credit Card companies could maintain current roles in online services, such as iTunes and Market Place currently use, with the additional business provided by NFC payments. The problem of this architecture still remains determining the party that provides the payment terminals. One of the options is adding the feature to new models of credit card terminals, but this is the issue of accordance between online service, terminal manufacturers and Credit Card companies.
There is another possibility where the OS designers can actually avoid Credit Card companies and design a system where money is being transferred directly from customer’s bank accounts to service provider’s bank accounts. This concept might not be likely to be implemented in the dear future, having in mind security issues that companies like PayPal who have be doing payment services for more then 10 years have been trying to overcome. This means that credit card payments will continue to be a part of the process, which on the large scale means that this architecture also brings them a lot of profit. More cost effective solution for companies like Apple and Google would be a direct bank transfer, and it is likely that in time they will try to push Credit Card companies out of the game by implementing such a system. Even though their online services have many users, direct bank transfers are different, with a whole other set of issues. First problem is the lack of standard verification process, and lack of international coverage. Even bigger issue is the time banks take to confirm the payment. In certain EU countries, like Spain, it may last up to three weeks. On the other side, there is a possibility that Apple and Google will follow the example of DoCoMo in Japan and also design their own credit card ID and transaction system.
Comments
Post a Comment