Sometimes we get frustrated at the lack of available information so we dig in to author educational pieces.
The following piece took nearly 4 months of interviews to get right. We hope it’s helpful.
A long time ago (i.e. pre-2010) everybody in software needed a payments gateway.
Gateways were the (mostly) neutral technology layer that stood between a payment acquirer and software.
The software provider, or ISV for independent software vendor, was usually overwhelmed with investments in engineering, fielding customer calls, and putting in long hours to ensure customers were well-served.
Payments acquirers were, well, looking for the shortest path to reap the largest profit, almost exclusively at the expense of the merchant and with little regard to the ISV, whom they viewed as an inconvenience on their way to bludgeoning the merchant with fees.
In 2010 the tables, which were slowly turning since the early 2000’s, started to move in meaningful ways with the advent of the payfac, or payment facilitator. Under this model of payments acceptance, the ISV didn’t need an acquirer to create more problems and could instead verticalize the lucrative payment stream for themselves, cutting out the endless middlemen of payments distribution (small acquirers, ISOs, and agents).
Mercury Payments was perhaps the best-timed exit in this software-bundled model of acquiring, partnering with ISVs for distribution but doing so before the ISVs realized that they didn’t need Mercury at all.
Nowadays the payfac model doesn’t make any sense for ISVs doing less than billions of dollars in processing volume, so the vast, vast majority of ISVs are turning to payfac lite models that give them 90% of the flexibility of the payfac at a fraction of the cost and time to set up.
There’s obviously still room for gateways, but they tend to exist for complex challenges nowadays:
- Enterprise merchants demanding full control over their acquiring (i.e. working harder than should be necessary to avoid being shafted by an acquirer)
- Entities (e.g. merchants or ISVs) conducting commerce across multiple countries that benefit from intelligent routing (in the modern era this is branded as orchestration)
- Entities with a franchise structure that don’t have mandates for tech/finance stacks
- ISOs with their own BIN that want portability
- Any acquirer that needs to support merchants/partners with multi-acquiring capabilities
Which gets us to the point of this educational article:
What’s required in building a gateway anymore?
The most critical decision that has to be made from the start is this:
Who’s bringing the devices?
That’s because this decision will shape the vast majority of the gateway’s overhead.
Some gateways opt to integrate to every device, supporting ultimate optionality. Gateways that have chosen this path would be those like ACI and DataCap.
But this comes at the massive cost of continued support for a near-endless number of devices.
The other approach is to limit the number of supported devices. FreedomPay and Accept.Blue are gateways that have stuck closer to this path, with FreedomPay only supporting Ingenico devices until a few years ago, and Accept.Blue only supporting two Equinox devices today.
The reason this matters is because each device needs to be certified to a processor (called a processing host in this situation) for Level 3 EMV certification. And this list becomes unwieldy as the devices and geographies grow.
For example, Fiserv isn’t just one acquiring host: it has a number of endpoints that each require their own Level 3 certification.
Considering that a Level 3 certification takes about 3-6 months to complete, you can see why gateways can take multiple years to support certain endpoints. (Note that it’s possible to run several Level 3 certifications in parallel which would, in theory, condense timelines).
But it’s not a requirement that the gateway certify the device.
That’s because there are three parties who can ultimately code to the device.
The first is the ISV or merchant. An example of this would be a software putting their own flavor of functionality onto the device. Ziosk, as an example, positions itself as an all-in-one device. When you get a Ziosk device it works with Ziosk software and that’s the end of it. Unattended devices are also good candidates for ISV-led device management.
The second party that can run software on the device is the device OEM themselves. This would be like Dejavoo’s SPIN or Verifone’s XPI: the device manufacturer has built their own software to run on their own hardware.
Last is the gateway. A good example is Adyen, who fully verticalizes the payment experience by controlling the entire process end-to-end, and consequently has tight control on devices.
These are not mutually exclusive, however, and there are gateways that will allow for all three models, but it comes down to strategy.
For instance, there are gateways that don’t bother with Level 3 certification because they want to punt that responsibility to the integrator. The value in undergoing the Level 3 certification as a gateway is that you can now extend your coverage to anyone that integrates with your devices, but clearly there’s a cost to do so. If a gateway were to have completed a Level 3 Certification, an ISV could then integrate to a gateway in 4-6 weeks and receive a compliant integration.
The Level 3 Certification runs somewhere in the range of $25K – $50K in hard costs from the processing host, but, just like writing to the card schemes, there’s a whole lot of hurry-up-and-wait happening. That means the integrator has development overhead that’s just sitting idle until someone at the processor decides that they care to show up for work that week.
Ah, big co.
Before we discuss PCI requirements, let’s touch on the difference between fully integrated and semi-integrated gateways.
Instead of reinventing the wheel we’re going to refer to this explanation:
The fundamental difference between integrated payment architecture and semi-integrated architecture is that in semi-integrated solutions, the payment terminal communicates sensitive transaction information directly to the payment gateway or payment processor, keeping that data separate from the merchant’s and ISV’s systems. This is critical for developers because it shifts most of the burden of PCI compliance away from the business’s application and onto the payment gateway or payment processor. The payment service provider’s EMV-certified and PCI-compliant software runs on the physical payment terminal, but only transmits non-sensitive data to the business’s application. The sensitive transaction data is sent directly from the payment provider’s terminal application to the payment gateway or processor, and the only data that’s returned to the POS application is a PCI-compliant response with non-sensitive data.
An integrated payments system has the same components as a semi-integrated solution, but — as the name implies — the components are integrated together. Specifically, the application that manages the transaction and interacts with the sensitive payment data is integrated into the POS system. This fully integrated payments software processes the payment and is often combined with other business functions including accounting, inventory, and CRM systems. In this architectural model, raw card data must travel securely through the POS, to the payment processor, and on to the bank for payment authorization. Because of this key difference, the Point of Sale application is responsible for complying with Payment Card Industry Data Security Standards (PCI-DSS).
What matters here is that while both integrated and semi-integrated require Level 3 certification, the former is actually easier to manage as a gateway since you can control the entire process and are not reliant on a third party partner (the POS, for example) to cooperate to achieve compliance.
By the way, ISVs often prefer this approach because it prevents them from having to undertake additional effort as well.
Now we get to PCI…
20 years ago the five major card brands (Visa, AMEX, Mastercard, Discover, JCB) all had their own versions of privacy certifications. Over time they realized that this was quite duplicative, so they decided to coalesce security standard development through the Payment Card Industry (PCI).
The role of overseeing these standards was now the responsibility of the PCI council, which in theory is an “independent council”, but you can read some of the inside baseball if you care to see just how “independent” anything in payments is when you have oligopolies in control.
Be that as it may, the Payment Card Industry Data Security Standard (PCI DSS) applies to all entities involved in payment card processing, including merchants, service providers that touch cardholder data (e.g. processors, gateways, et al.), and obviously the financial institutions that issue cards.
The specific requirements and compliance levels vary depending on the entity’s role and how they handle cardholder data. For instance, a Level 1 merchant processing millions of transactions will have more stringent requirements than a small online retailer.
There are different types of PCI certifications. Here are the four main levels for merchants as shared by the folks at Compliance Point:
Level 1: Merchants processing over 6 million card transactions annually. Requires an on-site audit by a Qualified Security Assessor (QSA), a quarterly network scan by an Approved Scanning Vendor (ASV), and a Report on Compliance (ROC).
The Report on Compliance (ROC) is a detailed report prepared by the QSA after conducting the on-site assessment. It documents the merchant’s compliance status, any identified vulnerabilities, and recommended remediation actions.
Level 2: Merchants processing 1 to 6 million card transactions annually. Requires an annual Self-Assessment Questionnaire (SAQ) and a quarterly network scan by an ASV.
Level 3: Merchants processing 20,000 to 1 million e-commerce transactions annually. Requires an annual Self-Assessment Questionnaire (SAQ) and a quarterly network scan by an ASV.
Level 4: Merchants processing fewer than 20,000 e-commerce transactions annually or up to 1 million total transactions annually. Requires an annual Self-Assessment Questionnaire (SAQ) and a quarterly network scan by an ASV.
The Self-Assessment Questionnaire (SAQ) is a series of questions that merchants complete themselves to assess their compliance with PCI DSS requirements. There are different SAQ types depending on how the merchant processes cardholder data.
And by the way, the acquirers have all figured out how to turn these merchant “compliance requirements” into a profit stream vis a vis fake fees.
Gateways and third-party service providers (TPSPs) are still required to go down the route of PCI DSS compliance. However, they are usually reporting to customers instead of an acquiring bank. They would usually go down the route of compliance for marketing purposes or to show that their platform has been evaluated against the PCI DSS controls.
For both gateways and TPSPs, a Matrix of Responsibility would accompany the Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ) outlining which requirements are the responsibility of the Gateway/Service Provider vs. the Customer/User vs. a Shared responsibility. This helps clarify to the customers who are using the gateway/platform or using the service provided by the TPSP which controls or requirements that can rely on from the TPSP as opposed to the requirements that they need to handle themselves.
The assessment process would be exactly the same for both a gateway or TPSP compared to that for a merchant; the only difference being that if a TPSP decided to do an SAQ instead of a ROC (they can do either), they would have to complete the SAQ-D form for Service Providers as it is the only version allowed by the PCI Council for TPSPs.
If a ROC is desired, then the process for validation of a gateway or TPSP must go through a Qualified Security Assessor (QSA), such as CompliancePoint, just like a merchant would have to do.
There are new, parallel flavors of PCI DSS compliance as explained by Steve Levinson and Adam Krieger of Online Business Systems.
The first is certification against the Software Security Framework (PCI SSF). This is in some respects the replacement for the older PA-DSS certification, and the real benefit here is that you get listed on PCI’s website as SSF-certified. So instead of needing to furnish proof of compliance, you can point potential partners to the public URL to assuage any concerns.
The second certification is virtually the same, only you don’t get publicly listed, and that’s through the conventional QSA route. As Steve and Adam explained, the process is as such:
- Though not technically required, it’s highly recommended that a gap assessment be generated by a separate consultant
- The company remediates what’s needed
- The QSA validates remediations
- The QSA completes the assessment and delivers the Report on Compliance (ROC)
Throughout the process, a QSA:
- Examines documentation
- Interviews people pursuant to the documentation
- Makes observations
Technically there’s a bit more scrutiny when taking the SSF approach, since any QSA can issue a ROC, although the assessor needs to be certified to their specific standard (e.g. QSA, SSF, P2PE). To become a QSA an entity would pay fees to PCI based upon the region in which they care to practice. The QSA also achieves one of a few possible certifications (e.g. CISSP or ISO 27X) and gets requalified annually, although a SSF Assessor needs at least three certifications (e.e. CISSP, CIS, CSSLP).
On average either certification takes 200-300 hours and costs run $50K – $70K. Keep in mind that this is a recurring annual cost
In summary, the time and cost it takes to build a gateway is mostly a function of the Level 3 certifications and PCI certifications. While they can be done in parallel, you’re looking at 2-3 months per certification and a cost of $50K each.
To be commercially successful with a gateway is a much larger discussion, since it depends mostly on both device strategy and then go to market plans: how do you get adoption?
Add comment