Ideally, organizations looking for a Payment Gateway Integration for SaaS start considering their options far in advance of the new application going live. Or in the case of an existing application, far in advance of the need to flip the switch on for the payment processing functionality that the new payment gateway integration will be supporting.
Applications differ in how they approach a gateway integration in terms of the business model. In some instances the organization will be looking for a partnership model where a revenue stream can be derived from a vertical base of client users. On the other hand, some organizations prefer to remain agnostic and provide multiple gateway options. This areas should be explored in advance of the integration so that everyone is on the same page with the integrating organizations' goals and how it correctly supports their business model.
Something that's rarely brought up by organizations that are looking to integrate is the issue of data migration. As an example, a start-up SaaS might not have all that much experience with payments in general, thinking only about the usefulness of the API functionality and how easy it is to use; they are simply looking to get the payments functionality up and running. It's wise to think about what happens down the road should their gateway relationship become a failure for whatever reason. That's where data migration can become an issue.
Payment Gateways differ in their data migration policies. There are some that even hold the data hostage, in effect. Some will have a minimum number of consumer accounts from the integrated partner in order to be eligible for data migration, and there are some that charge an exorbitant fee for migration; tens of thousands of dollars in a few cases. While data migration is a real expense to your gateway partner because of the security measures in the transfer that take place, holding data hostage is simply a mechanism to keep existing business. Know in advance what data migration policies are.
Decide what you payment rails that will be needed are. Applications that serve a single sale model can get by just fine with only a gateway integration that supports credit card transactions. However, if your application has a subscription component with recurring payments, you should strongly consider the ACH rail. Having a single integration source that covers both the credit card and ACH rails is generally advantageous not only to the integrating organization, but to the vertical client user base.
We listen to new gateway integration prospects every day, and there's always something new for requirements. There's rarely a cookie cutter model when listening to the prospect. Compose a list of your technical and business model requirements and have those ready when discussing options with a gateway integration parter prospect.