1. Choice of partner

Your choice of vendor has a considerable impact when it comes to face-to-face payments timelines.  Some companies are experienced with and committed to enabling integrated payments for SaaS.  Some specialize in serving other (really important) parts of the market, like standalone terminals or enterprise merchants.  We even see some "Trojan Horse" providers who have their own POS systems, but let some select partners piggyback on their payments rails (think Square, Clover, etc.) so they can get more payments volume.  Some of these are great companies, but choose carefully.

These other parts of the payments market have distinct needs from most SaaS platforms.  Why?

Let's consider the three other parts of the market and what they are solving for.

You might think that you should choose the provider who is optimized for Enterprise.  They will have amazing logos as customers, and why not trust the one trusted by the best?

When it comes to integrated payments, solutions designed for enterprise merchants may be optimized to have raw payments data routing through your platform, let you link your payments stream with your on-prem servers, give you integrations with Oracle, or even enable you to do your own custom terminal certifications.  A multi-year integration path with custom capabilities may be the expectation.  If you are Walmart or an airline, this might be exactly what you need.  

Not always, but this can be a common offering of a traditional acquirer, supported by some kind of third-party systems integrator and a dedicated department (or two) inside of your business.  This generally can be referred to as fully integrated to the acquirer. Integration time is measured in "months," but really can take years and considerable commitments, as well as hard project costs.

Most of the SaaS companies we know are disappointed with this kind of offering.  Almost all prefer a method of "semi-integration." But not all semi-integration is created equal.

On the other end of the spectrum from enterprise providers are API-only solutions built around terminals optimized for standalone scenarios. Standalone-optimized terminals are enabled for payments via integrations done by terminal hardware vendors themselves directly into acquiring platforms. Think Verifone certifying a terminal directly to Fiserv via Rapid Connect/Nashville-North.  

Sometimes you can find a third-party API provider (like eConduit) that lets your SaaS software send commands to these standalone-optimized terminals.  It is one form of "semi-integration" in contrast to the full integration described as appropriate for enterprise. 

Here's the catch with these third-party API-only solutions.  These terminal solutions are often optimized for ISOs (payment contract resellers) who sell standalone terminals direct to merchants, who in turn key in a card amount manually and do everything through old-school menus on the terminal.  The terminal is the whole center of interaction, and the interaction is driven by the merchant, not the card-holder.

This ends up having many limitations for SaaS platforms. The third-party API that you use for communicating with the payment software on the terminal is necessarily outside of the payment details. It just sends commands and waits for responses from a black box. Limited data will be provided back via your API or only your reporting portals (a day or two later). 

Further, putting your own application on the terminal is not a real option with these providers, with app-to-app UX available at best (eg, like the PAX BroadPOS experience).  

Again, most of the SaaS companies we know are disappointed with this kind of offering.  SaaS providers need options, control, visibility, customization and data that are simply not available via such third-party APIs providers.

So what about the Trojan Horse providers (e.g., Clover, Square, SumUp)? Some payments companies are also POS software companies.  Sometimes this is because a payments company bought a POS, like Fiserv bought Clover.  Sometimes this is because a payments company has built more and more POS capabilities to capture more and more revenue from its customers as they grow - like Square or Zettle.  These platforms admittedly have some great capabilities.  Clover can give you a hardware platform to leverage. Square can give you an even bigger platform, including some enviable underwriting and marketing tools. 

The catch here is that you are contracting your customers directly with your competitor, not to mention that you will never control your payment strategy.  Your vendor will set the the payments price your customers pay and keep most of it.  And you shouldn't let yourself be fooled into thinking that your integration to one of these platforms gives you either a new sales channel or an installed base that you just might be able to reach.  We have yet to see either of those pan out.  

Assuming you have successfully decided the above options aren't right for your platform, how can you compare face-to-face integrations among semi-integrated vendors who are dedicated to SaaS? 

A few key criteria: 

• Be sure that the vendor has great documentation COMBINED with great integration support, especially if this is your first step from e-commerce into face-to-face payments.
• Consider what bang for your buck you get from that vendor - Can they
  • help you reach new markets with a single integration? 
  • cover all the use cases you need (kiosks, mobile, checkout counters) with a single integration? 
  • work with every type of application you offer? 
  • give you real-time data that adds greater value? 
  • help you with execution of your payments strategy?  T

This kind of vendor can help shorten both your initial integration time, but also your TOTAL integration time, because you get so much more done with each API you pick up.

2. Your semi-integration method

Not all APIs are the same. There are some genuinely terrible APIs out there. Legacy providers who got into the API game without a dedication to SaaS are notorious for having terrible documentation and terrible APIs.

But even among good APIs, there is variation in how long to estimate for a development project.

How you choose your integration path is dependent on the use case you are solving for combined with your own tech stack.

Ways that you might integrate:

1. REST API: This is the easiest and fastest.  PLUS it works even for entirely cloud-based software. Note that it requires a terminal with IP/internet capabilities, so it tends to require more expensive terminals and some sort of network connectivity. But it is perfect for traditional checkout scenarios with a pc/tablet and a terminal facing the cardholder.  You'll generally be able to run your first transaction with a few lines of code.  But you'll want to budget days of effort to build out every type of transaction that you need (see below).

