If you have shopped for payments integrations before, you probably have had discussions with traditional acquirers about their excellent support...only to find out later that those guarantees didn't mean you had what you needed, when you needed it.
This time around, you are thinking differently about payments. You want to own the customer journey. You want to control your payments offering. But as this is new territory, you might not know what to ask about embedded payments support when you are considering your options. And you hate that feeling of not knowing what you don't know, which happens ALL THE TIME in payments. As you know.
What questions should you be asking your providers about embedded payments support?
Let's start with the wrong questions. The right question is NOT:
- "Who can my merchants call 24/7?"
- "What is your SLA on merchant support tickets?"
- "Do you provide on-site setup support for terminals?
You have already learned that YOU are the key point of contact for your end users, whether you want to be or not.
What you really need for embedded payments support:
- A great customer-facing product that is ready (and tested) quickly
- Great up-front training for you and your team
- Setups that don't require on-site support
- Fallbacks that ensure your customers never miss a sale
- Processing system security, redundancy, and visibility
- Quality documentation that you can re-use for your support center
- Live tools for diagnosing and fixing things yourself, remotely
- Fast responses to support issues that escalate
These are much better questions to ask:
-
How do we make sure OUR product is ready for OUR customers?
- Your product is an embedded product. It is YOUR product. You need to make sure that YOUR embedded product works.
- Look for great documentation and sandboxes/staging environments.
- Ask how long an integration will take given what you are trying to accomplish, not just the time to implement the first sale call on the first screen.
- Ask about testing procedures. validation, and integration support to make sure you have a great product before it gets into the hands of your customers
- Ask for a supported pilot to make sure you "got it right"
- Make sure that quality of integration support doesn't go away. You'll keep improving your product over time and you want your provider to keep up with you.
- Pro tip: If they make you wait 2 months to fly to a paid training, they are the wrong provider. If they put you in a queue to get an analyst before you can get access to a testing environment, you are with the wrong provider. How would you ever count on them to help you ship code at the pace of Saas?
-
How do we get trained on OUR payment solution - for sales, setups, and payments support?
- More than a development project, you need to be ready to productize YOUR solution, get YOUR sales team/tools ready, and train YOUR support team.
- Look for a program designed to help your entire organization move forward.
- We have seen SaaS companies scale with payments, and we have seen others fail to get the ROI they were expecting. Sometimes it was because their sales team only knew how to sell their old offering. Decide in advance whether you want to succeed or fail at payments. Failing to plan ahead for how you will achieve your success is equivalent to planning to fail.
-
Can you show us EXACTLY what needs to happen to activate OUR customer with payments?
- While you may be willing to take some manual steps to make sure you can set up each product deployment to each end user, you do not want to have a difficult onboarding requirements for your end users. Chances are they are choosing your solution precisely because they are working today with a difficult solution.
- Ask for a demo of the merchant activation experience. What do you need to do and what does your customer need to do?
- Pro tip: If your customer needs to configure an IP address on a terminal, you are with the wrong provider. You'll be fighting through every set up and every replacement.
-
What options do OUR customers have if something goes wrong with our software, a terminal, or the wifi?
- Look for redundancy! Especially in face-to-face payments, there are many breakpoints - from mechanical to network to user error.
- Look for different kinds of redundancy, especially that cover times of day that you don't want to manage escalations. Look for the ability to have your customers fall back to standalone terminals seamlessly if your system goes down or use MOTO (keyed entry) if a credit card is not working well. Offer SIMs in mobile terminals so payments aren't challenged by overtaxed WiFi in a busy bar with happy patrons posting happy pictures online. Offer virtual terminals or even pay-by-link. Fundamentally, help make sure your end users never miss a sale.
- Then look for visibility when you want to understand what went wrong. Can you get terminal logs remotely? Can you see real-time details on why a transaction was declined. Can you push an update or a new key?
- If your customer needs to swap a terminal, make sure it has the easiest set-up so when they get the replacement, they are ready to go instantly.
-
How do we know if there is an issue on your end?
- Transparency is critical when you are selecting an embedded payments provider. If problems occur, you want to know where to look first.
- Look for transparency about your provider's current uptime on every part of their system. An email to your system admin is not enough for the real world.
- Look for cloud-hosting (we are happy to be PCI-DSS Level 1 certified on AWS)
- Look for real-time visibility on transaction responses, so you know what's going on among your merchants. Look for APIs that can help you see activity across your portfolio.
- Ask about pro-active monitoring of key systems
- Ask about frequency of scheduled and unscheduled maintenance windows. Do YOU take your system down to do updates? We don't either.
-
What tools do we have for reviewing in real time: individual transactions, terminal logs, receipts?
- Look for data that you can see from anywhere, that is real-time and rich. Data on total volumes that is available next business day is designed for another purpose. If your customer has an issue arise, you want to be able to investigate it yourself, and now.
- Ask about cloud-hosted tools that your team can access from anywhere to diagnose issues.
- If something has gone wrong, look for APIs or other tools that you can use to reconcile or identify any data you may have lost.
-
If there is a problem, what are we able to fix ourselves?
- Everything that has to happen across companies or, worse, involves shipping, is going to result in delays that are frustrating for your merchant, no matter how fast they are.
- Since this is YOUR product, look for remote tools for managing YOUR applications and terminals. Make sure you can push updates to YOUR software, keys, configs, etc. in real time, without merchant hassles.
-
How can we reach your team to get the fastest response when we need you to help US respond to a support inquiry from OUR customer?
- Look for a provider who understands how you work. An automated bounce back that "Your message has been received" is not service. A friendly chat with a call center employee who does not know what an integration is...is not service.
- You want to reach the right person, fast. The problem might be in your integration, in a terminal, or in a setup, but you may not know up front. When the tools and documentation aren't answering your questions, be sure you can send a Slack, open a chatbot, or get a prompt response to an email from a human who knows what they are doing.
- Once the issue is identified, look for the ability to fix things on the fly.
Asking these questions will give you a much better sense of whether a potential embedded payments provider is going to help you scale with YOUR embedded payments product and YOUR target customers.
Your customers are moving to you in order to get away from the old dinosaur ways of doing business. Don't accidentally tie your future success to a payments dinosaur because you didn't know what you didn't know.