In the first part, we explained the basic concept of the bank card system and explored the differences between hosted and non-hosted payment gateways from the perspective of integration complexity and control of payment page. In this part, we’ll compare the two in terms of security, user experience and Payment Card Industry Data Security Standard.
Security Concerns
As far as security during payment processing is concerned, the merchant doesn’t have to worry too much since their service provider offers a comprehensive fraud solution. However, using a non-hosted payment gateway means you are responsible for ensuring the security of transactions and data protection. Although two different types of payment gateways may choose the same vendor as a fraud prevention solution, it’s often easier to incorporate the hosted payment gateway. Merchants that integrate the Hosted Payment Gateway don’t have detailed information regarding customers' credit cards. As a result, when using anti-fraud services, it usually requires only one or a few simple API requests. Additionally, many mainstream anti-fraud solutions can be integrated into both hosted and non-hosted payment gateways, such as EMV3DS. Therefore, there is not much difference between the two in regard to security.
User Experience
When considering the user experience, the non-Hosted Payment Gateway offers merchants the ability to customize the payment interface and more controls of the customer experience. As a merchant, you can standardize the overall style of the payment page, logo, and the main site. This increases the trustworthiness of the site since there is always one merchant at any given time providing end-to-end services. Payment service providers now allow their merchants to display the merchant's name and logo on the Payment page. The result is that the user is still led to believe a merchant is servicing them from beginning to end, thereby reducing their concerns about payment fraud. Hosted payment gateways don’t offer such customization capabilities. As Gateway has complete control over the payment page, they have a responsibility to create the payment page available to the merchant, who may be limited to adjusting the input field sizes and text fonts during integration.
PCI DSS Level
A merchant must follow Payment Card Industry Data Security Standard (PCI DSS) when accepting card payments. There are four levels of PCI. Unless your company processes over 6 million transactions per year, you don't really need a PCI Auditor for the other three levels. Merchants who conduct fewer than 6 million transactions per year are required to complete a SAQ (self-assessment questionnaire). The amount of SAQ questions you need to answer varies based on the type of payment gateway. Merchants only have to answer 22 questions for the lowest level of SAQ A. To pass the highest level, SAQ D, merchants must complete 329 questions, a vulnerability scan, and a penetration test. Merchants have the option of a different payment page with most hosted payment gateway providers, but as a general rule, they don't have access to the card information of their customers, so the risk is low. When the non-hosted payment gateway is used and their method for collecting card details is through the payment gateway API, the level of risk will be high. The SAQ corresponding to this will normally be SAQ D. SAQ D will require more time and effort from you than SAQ A.
As choosing a type of payment gateway becomes an issue for you, you need to ask yourself, can your site, and your business, grow? A fully-fledged non-hosted payment gateway will undoubtedly deliver a better experience and more functionality than a hosted payment gateway. Additionally, the need for customization can be more relevant to their business and seamlessly integrated with the platform of merchant websites. However, it can often be more costly to build and maintain. It’s essential that merchants understand the current needs and development direction of their business, as well as its stage of development, to make an informed decision.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
