As I have referenced in prior articles, software vendors may initially offer their services in a payment agnostic manner. As they mature and build, they realize the financial benefits of integrating as well as product enhancements of integrating. Others may determine from their inception for their product to flourish, it must be integrated with payments. Once an Integrated Software Vendor (ISV) decides they will integrate with payments, however, they then need to navigate the course in which they will do so. Adept Product Managers would be wise to consider their options prior to committing their resources.
Integration options for payments
The three primary options for an ISV to integrate payments include:
- Integrating to a PayFac
- Integrating to one or more gateways
- Integrating to one or more processors
Properly considering these options before pursuing a course will prove beneficial for development costs, customer features and the overall processing cost as well as ensuring the greatest percentage of clients are converted to the integrated solution.
While the integration options are neither mutually exclusive nor irreversible, practically speaking, once an ISV has completed their integration and is supporting customers, even if their choice is sub-optimal, the etched path is difficult to deviate. The ISV must either commit scarce resources to another integration (and customer conversion) for an incremental benefit OR pursue the Product Manager’s Vision of revolutionizing the lives of their customers. Obviously, the Product Manager’s Vision will be more compelling and command the lion’s share of engineering bandwidth. It is simply a more exciting and more internally saleable argument than integrating to a second provider.
An ISV should carefully consider the pro’s and con’s of each option. Any consideration should start with security and I would argue against an ISV bringing their solution within PCI scope (unless it is core to their offering….and even then, there should be a discussion). Within the three options there is a continuum of integration complexity which is typically, but not necessarily, aligned with an ISV’s control and flexibility. To be clear, however, this decision will directly impact time to market, user experience and cost as depicted below:
Factors to consider
An ISV should consider a broad array of use cases and marketing before embarking on their solution. A solution with pre-built UI components can save development costs. For example, a solution with an iframe for sensitive customer information which must be passed along to the processor is easy to integrate and maintain; especially as bank and regulatory changes dictate. Further, support options and tools should be considered in light of an ISV’s own talent and resources. Does the solution have the tools necessary to support an ISV’s agents, can they accommodate after hours support or overflow support when needed and to allow for rapid scaling. Other factors to consider include, but are not limited to:
- Currencies and Geographies supported
- Processors supported along with their pricing and underwriting flexibility
- Methods of payment including crypto currencies and non-card options
- Optional tools such as fraud mitigation and sales tax support
- Vertical(s) supported
- eCommerce, in-person, mobile, or omni-commerce, recurring and corporate payments
- Gift/loyalty programs
- Ancillary offerings
- Authorization latency and transaction limits
- Hardware supported
- Portability or ease customers may be migrated
- Co-locations and back-up
- Data formats and availability
The PayFac integration
Integrating to a Payment Facilitator or PayFac will be far and away the easiest and quickest to market. PayFacs were bred to disintermediate the complexities from a traditional payment processor. Companies like Square, Stripe and PayPal have developed a business model around making their application easy to integrate. The process can be as basic as downloading a library and copying a few lines of code. A single engineer could have an ISV payment enabled in a day. The flip side is that once accomplished an ISV has, to a large extent, outsourced their payments pricing, customer service, data, dispute resolution and hardware options. You may not ultimately appreciate Square’s pricing model or your revenue share with Stripe, but such is the sacrifice for rapid integration. At the time, this trade-off may seem well worth it but as an ISV’s portfolio grows, even a few basis points of margin translates to a fortune when examining the multiples of a publicly traded stock. Further, an ISV may find itself without the means to differentiate from competitors within the same space.
The gateway integration
Along the spectrum, the next degree of difficulty is integrating with a payment gateway. Payment gateways are typically connected to multiple processors so a single integration can provide an ISV multiple processors which translates into greater underwriting flexibility and lower pricing while still extrapolating the heavy lifting of PCI and processor certification.
Within a gateway integration an ISV must further choose between a simple hosted payments page which is similar to the complexities of a PayFac integration or fully integrating so the customer experience is seamless and more professional. Before selecting a gateway, an ISV should examine the API for ease of integration. Ideally the SDK will provide code samples which can be used as the foundation for the integration and a checklist for certainty and specificity. The SDK should be heavily commented allowing for ease in gaining robust domain knowledge. Unlike with a PayFac, gateway costs are all a la carte. An ISV must consider the gateway costs in addition to the payment processor’s costs.
The full monty
A full processor integration is along the spectrum of integrations but it is as far apart on the spectrum from a gateway integration as is Lisa and Homer Simpson’s IQ. For that reason I will only briefly touch on my thoughts regarding such work. Not only will the ISV need to undertake an annual PCI audit, but they must also integrate and be certified to a selected processor. Processor certifications could take over a year and although provide for the greatest flexibility of service offering and the lowest pricing; it comes at cost. The development will be slow. The processor documentation and supported languages will likely be antiquated as many processors have been around for decades operating on main frames.
There may well be a certification by vertical and in addition to the processor’s own certification; the Card Networks too will have to sign off. Direct processor certification should be reserved for the largest ISV’s and likely as an iteration or the final version where the ISV becomes a registered PayFac. In that context, full processor integration makes sense.
Conclusion
There is no perfect solution and the ideal solution depends upon the ISV. Product Managers should well consider the ramifications of their path before embarking however in order to make the most efficient use of their resources and in order to convert the greatest percentage of their customers.