2. Direct On-Terminal Integration: You may want to put your application on an Android smart terminal (eg, on PAX A920 Pro) to offer an all-in-one.  Perhaps for pay at the table, line busting, in-the-field contractors, in-stadium raffles, or other very mobile use cases.  This type of integration requires that you have an Android application.  Assuming you have that, the length of time you need to budget depends on the "elegance" of the Android SDK that you can use.  Look for something that lets you control the experience, stay out of scope, keep your software up to date, get distribution in the market you want, provide remote support to your terminals, and support a range of terminals for your use cases.  This can be done in days, but can take a couple of weeks. 

3. mPOS integration to a BT device This can be a good solution for native applications on phones where the terminal size or cost are the single most important factor or an IP-enabled terminal cannot be supported.  Look for security and the ability to remotely deploy and support the solutions.  And remember in some markets, you'll need to support PIN even for credit transactions. Of course, BT handling isn't always easy and your app will need to do a lot of the message displays. So anticipate a baseline integration done in a couple of days, with more work depending on how many options you are looking to support.

3. The face-to-face payments features that you choose to implement

Assuming you have chosen the right vendor and the right integration path, the final driver impacting your potential development timelines is determining which face-to-face functionality you need. In some scenarios, you will want every functionality, in others less. In almost all cases, you will want Sale & Void. But, if you are in the business of selling charity raffle tickets, you may not want to implement traditional refunds. Or if you sell tax auditing services, you may not want to implement tipping.

Functionalities that you may want to consider implementing via the terminal:

1. Sale: Almost always the key goal is to let your merchants get paid from the terminal.  Make sure your provider can enable your merchants to accept a broad range of card types. 

2. Voids: Mistakes or last-minute mind changes happen.  Voids allow for transactions to be cancelled before any funds are moved (aka "settled") from the cardholder to the merchant.  

3. Refund:  If the money has already been moved from the cardholder to the merchant, a refund enables the merchant to return some money back to the customer.  This can be very useful for managing customer relationships - e.g., in the case of a returned item or when a extermination service call did not meet expectations.  

4. Tokens: Tokens are not all created equal.  There are multiple types - for omni-commerce, for loyalty/intelligence, for security (sometimes in lieu of other robust methods of encryption...).  Make sure that you can get tokens that help you build the overall solution you are looking for and make no assumptions.

6. Reference ID:  To easily link your your data together, you may want to pass additional data with your transactions. 

7. Tipping or Tip Adjustment: Depending on the markets you serve, tipping may or may not be a key feature.  And depending on the customs of that market, HOW people are comfortable tipping may be very different.  Do cardholders want to tap their own card and enter a tip while the waiter is standing nearby?  Do cardholders want to hand over their card to the waiter and write the tip on a receipt for the restaurant to manually enter at a later time?  

8. MOTO: Mail Order Telephone Order (MOTO) can be a simple way to key in phone orders, whether for a floral arrangement, a prescription delivery request, or a pizza.  

9. PAN from a closed loop card system: Sometimes you want to read a non-payment card and get the number back for loyalty programs.

10. Transaction Routing to Multiple Merchant Accounts: Support multiple-merchant accounts from one terminal.  Ideal for salons, healthcare practices, or other businesses where multiple service providers each with their own merchant accounts share a single facility and checkout.

11. Receipt customization:  Whether cardholders want receipts by email, text, or in-hand, you may want to include additional information.  Can you include a QR code for additional information or to make returns handling simple?  Can you add logos or offers?

12. Transaction APIs: You want to make transactions as valuable and reliable as possible for your customers.  Transaction APIs of various sorts can help you verify transactions and creating transaction reports and portals, either on the terminal or in a back office cloud solution.  A good transaction API will let you see data from the terminal in real time.

And there may be more that are right for your needs.  Just consider that the more flows you want to implement, the more time you will need to budget to your integration timeframe.  

That, in turn, makes good developer documentation and great integration support all the more vital to your timelines.

If you cannot understand how to implement something from the documentation site, first consider whether the documentation itself is a red flag for you.

But when it happens that you are not sure how to implement APIs specific to your software, you need to be able to get fast answers from the right people. We find that our shared developer-to-developer Slack channels are a key driver of development time to market, quality of integration, and developer reviews.

Wrapping it all up

A face-to-face payments integration doesn't need to be a hassle or a headache.

From our own experience, we know that the 3 key factors mentioned above - 1) your choice of a partner or vendor, 2) the selected integration methods, and 3) the face-to-face payments features you choose to implement - can help make your terminal integration process go quickly or take much longer.  Your integration can be completed in years or in a few lines of code.

Handpoint's APIs and terminal solutions are freely available on our dev center.  Please take a look and see how we approach making integrations easy to understand and easy to build. 

Still, Handpoint understands that even just thinking about undertaking a new integration can be overwhelming and that you might not know where to start or even how to evaluate your needs.

That's where we step in to help you evaluate if our solution is right for you. If you're thinking of embarking on a face-to-face payments integration, grab us in the chat box or we'll even happily schedule a 15-minute no-pressure call just to answer your questions.  Just don't hesitate to contact Handpoint for more information on how we can help.