Payment step is often painful on a web site, especially if it's the first time you buy on it. Nowadays, most of the websites allow you to save your credit card after first order (or use alternative wallets like paypal). This first order can be a blocker in user experience flow, especially on mobile where a typo can happen quickly.
W3C is working since last October on a new set of APIs to allow browsers to act as your wallet. It will contain your payment data and, if the website supports it, will provide them to process payment more easily. Specifications are still in draft and will continue to evolve.
Chrome 53 has just released on their Dev branch a first version that supports these APIs, limited to credit cards and mobile version only for now.
How does it work?
On the contrary of automatic fill that already exists, these APIs are designed to abstract payment methods.
Once you're on the billing page, the website prepares a request to the browser with accepted payment methods. If some of them exist in you wallet, the browser displays them for you to pick the one you want to use. The API, in addition to payment information, is also designed to store billing and shipping address so you won't need to input them again.
(Credits Chrome Developers website)
For credit cards on Chrome, you are being requested to confirm you are the owner of the card by providing CVV again for each payment. Once confirmed, payment information are then passed to the page that can call the actual payment using the credit card number and other data. Credit cards won't be the only payment method supported but is the one that implies most critical work for security reasons.
If no payment is found, a more classic payment flow is proposed to the user.
Browser (or any application that could use these APIs) is in charge of data storage security, which means storing your credit card number (including CVV for validation purpose). Chrome added the CVV validation when you want to use your credit card which reduce the risk to use it if your phone is stolen (phone covers which contain credit cards are already at risk anyway even without this API).
Websites have to be secured by HTTPS connexion and certificate should be a valid one (which is now easy with solutions like Let's encrypt) and have to be opened as a top level page. PaymentRequest API is not allowed in an iframe yet, even if the context is secure (HTTPS iframe in an HTTPS page). Discussions are on-going inside workgroup to keep or not this limitation but for now the limitation remains.
Other validations like 3D Secure scheme have to be handled by the website or third party.
(Credits Chrome Developers website)
PCI compliance is a set of rules / best practices to work with credit card data on a merchant website. Even if it's not a legal constraint to work with credit cards, if you do not follow these rules you may not work with some other companies and it could cover you when an incident occurs involving payment system.
PCI compliance is applied in various situation but for a website there are 3 compliance levels:
- PCI A Level: it's the most basic one for merchants. Every aspects of the payment are handled by a third party (which is PCI compliant on his side). Merchant website does not provide nor the payment processor nor the form to provide credit card number. Integration varies from one payment processor to another to offer UI customization and integration into the website. Constraints are limited to basic best practices like no default passwords on website servers, access control measures... This level is the one by default for small merchants or merchants for which e-commerce is only a side activity.
- PCI A-EP Level: this level has been created in 2014 as an intermediary level. Merchant website can host the form to provide credit card information (to have a total seamless user experience) but data have to be post directly to payment processor without going through merchant system. In addition to PCI A constraints, merchants at this level have a long list of constraints with increased network security (firewall, DMZ, full network map), more complex architecture (one primary function per server, you can't have 1 server for both Web app and DB for instance), disable anything unused on server, proof of code reliability, vulnerability scans, secure physical access to servers and data storage...
- PCI D level: this top levels allows merchant to work with credit cards data at their fullest. Compared to PCI A-EP level, it mainly add rules about credit card data storage. Once you are PCI A-EP, you're closed to PCI D in terms of constraints.
Due to the constraint of top level page, PCI compliance may be impacted for small merchants who are PCI A compliant. To remain at this level, payment by credit card will necessary have to be in a top level page which can add an additional step in payment flow if third party was integrated in an iframe until now. A solution would be to add a "blank" page just before the shipping page, hosted by payment processor. On this page, payment processor tries to invoque PaymentRequest API to get a payment. If no payment is found, then customer is redirected to "standard" payment flow with potential iframe integration. If yes, once user selected payment it's processed by staying in third party domain. Integration is more difficult for the merchant, impating tracking for conversion rate and potentially creating issues with "Sales and Conditions" acceptance but it would be the one with the less impact on the overall user experience.