Part 1 of e-commerce journey: Decide for payment gateway
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.
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).
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.
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.
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.
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:
References for more details about Accept.JS:
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.
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.