Part 1 of e-commerce journey: Decide for payment gateway
Audiences
This article consists of 2 parts and is specifically beneficial for only two groups of audiences.
1- Businesses Owners: This article would be valuable for business owners interested exploring and implementing a simplified approach to a payment gateway, particularly for businesses in North America and Canada.
2- Fellow Tech Enthusiasts like Me: In this article, I've happily shared some of my experiences with testing payment gateways.
Introduction
ove the past few weeks, I've been on the hunt for a solution to replace the payment gateway of a commerce site. I had two key objectives:
1- The solution shouldn't necessitate complex PCI-DSS (the legal aspect)
2- The design and user experience of the payment process are crucial (UX).
My Experience as Developer
When you first venture into the realm of documentation, you'll encounter numerous concepts and terms which might leave you feeling a bit bewildered. most of the time you find yourself juggling three distinctive facets of payment gateway simultaneously, striving to strike a harmonious balance among them:
1- The Technical Aspect: Security, UI and API, often takes the forefront.
2- The Legal Aspect: PCI-DSSs I mean! ๐ฉ
3- The Logical and Business-related Aspect: factors like time constraints and complexity, also plays a pivotal role in the equation.
First Step: Boring PCI Compliance!
There are 7 (or more probably) different levels of PCI DSSs. If you want to know more about PCI DSSs click here
For small businesses that prefer not to invest a lot of time in security and legal procedures and don't require a complex payment method (which may requires storing customer card data)there are two preferable options:
1- PCI DSS QAS A (I refer to this as Level A): The simplest one, you can't touch the sensitive card data (such as card numbers and expiration dates), even if you want ๐ . This option includes redirect (HPP), iframe (HPF), and other pop-up approaches.
2- PCI DSS QAS A-EP (Level A-EP): It is one step above Level A, and provides better control over the UX of payment form.
While you may briefly interact with sensitive data in the UI layer, you shouldn't send it to your server or store it. In this method a payment script manages sensitive fields and the payment button. This JavaScript replaces the sensitive data with a secure token called a payment nonce before submitting your form.
Whenever I discuss these various approaches, people often inquire about their visual appearance. I mean, the most significant challenge during this journey has been assessing the user interfaces (UIs) of these different methods. Aside from a handful of screenshots and some less-than-ideal videos, I couldn't find any live demos to evaluate the UI. Additionally, it remained unclear how much more challenging it might be for businesses to upgrade their PCI compliance even by just one level.
Live Demo for Accept.js and AcceptUI
If you're interested in exploring the UI and UX of Accept.js and AcceptUI from Authorize.net's service, you can access UI demos and HTML code here:
Option 1: Accept.js, Hosted Payment Form (Requires PCI-DSS SAQ A-EP)
Option 2: AcceptUI - Hosted Payment Form (Requires PCI-DSS SAQ A)
References for more details about Accept.JS:
Comparing Workflows: Accept.js vs. Accept Hosted Page
Within the Accept Suite of the Authorize.net website, you'll find two different options. the Accept Suite itself is a designed section with reduced PCI DSS requirements.
However, even within the Accept Suite you'll encounter two types, as mentioned earlier.
The primary difference between AcceptJS (or AcceptUI) and the Accept Hosted Page method (which includes redirect and iFrame) lies in their workflows:
1- In the AcceptJS workflow, you receive a payment nonce instead of sensitive card data before submitting the form to server. Subsequently, the transaction can be initiated on the server side. the payment response indicates the success of the payment.
In this method, you have two options. In the first option, you can design the entire form by yourself, including HTMl, CSS and JavaScript. In the second option, when you click on the Pay button, an iframe loads and displays a popup modal whose design cannot be changed.
(I must confess: It's a rather unfortunate Material Design form with fields shamefully underlined ๐)
2- With the Accept Hosted Page method, you have to initiate payment after the user has confirmed the price and order. Then you can send a payment request to Authorize.net (including details such as the amount, order specifics). after that you received a payment token, you can display the payment form to the customer.
This form loads within an iframe or on external pages. Unfortunately, you have no much control over the UI of that iframe.
Once the user filled out the payment form and clicked the pay button of Authorize.net iframe (or page), the transaction begins and a callback (or webhook, if you ahve configured it beforehand) will be sent to you.
Subsequently, you have to make an inquiry request to the API to confirm whether the payment was successful or not.
Top comments (0)