You don't even need a secure area on the smart phone. You could put a thumbprint reader on the phone, then generate a hash from the thumbprint, then use that hash to generate a public/private key pair, then encrypt the credit card details with the details with the public key. The phone would never have to store the private key at all. That is just one of many ideas that would help make this secure. Among others: 1. Require a thumbprint *and* a PIN code 2. Have a uber-long password to reset things in case the thumprint or PIN don't work 3. Have a website to blacklist lost or stolen phones, not just some obscure phone number 4. When talking to other NFC equipped terminals, don't send the credit card data. Have the phone sign a "transaction receipt" with your private key. This would prevent replay attacks and no one would ever even have you card number 5. Create a seperate pay-pal like account that users could put limited funds in, so if their phone was stolen, they would only lose the money in that account and in addition, there could be many cool new features: 1. Put NFC readers on laptops, and use the public key idea for online shopping 2. Use your public key for door locks, and throw away your keychain *and* your wallet 3. Keep a list of transaction details on the phone, then sync up to Quickbooks at night This technology could be super cool if they did it correctly, but as usual it seems to be implemented in the most half-assed way possible. Did these guy even contact and independent security firm to audit this before release? Did they hire someone like Bruce Shnier to architect it securely in the first place? Or did they just have a couple of MBAs, junior devs, and a few legal people draw something up on a whiteboard?

I've been responsible for maintaining CAD software with client apps in C++ / C# / JS / Flash. Because I found commonality between all these languages, I was able to port the code quickly and easily. Some tips:
1. Keep all the state on the client side. This means put everything on one HTML page, then manipulate the DOM to add controls, etc
2. Create a set of HTML+JS controls (say datagrid.html for example), then use jQuery to load instances of these controls into the DOM
3. Aside from the initial page load and loading of your controls, the only other reason to call to the server is to save & load data via webservices
4. Classical inheritance is a subset of prototypical inheritance, therefor you can emulate it perfectly. See the below examples:
Base class: http://pastie.org/3341844
Subclass: http://pastie.org/3341846
Clone function: http://pastie.org/3341847

If you think of HTML+JS just like you would MXML+AS or XAML+C#, then your app works the exact same way! HTML5 doesn't have to be any difference from the traditional model, you just have to tinker around with it more to achieve the similarity, since there isn't really a built-in concept of controls. Lastly, install Chrome. Since there is no compile-time, this is your new IDE. If you go into "developer tools" you have all the traditional stuff: call stack, break points, watch window etc. You still have to write your code in notepad without auto-complete, but everything else you do right in the browser. You can even use the watch window to inspect what methods are on an object, so you can use this as a sort of "manual" auto-complete!

PS, before I get modded down, please see that this was an honest attempt to directly answer the author's question.