Payment Integration

This replaces the payment forms on a site with a much simpler experience on mobile devices. So let’s talk about paying for things on the web. This is a longer talk, so let me give you an idea of what’s coming up. First, we’ll talk about the user experience today and what could be better, we’ll look at the payment request, API twice.

First, to give you the big picture, then we’ll dive into the code. Finally, you’ll get the usual resources in lab. It’s no surprise, given the rise of mobile computing, that a majority of commercial traffic is coming from mobile devices, what is surprising is that 66 % of that mobile commerce is still happening on the web, even when people have native apps installed. Unfortunately, we also see a lot lower conversion rate on mobile web relative to desktop websites.

Mobile conversions are about one third of the desktop conversions. If you wonder why this is the answer is pretty simple. Checking out collecting payment from the user is still rather messy. People often give up while filling the checkout form some checkout forms have improved since the beginning of web Commerce. What hasn’t changed is you still have to manually input the same information credit card billing address and shipping address? Our first step to solving this problem is autofill, because autofill works on existing forms.

You don’t have to modify your site. Autofill just works to help users check out faster autofill alone increases conversion rates by 25 %. Autofill does a good job of identifying form fields, but it’s not perfect. If you want an even better experience, you can have the autocomplete attribute to your forms. In this example, we’ve annotated the credit card portion of a form using values such as CC name and CC.

Number autofill will know exactly where to place its information. If you want to learn more about autocomplete attributes search the web, using what WG autofill to find the specification, autofill gets rid of the manual nature of data entry and makes it much simpler for the user. The current checkout experience presents you with a form to fill out every time for users, though the ideal experience would be that, when it’s time to buy they just buy site should be able to focus on creating an amazing and engaging shopping experience without worrying about optimizing.

A long checkout form this is where the payment request API comes in, we’re going to look at it first from a user perspective and then look at the code. What if we could do away with the form using web payments when it’s time to pay the user? Just pays payment request is a simple JavaScript API that helps the browser collect payment information. Then it’s a simple one: tap checkout for the user and an easy way for a site to receive a payment.

With the payment request API, you can make the whole process much faster and simpler and since the browser is actually taking care of collecting payment information from the user, we go from end taps to one tap. Let’s take a quick look at the code flow here. First, the site initiates a payment request in this request. The website passes to the browser the parameters of the payment, for example, how much is being charged and the available forms of payment? Don’t worry about the details now we’ll come back in a few minutes and look at this in detail.

The browser then determines the intersection of payment methods from the site and what the user has. It then presents a selection UI where the user chooses their method of payment. You get the UI by calling show this displays a native UI over the browser within this UI, the user can change how to pay the delivery method and the delivery address. The payment method can be credit cards or one of the apps that’s installed on their device, such as Android pay and, finally, the user taps on pay.

Then the browser requests a response from the selected payment method. This might be an app on your device or going directly to a payment provider. The payment processor verifies the request by examining its details and then returns the response directly to the server and the website now has all the information it needs to process the payment. Is this safe? The API is more secure than forum based payments.

The new payments are based on modern cryptography. You don’t need to enter payment data that could be logged or observed at the point of entry. Autofill is safe from website access and is typically stored. An encrypted storage on the hard drive to prevent disclosure, even when the OS is compromised payment request, is not just a chrome only API. The API is currently under development in the w3c web payments working group.

The goal is to create a universal cross browser standard for any website to accept any form of payment so to review payment requests, eliminates manual and tedious entry by storing the user’s information securely in the browser. The browser passes, addresses and credit card details immediately and securely to the site, and since the browser is collecting payment information from the user, we go from end taps to one tap: you’ve seen how payment request works for the user.

Now, let’s go over the code in more detail. First, a quick review. The site initiates a payment request in this request. The website passes to the browser the parameters of the payment, including the price and the payment methods accepted. The browser determines the intersection of payment methods for the site and the user and presents a selection. Ui payment can be anything from a simple credit card payment to a payment application installed on the user’s device.

The browser requests a response from the selected payment method and returns the response directly to the merchant. There are multiple code samples for this on: Google, Chrome, github, dot, io. Let’s start writing some code. Step 1 is to tell payment requests. All the ways you can get paid. Step 2 is to define the details about the actual transaction cost items, currency, shipping options and so on.

Here’s an example of how you would define shipping options notice. The selected bit you can include this: if you have multiple options, the browser will tell you which one the user selects step 3 is to define what information you want. The API to collect. Take the three data structures you just created and pass them to the payment request. Constructor. You often do this when the user indicates they’re ready to pay, take the request and call it show method.

This returns a promise and opens the user interface. The UI shows the details of the purchase and collects payment information when the user approves the prom resolves with a payment response object. Next, you should check that the payment is valid. Send the information to your payment processor for processing the UI will show a spinner while the request takes place when a request comes back, call complete to close the UI.

The complete method tells the user agent that the user interaction is over. The payment response object contains everything needed to submit a payment for credit card payments. The response is standardized for non credit card payments such as Android pay. The response will be documented by the provider. There’s one loose end to tie up what happens if the user changes their shipping address or options.

This may change the total cost and in some cases, may change the shipping options. Payment requests can omit shipping address, change and shipping option change events. You should add event. Listeners for these and update the payment details. Accordingly, the sample code will show you how and that’s it. You can find a full set of resource links on this final slide. You may have noticed. I didn’t mention a lab, we’re just finishing it up at the time of filming, so check your lab notebook for a complete ecommerce example.

---