Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Payment Request API for Online Purchases in PWAs

DZone's Guide to

Payment Request API for Online Purchases in PWAs

How the Payment Request API can help provide in-app purchases in PWAs.

· Integration Zone ·
Free Resource

The Future of Enterprise Integration: Learn how organizations are re-architecting their integration strategy with data-driven app integration for true digital transformation.

New web APIs are closing the gap between native and web development. The rise of Progressive Web Apps (PWAs) is a great indicator of that. The typical mobile+web strategy makes less sense now for the great majority of applications. PWAs are a more cost-effective way to engage with your audience when compared to traditional mobile development. It’s hard to beat a single and continuously deliverable codebase with a single set of APIs that run everywhere.

Purchasing Online

A common use-case on mobile apps is for users to purchase items through the app. These items can be physical or virtual like a subscription or a game level-up. On mobile platforms, like iOS for example, there is a monopoly by Apple for the purchase and payment of these virtual items. Though this position has been seen as negative, resulting in high commissions, fees and a lock-in to a single payment provider, on the other hand, it can bring some value. A single user-experience for the purchase of items throughout all apps on the iOS platform that makes it easier for everyone to buy items in-app, which intuitively optimizes revenue generation for developers.

The experience of purchasing items on the web hasn’t been that easy and streamlined until now. Multiple forms with various input entries and complex workflows that change from website to website is hard for most people and it’s one of the top causes for shopping cart abandonment. It became evident that a better approach was necessary for the Web, especially given the seamless experience available today on mobile apps. Having this native experience as a benchmark, the Payment Request API emerged and became a very strong contender to narrow the gap between native mobile and web development, providing a unified and consistent experience to collect payment data from users without the friction of checkout forms or complicated workflows.

In a nutshell, the Payment Request API makes the purchasing experience:

  • Fast: users no longer have to fill out the same details repeatedly across different sites, payment details are entered once and stored in the browser.
  • Consistent: users will have the same visual experience and workflow when dealing with payments on the web, regardless of the website.
  • Accessible: the browser controls the input elements so consistent keyboard and screen reader accessibility is assured for every site without any additional development.

Browser Support

The W3C Payment Request API is still at a candidate phase but has built great momentum with major browser vendors. The API is supported in Chrome for desktop and Android, Safari for desktop, and iOS, Edge, Samsung Internet Browser, and others. Firefox has also been very active incorporating this new API, but it’s still in development and available behind a configuration flag.

Image title

To see the interactive version of this chart, visit the original article on the nearForm blog.

Apple seems to have decided to keep the Payment Request API only available for Apple Pay payments on Safari and iOS Safari. This goes in line with the monopolistic approach they adopted for the in-app purchases with the App Store for native apps. The good news is Apple Pay charges no fees for merchants, meaning that in-app purchases of non-tangible goods on your PWA can be achieved without the 30% fee that is currently charged on native iOS through App Store. The downside is that Apple Pay is not available in all countries, and making the API exclusive for this type of payment might exclude a significant amount of potential customers using Apple devices. In that scenario, an alternative payment data collection method without relying on Payment Request API must be put in place.

Payment Methods

When using the Payment Request API, multiple payment methods can be provided. These payment methods will fall into either one of two available categories: Basic Card or Payment Apps.

The basic card method is a model to facilitate card-based payments such as credit, debit or prepaid card payments. It is possible to restrict the payment to certain card types such as credit or debit but also to certain card networks such as amex or visa. When using the payment method, the API caller is essentially collecting raw payment card data from the user. As we will see further, this has PCI compliance implications.

The payment apps method facilitates payments using other 3rd party payment processors or wallets such as Apple Pay, Google Pay, and others. These payment processors could use any form of actual payment type such as cards, bank transfers, e-money, cryptocurrencies, etc.

PCI Compliance

When using the Payment Request API with a basic card method, raw card data will be collected from the user and therefore a certain level of PCI compliance is required. For businesses that already have the necessary PCI compliance, this might not be a problem, but for small businesses, it can be a hurdle or simply a deal-breaker. Many payment providers such as Stripe or Braintree already incorporate the Payment Request API into their SDKs. When requesting a payment using these providers, the API will be used if available. Since the API is being called by the payment provider’s iframe, the developer or merchant is kept away from raw payment data, having only access to tokenized data, and therefore keeping the PCI compliance scope to a bare minimum.

Sample Code

Here is a piece of code that shows how to use the Payment Request API. You can also test if your browser supports it.

const methodData = [{
  supportedMethods: 'basic-card',
  data: {
    supportedNetworks: ['visa', 'mastercard', 'amex'],
    supportedTypes: ['credit', 'debit']
  }
}]

const details = {
  total: {
    label: 'Total',
    amount: { currency: 'EUR', value: '17.30' }
  },
  displayItems: [{
    label: 'Some random item',
    amount: { currency: 'EUR', value: '10.00' }
  }, {
    label: 'Shipping',
    amount: { currency: 'EUR', value: '5.00' }
  }, {
    label: 'Sales Tax',
    amount: { currency: 'EUR', value: '2.30' }
  }],
  shippingOptions: [{
    id: 'STANDARD',
    label: 'Standard Shipping',
    amount: { currency: 'EUR', value: '5.00' },
    selected: true
  }, {
    id: 'EXPEDITED',
    label: 'Fast Shipping',
    amount: { currency: 'EUR', value: '10.00' }
  }]
}

const options = { requestShipping: true }
const request = new PaymentRequest(methodData, details, options)

request.addEventListener('shippingoptionchange', event => {
  event.updateWith(updateDetailsShippingCost(request, details))
})

request
  .show()
  .then(result => {
    // do stuff with the result
    result.complete('success')
  })
  .catch(err => {
    console.error('Something went wrong', err.message)
  })

Conclusion

The Payment Request API is one of many new APIs that is enriching the user experience of the Web and that is making Progressive Web Apps the best strategy to engage with your audience across all devices. The Web today is more solid than ever as a platform to build any app. If you need help setting up your Progressive Web App or want to learn more about it, get in touch with us at nearForm.

As a companion to this article, we have done a screencast to demo how the Payment Request API looks, both on desktop and mobile.


Links:

  1. https://baymard.com/lists/cart-abandonment-rate
  2. https://w3c.github.io/payment-request/
  3. https://webkit.org/blog/8182/introducing-the-payment-request-api-for-apple-pay/

Make your mark on the industry’s leading annual report. Fill out the State of API Integration 2019 Survey and receive $25 to the Cloud Elements store.

Topics:
integration ,apis ,browser support ,pci compliance ,pwas

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}