The SaaS model is a common and growing go to market monetization model for software vendors. Customers appreciate the pay-as-you-go cash outlay and it allows vendors continuity of revenue for continual upgrades needed to satisfy clients. Many vendors will start with a freemium offering where the basic service is free but a premium is charged for additional services. The vendors will also attempt to monetize their offering through other revenue sources such as credit card processing.
In order to accomplish this, the software vendor needs to integrate with a credit card processor. There are several ways a vendor may integrate and depending on how the vendor chooses to integrate will dictate what credit card processing options a merchant may have.
Application verticals
Typically, software packages are decked out against a vertical. Examples include:
- Accounting package for small businesses,
- Restaurant Point of Sale,
- Billing solution for insurance companies,
- Dentistry package,
- Storage facility tracking or
- Medical records solution
Each of these providers have a unique specialty. They are experts in the nuances of the verticals they support but they need not be an expert in other aspects such as the hardware needed for their clients or payment processing solution. As a consequence, they may resell another manufacturer’s hardware and integrate with a payment processor.
When integrating the payment processing, they must do so in a way that allows for them to leverage their own expertise while not interfering with the credit card transaction or transactional information. Credit card data, for example, is highly confidential and highly sought after by fraudsters. When transmitting the data to the processor, it must be encrypted. Certain fields must never be stored. Other fields must be stored but in an encrypted manner and any system touching card data must be hardened and monitored.
Before sending data to an authorization provider, the sender must certify to the processor’s specification and re-certify on a regular basis or when new features are added. Because of this complexity, software vendors will integrate to a credit card provider’s SDK in a way that allows the flow of non-sensitive transactional data, such as the amount, purchase information and card type, but tokenize cardholder information. The result is the software vendor is made aware of any transaction or inquiry but remains outside of scope for a Payment Card Industry (PCI) Data Security Standards (DSS) review.
Payment provider or gateway provider
As shared above, in order to send an authorization request to a processor, the entity must first be certified. They must code to and receive certification from the processor and must undergo regular recertifications. If they wish to send authorizations to multiple acquiring banks they must integrate to multiple authorization providers.
Here again, to minimize complexity, software vendors will avoid directly certifying to authorization providers and instead certify to a payment gateway. A payment gateway will have completed both the PCI certification and integration work with a processor and will sit between the merchant and the authorization provider, as depicted in Exhibit 1 below.
The payment gateway will extricate the heavy lifting involved in certifying to a processor and maintaining PCI compliance. All the software vendor need do is certify to the payment gateways’ SDK. The SDK will then provide the software vendor the needed data points for maintaining the merchant’s records and transactional data.
Payment gateways are not completely interoperable
Because most payment gateways like Authorize.net, Ingenico One, FreedomPay and NMI are connected to many processors, merchants may think that just because their software vendor integrates with one of the above gateways, they can then process with any and all processors to which the gateway has certified.
The issue is that a software vendor may need a particular hardware for their card present solution or a specific configuration which is unique to a particular processor. Many software vendors will allow merchants to use multiple payment providers but have unique optional features only available with select providers. For example, because the hardware may only be certified with one processor, they may be only able to process card present transactions on a specific processor. This then limits the options and ultimately the service (or lack thereof) or pricing afforded a merchant.
Merchants can and should understand the limitations and options available to them. They should understand the gateway their vendor has certified to and is powering their payments solution. They should recognize upfront if there are limitations associated with the gateway the vendor has integrated and further if there are different options available amongst the payment processors supported. They should ask for and always know the roadmap of their vendor so if changes are in the making, they know that with time to act.
