Checkouts have always been a pain point on mobile for both retailers and customers. There’s certain important information that needs to be exchanged before goods can be purchased and shipped, but that’s easier said than done on mobile. Whether it’s from filling out forms with small, virtual keyboards, security concerns, or simply being interrupted, web payments inhibited by poor checkout flows have meant that conversions on mobile have remained 66% lower than desktop.
However, the PaymentRequest API is designed to eliminate checkout forms, thereby increasing conversions on mobile. It vastly shortens the amount of time it takes shoppers to make web payments, providing a more consistent user experience and enabling m-commerce merchants to easily accept disparate payment methods.
Have a read through my post, watch a recorded version of the webinar, or scroll down for FAQ&A.
Out with the Old
Traditional web payments are a series of forms, requesting the same standard information: name, shipping and billing addresses, phone number, email, and credit card information. It’s spread across numerous pages, which means increased time spent waiting for pages to load, not to mention the tedious task of typing into a tiny virtual keyboard.
With PaymentRequest you basically remove three full pages from the process: shipping information, billing information, and credit card information. The manual form-filling is replaced, and the payment information is quickly collected and returned between customer and retailer with PaymentRequest. This reduces the chance of a customer getting interrupted by the many distractions on their mobile shopping journey: a baby waking from her nap, the train entering a tunnel, or the boss walking over to their desk.
Three Wise Goals
The PaymentRequest API was designed with 3 goals in mind.
First, we wanted to get users through checkout flows as quickly as possible. Cumbersome checkouts are a major source of customer drop-off and cost retailers millions of dollars in revenue every year. But browsers like Chrome are already trusted by users to store personal information such as name, email, phone, address information, and even credit cards, which is the same information that’s requested of users in almost every checkout flow. PaymentRequest allows us to quickly share this information with websites once user consent is given, making web payments quick and seamless.
Second, we know that returning accurate information is vital for web payments. PaymentRequest transmits quality, user-verified data that you know is up-to-date and correct. Customers can easily toggle between different shipping addresses and payment options.
Last (but not least), securing the information of customers and merchants is a non-negotiable. Fast and secure web payments means supporting new web payment methods, such as Android Pay, that rely on tokenization to protect both merchants and users.
The Conversion Connection
We know the payment phase of checkout is a critical component to get right on mobile. Customers are so accustomed to the checkout phase taking a long time that they often leave items sitting in their cart. While many shoppers might be heading into a store to complete their purchase, the ones that want to “buy now” are faced with a process that ignores the reality of mobile moments.
PaymentRequest allows allows you to easily explore new UX patterns. You can add a BUY NOW button directly to your product page if you want, tailoring the checkout to go from mobile micro-moment to checkout in a matter of (uninterrupted) seconds. It’s all up to you, and what works best for your customers.
We’ve answered some of the most popular questions from our RIP Checkout Forms webinar below. You can also watch a recorded version of the webinar here, and send any follow-up questions to email@example.com.
Where and when will PaymentRequest be available?
PaymentRequest will be available in Chrome on Android starting early September. We expect to have support across all of Chrome platforms (including desktop) by early 2017.
Is this just for Chrome, or are other browsers supported too?
PaymentRequest is an open standard, so all browsers can support it. In fact, Microsoft, Mozilla, and Apple are all a part of the working group that build the standard. So Chrome is the first to implement, but we don’t think we’ll be the last.
Security is a big issue for my customers. How have you addressed security concerns in PaymentRequest?
Security is incredibly important to us, too. By default, PaymentRequest is only available in secure contexts, which means a website has to support valid HTTPS. PaymentRequest also allows us to bring more secure forms of payment to the web with offerings like Android Pay, which protect users information even more by exchanging real credit card information with tokenized forms of payments.
How long will this take to implement?
The API itself is pretty straightforward. It’s definitely measured in hours and days, not weeks and months. One thing that’s important is to make sure that you’re matching the form fields that you had previously and how that data is passed to the PaymentRequest API so that you’re getting all the fields you were asking for previously.
If you have lots of validation in your checkout flow there’s probably some extra work to do around quality assurance to make sure that you’re getting everything and customers are able to complete their checkout process and that the elements that you usually had validations on that they’re still present after you implement the PaymentRequest API.
Currently our mobile website is using Mobify’s Platform. When desktop code changes how will PaymentRequest handle those changes? Will we have to update mobile code to make sure there is no breakage?
PaymentRequest is part of the payments feature in the Mobify platform. Talk to your customer success manager to upgrade.
How does this work with other payment methods (e.g. Paypal)?
PaymentRequest is an open standard, built to work with any and all payment methods. That said, for our initial launch, we’re starting small with support for credit cards and Android Pay. We hope to support third party payment methods soon.
Will customers think we are invading their privacy? How do you address that?
We care deeply about user privacy. Users always have a chance to review their information before it’s shared with the merchant.
I travel a lot. Will this be able to support multiple addresses?
PaymentRequest is built to fully support multiple shipping addresses, especially inside of Chrome. You can tap on the default address and select a different one, or add a new one if it doesn’t exist.
Is it tailored to support alternative delivery options (e.g. Collect in store)? How will this work from a UX perspective?
Right now PaymentRequest is built to work best with shipping to a home or office, not so much for in-store pickup. That said, even if you can’t use PaymentRequest for shipping information, you can still use PaymentRequest just to collect payment information.