Sphere recently sat down with its own Andrew Immerman, Senior Vice President of Technology to answer questions asked regularly by software vendors when choosing a payments platform with which to integrate. Mr. Immerman leverages over 20 years of experience in the development, deployment, coordination and operation of quality-driven, mission-critical technologies.
Sphere: Why use a gateway when you can connect directly to an acquirer/processor?
Immerman: Premium gateways are optimized to dramatically reduce the costs and risks of electronic payment acceptance. In general, processors are optimized to extend as much functionality as possible to the widest possible user base. To facilitate these objectives, premium gateways offer user-friendly human interfaces and easy to integrate application programming interfaces (APIs). Processors, on the other hand, extend complex, yet highly functional, user interfaces and APIs. As a result, processor interfaces are generally far more costly and time consuming to implement.
Premium gateways offer a wide variety of value adds and flexibility processors generally cannot. For example, gateways can offer fraud prevention and analysis solutions generally beyond those of the processors themselves. Additionally, gateways can offer management and automation for scheduled payments, such as those of a recurring, installment, or deferred nature. As from such functional value adds, gateways almost always natively support seamless transitions from one processor and acquirer to another.
In general, only merchants processing an extreme and sustained volume of transactions, such as 100+ transactions per second (TPS), are advised to directly integrate with a processor. Such merchants essentially build and use their own gateways, though often without the benefit of proven and ever-maturing technologies.
Sphere: Should gateway uptime/availability be a concern when selecting a gateway, or has cloud computing made this a non-issue?
Immerman: Dependability, performance, security, and many other quality attributes should be considered whenever evaluating any technology for use. As part of any dependability evaluation, availability, reliability, resiliency, and controlability should all be considered. Availability describes a system’s functional readiness; reliability describes a system’s functional correctness and consistency; resiliency describes a system’s ability to endure exceptions; and, controlability describes the efficacy and efficiency of system controls for management, maintenance, and administration. These quality attributes are implemented using careful and proven design, development, and deployment lifecycles.
“Cloud”-based technologies generally enjoy greater dependability and performance through service-driven relationships that abstract single points of failure. The configuration of cloud-based technologies and, more so, the services, applications, and other software that run thereon, dictate the potential and realized dependability and performance of such technologies. Put another way, cloud-based technologies reduce some risks; however, poor designs, such as those having single points of failure, are often just as failure-prone as are non-cloud-based technologies. As an analogous example, consider that multi-engine aircraft are often considered safer than singles. In actuality, multi-engine aircraft are generally more challenging to operate and are still susceptible to fuel depletion and contamination, both essentially being single points of failure.
When considering the introduction of any new technology, such as those of a payment gateway, it is generally advisable to obtain historical dependability, performance, and security data, as well as to understand and assess its continuity, resiliency, and resumption considerations.
Sphere: Does using a gateway add time to a transaction, especially if it’s EMV? Can bandwidth/capacity affect transaction times, especially during peak periods?
Immerman: Whereas all payment processing steps do increase round-trip transaction times, premium gateways do so with increases of no more than 10 to 50 milliseconds, including EMV overhead. In many cases, a premium gateway may be able to offer reductions in transaction times through highly tuned, high-throughput integrations with upstream entities. As an example, Sphere round-trip transaction times include overheads generally well under 50 milliseconds and, in total, average less than one second, including all round-trip times with the processor, associations, and issues.
Sphere: Every gateway is PCI validated, what makes Sphere more secure?
Immerman: Payment gateways, like all entities that handle sensitive cardholder information, are expected to maintain ongoing compliance with the PCI Data Security Standard (DSS). That said, not all do. In some cases, organizations predominantly focus on annual PCI DSS revalidation efforts, as opposed to ongoing compliance. Often, the terms “secure,” “compliant,” “validated,” and “certified” are used interchangeably when, in fact, each is distinctly different from one another. For example, being secure and/or being compliant are ongoing states, while being validated and/or being certified are based on assessments of security and compliance at specific points in time. Moreover, most security and/or compliance assessments are sample based, as opposed to being comprehensive. Additionally, no single security standard is truly comprehensive or all encompassing. All this is to say that being PCI “validated” may only be a superficial indication of an organization’s security and/or compliance maturity.
In numerous ways, Sphere distinguishes itself in the community of payment gateways and other service providers. As just a few examples of Sphere’s commitment to exceptional security and compliance:
- Sphere maintains several independent compliance and security organizations that operate in tandem with one another, as well as with mutual accountability;
- Sphere prioritizes and invests in security and compliance as separate activities to ensure that both are achieved;
- Sphere leverages several security frameworks to ensure better coverage (e.g., Sphere maintains compliance with the PCI DSS, as well as the PCI Point-to-Point-Encryption (P2PE) Standard and the HITRUST Common Security Framework (CSF);
- Sphere establishes compliance and security requirements that, in many cases, exceed those of the PCI DSS, PCI P2PE, and/or HITRUST CSF;
- Sphere invests separately in the architecture, the implementation, the administration, and the assessment of security and other sensitive solutions;
- Sphere implements security considerations through the lifecycle of all plans, processes, products, and technologies;
- Sphere offers and encourages ongoing training for all employees; and,
- Sphere maintains a culture where security, privacy, compliance, and risk mitigation in general are championed.
Sphere: What can go wrong with payments and what risk does that introduce to me and my customers?
Immerman: Payment processing involves numerous entities and many complex workflows. Any degradation with any interconnectivity, any degradation with any processing entity, and/or any workflow exception can lead to connectivity failures, processing failures, duplicated or otherwise erroneous financial authorizations, incorrect settlement or funding, etc., not to mention numerous risks relating to security, privacy, and compliance.
Premium payment gateways implement numerous checks, balances, and other controls to minimize the vulnerabilities and risks of processing exceptions. Such controls may include redundant connectivities, client- and server-side availability switching (fail-over and load-balancing), verification cross-checks, integrated and continuous system health and integrity monitoring, and autonomous exception containment, mitigation, recovery, and reporting.
Sphere: Is integrating to Sphere more complicated than using other gateways?
Immerman: Sphere technologies were designed to be inherently easy to integrate. As an example, the TC Link API, a highly dependable and highly flexible application programming interface (API), can easily be integrated with less than a dozen lines of programming code. Additionally, Sphere products are designed and assured to be compatible with all major operating systems and operating environments. For more information, please refer to the TC Link API Developer Guide, which details and demonstrates its integrational simplicity, as well as its vast functionality.
The Sphere Technology team and I are very proud of the products and services we offer. We look forward to addressing any questions or comments our partners may have, and to assist with all integration efforts.
To learn more about the developer resources that Andrew mentioned, visit our integration page or contact us below:
By Dr. Heather Mark, CCEP
The complex puzzle of PCI DSS compliance can be made more challenging for merchants when they introduce the wide variety of service providers that they use in order to service their customers. Increasingly, Independent Software Vendors (ISVs) are working to simplifying their merchants’ burdens by introducing integrated payment functionality. In essence, the ISV is presenting a one-stop opportunity for merchants to support their business management objectives – be it through back office support, inventory management or billing – while also enabling payment functionality. In doing so, the ISV may inadvertently become the de facto resource for merchants on all things PCI DSS related. So, what are some things that ISVs can do to help support their merchants in achieving and maintaining PCI DSS compliance.
#1 – Understand your own PCI DSS compliance obligations and status
It isn’t uncommon for an ISV to be new to the payments ecosystem. Even for those companies that are deeply ingrained in the payments chain, the compliance and security obligations facing payments companies can sometimes get confusing. As an ISV, it is important to understand whether your integration of payment functionality renders you a Payment Service Provider, as defined by the PCI SSC. A Payment Service Provider is an entity that stores, processes, or transmits cardholder data on behalf of another entity, or can impact the security of the transaction. If the ISV integrates payments in such a way as to fall into that scope, then the ISV must validate compliance with the PCI DSS. Merchants must use PCI DSS compliant service providers, so it’s important that ISVs are prepared to provide their Attestation of Compliance (AOC) to their merchants.
If the ISV is able to offer payments functionality without falling into the Payment Service Provider scope, then the entity must be able to clearly articulate how they are able to maintain that status. For example, if the ISV has partnered with another PCI-compliant service provider to offer a hosted payment page, and the ISV does not host, nor does it redirect to that page, then it may be possible to remain out of scope. This is dependent on the ISV integration and the current guidance from the PCI SSC and the card brands.
#2 – Implement Industry Best Practice Even if You’re Not in Scope
Even if an ISV is able to maintain a posture that keeps it out of scope for PCI DSS, it is important to maintain industry best practice for data security and privacy. Having good security practice is not just necessary for those companies that are obligated to PCI DSS. Most states have data breach notification laws that offer safe harbor for encryption of sensitive data, as long as the encryption keys are not also exposed. Additionally, states are rapidly moving towards the adoption of privacy laws, most of which have data protection requirements. Maintain compliance with industry standards such as PCI DSS, even in the absence of card scheme requirements, can put an ISV, and by extension their clients, in good stead with respect to existing and forthcoming regulatory requirements.
#3 – Explain the Payment Integration Options that You Offer and their PCI Implications for Your Merchants
For ISVs that are looking to add payments functionality, it’s important to understand how that choices you make about the payment solutions you integrate cascade down to merchants. For instance, if an ISV integrates a hosted payment page the likelihood that the merchant will be able validate their own compliance using the SAQ-A is fairly high. However, if an ISV integrates and offers a redirected page, the merchant is more likely to be required to validate using an SAQ A-EP, which is a much longer questionnaire. Both may be valid choices for a variety of reasons, but ISVs should understand the implications on their merchants
#4 – Clearly Communicate Who Owns What Responsibilities
The interplay between merchants and service providers can be complex, particularly if merchants are able to select services and features a la carte. This can lead to uncertainty as to which entity might own responsibility for various security controls. ISVs can demonstrate partnership with their merchants by providing a “shared responsibility” matrix. The matrix doesn’t need to be very complicated, but it should clearly delineate which PCI responsibilities belong the ISV and which belong to the client. Since all merchants must comply, and any business with a Merchant Identifier (MID) must validation compliance, this documentation can significantly simplify their own process of PCI compliance management.
PCI DSS compliance is a fact of life for any participant in the payment system. Understanding how your decisions as an ISV can impact the compliance standing of your client portfolio can help you make more informed decisions about the solutions that you implement and may simplify the compliance and validation process for your merchants.
We recently sat down with Curtis Bauer, Sphere Chief Product Officer, to learn about an innovative new product, Hosted Multi-Channel Payment Suite. This solution gives software vendors the power of accepting payments via many channels through one single integration.
Q1: You recently launched a hosted payments product suite for software vendors, what sparked the solution?
Bauer: That’s actually an interesting story. The Sphere Product team is constantly thinking about ways in which we can solve ISV needs in the most impactful, secure, but lightest way possible. One of our most successful ISV solutions is our Premier hosted payment page, which enables ISVs to accept card not present transactions within their SaaS based solution, e-commerce site, mobile, text or even email. In fact, calling it a hosted payment page is probably a bit of an understatement as it somewhat minimizes its robust capabilities. ISVs love the product due to its simple integration, branding and style continuity, as well as PCI scope reduction.
The Product team thought about ways we might be able to leverage all of the benefits that are inherent with our Premier hosted payment page, but allow us to expand it into other user scenarios, including the ability to accept EMV card present transactions. The team came up with an idea to leverage a fairly underutilized technological approach, which the team theorized might allow us to connect a traditional EMV card reader to a PC and process EMV transactions through a browser, without the need to install software on the desktop or leverage any antiquated java scripting to communicate with the EMV device. To test the theory, the Product team worked with our Development team and to make a long story short, the approach was proven to be viable and it ended up being the foundation for expanding our hosted payment page into an entire multi-channel hosted payment product suite.
Q2: What are the main problems this solution solves?
Bauer: ISVs have four critical challenges as it relates to adding payment acceptance to their core product solution:
- How do they enable payments to their solution with the least amount of development effort
- How do they enable payments in a way that does not interrupt the user experience, keeping the same look, feel and flow
- How do they enable payments across multiple acceptance use cases
- Possibly the most important challenge, how do they ensure cardholder data does not reside within the ISV’s platform, minimizing their PCI footprint, while protecting their customers from cardholder data breaches
Our new hosted payment product suite solves for these critical challenges and much more. ISVs face so many challenges with bringing their products to market. As a payment processor and gateway platform, we have a responsibility to ensure payment acceptance doesn’t become one of those challenges, but more importantly, ensure payment acceptance enhances their core product offering to improve the overall value proposition to their customers.
Q3: How can this product suite fit into software vendors business models? Can you share an example?
Bauer: One of my favorite examples is an ISV that creates business management software for a bakery. Let’s say that the bakery sells their products from a retail location. They need the ability to accept card-present EMV transactions from their in-store customers through the ISV’s SaaS-based business management solution. The bakery also has a website where they accept orders for birthday cakes or other items, in which they need the ability to accept credit card transactions online. The bakery also has a cookie of the month club, where subscribers pay a monthly fee to enroll into receiving a dozen of their specialized cookies each month at a discounted price. The bakery needs the ability to accept a credit card, either in person or online, and then setup the card for a monthly recurring subscription billing. Finally, the bakery also takes orders over the phone for delivery. They need the ability to accept credit card information over the phone and process the transaction securely. Our hosted payment product suite not only provides the ability for an ISV to enable accepting payments via all of these scenarios, but it also allows them to do so while ensuring sensitive cardholder data is never stored within their platform, but is instead transmitted, processed and stored within the Sphere secure gateway. In addition, this only requires one simple integration, which allows the ISV to spend more time focusing on enhancing their core product instead of allocating precious development resources to managing their payment acceptance program.
If you would like to learn more about the Hosted Multi-Channel Payment Suite, read the fact sheet. To schedule a demo, click here.
Curtis Bauer, Chief Product Officer, brings more than two decades of payment industry experience with a core focus on Product, Technology and Corporate strategy. He has held Senior Leadership roles at TSYS, TransFirst and Vantiv. He is responsible for identifying and executing on our product strategy to help deliver growth by providing innovative solutions to our customers.