Close this search box.
Close this search box.
Close this search box.
Close this search box.

Agile Payments Blog


Top 5 must haves before integrating with any Payment Gateway. The #1 MUST HAVE is probably the least thought about decision making criteria yet arguably the most important.top5 payment gateway must haves pdfYou MUST make sure your payment gateway partner values your customers as much as you do. You know how much time and effort is spent on customer acquisition. In today’s world competition for clients is fierce. You can’t afford to spend time and money to bring on a new client only to have them disappointed with poor communication or a complete lack of support. Having confidence that your most valuable asset is being well taken care of simply cannot be overstated.

This may come as a surprise to many. After all having a great API that you can deploy quickly tends to be at the top of the list for many developers. This can be short sighted so before you make the decision to hand over your client base you owe it your business and your customers to ensure that the payment gateway partner has an acute understanding of lifetime customer value.

  • What is the support plan?
  • How do they you do it?
  • Ask questions about front line support [time to respond/support hours]. Is this outsourced or handled internally? If support needs to be escalated what is process and time frame.
  • Who handles billing issues, bank account changes, business formation changes?
  • If your payment gateway provider also provides the merchant accounts you can also add questions about the application and underwriting process. What is the application turn around, what are the merchant obligations?
  • Can credentials be pushed automatically into your app so that the end user has little to do?
  • Do they communicate with your users about enhancements, service issues, recollection options, payment recycling strategies etc or are those customers an afterthought?

2 – Multiple payment modalities

Recurring or subscription billing should have the ability to process credit, debit cards and ACH transactions. Credit cards are the de facto billing method for many providers and offer the security of knowing at the time of sale that the customer payment is good. This comes at a price [likely 2.5% or more]. For most merchants the ACH option is an excellent alternative. Though there is no authorization component whereby purchase amount is validated for payment the additional risk of failed payment [eg a non sufficient funds or closed bank account] is mitigated by the available 90+% reduction in transaction processing fees. If the merchant perceives higher risk there are checking account verification services that can be deployed as well as automated payment resubmission. The ACH system is available in the US and some providers [limited] also offer Canada. A single platform for billing US and Canadian bank accounts and credit cards is a competitive differentiator. There is another “dirty secret” about credit card processing. Recurring payments often have decline rates that exceed 10% [due to invalid expiration dates and card reissuance- think Target breach].

3- Integration options and developer support

A Single-Stack Solution should be available – Developers shouldn’t have to use different processors, versions or stacks when integrating across those various channels. Single-stack APIs create opportunities for payment integration that in turn reduces integration time.

Multiple Development Languages – Flexibility is an advantage developers have come to expect. Legacy APIs have limited developers’ options when it comes to the use of languages. For developers, the best case scenario is a payments API that allows for all contemporary development languages, including JSON, Ruby, Python, .NET, JAVA and PHP.

Development Support – Development support seems like an obvious feature for payments APIs. But many APIs lack the resources it takes to develop and maintain payments technology. To minimize risk down the road, API support should offer developer-friendly documentation, sample code and other features that improve the development process. Test accounts should be made available same day with dev support being an email or call away.

4 – PCI Compliance Offloading

PCI compliance is often confusing and intimidating. For developers and SAAS providers the decision to embed payment processing into an application often leads to questions about obligations and repercussions regarding PCI.

Achieving Level 1 compliance is an expensive and time consuming task that also comes with frequent audits. For some companies it may be an option that best fits their business model. For most SAAS providers a much simpler and less expensive option is to partner with a payment gateway provider that can help remove the PCI burdens.

The key is to work with your payment gateway provider and create a solution that takes the application out of PCI scope. Essentially that means that the SAAS provider never touches nor stores the sensitive payment data. Typically this is accomplished via vaulting or tokenization. In the tokenization scenario the full card # is exchanged with a proxy token and when that customer needs to be billed again the token is sent in place of the credit card [or ACH data. This is often accomplished using a secure pop up “lightbox” where complete card data is entered. From there the gateway partner communicates the token back for storage and future use.

PCI compliance is a requirement in credit card processing. ACH processing currently does not have the same mandate. However it is likely there will be a corresponding data protection rules and regulations forthcoming. If your application will have an ACH component [all recurring apps should] you want a payment gateway provider that already employs tokenization for ACH transactions.

5 – Revenue Share Model

It does not seem to make much sense to leave money on the table yet many gateway partners do not offer a true revenue share model. The prevailing attitude of many developers and SAAS providers is: We do the integration and our clients choose their provider [if gateway options are offered]. There are multiple reasons why this may not be in your best interest [see reason #1 for a big one]. If you have done the hard work [and expensive] of acquiring a new client you are obligated to derive as much revenue as possible. The payment gateway partner is being provided a new client with NO acquiring cost. It seems reasonable that a revenue stream agreement should be in place for the lifetime of referred clients. Some providers take the attitude that this is somehow endorsing a gateway provider. If you believe your end users will benefit from your gateways partner’s tools for reliably getting paid and you have faith that your clients are well taken care why would you not endorse them?

Consider the SAAS provider collecting $29/month for their app. If each of those clients generated just $10/month in payment related revenue sharing you could have a 33% bump in income. In addition having a revenue share partnership tends to also produce better and more frequent communication between the SAAS provider, the payment gateway provider and the SAAS user base. Often this synergy drives enhancements that benefit all stakeholders.

Payment Gateway strategy can have long and far reaching effects on almost every part of your business. By using the suggestions above you can save time and money as well as generating new revenue streams for your business. Most importantly you deliver more value for your end users.