How to Prevent a “Failure to Launch” Payments Integration
Picture this: You find yourself in the market for a new payments partner or need to add a payments integration to your software application for the first time. You research solution providers, narrow down the list to a few, conduct thorough due diligence, select a winner, and execute a partnership agreement. Your development team engages, completes the integration, and your solution is ready for release. It’s smooth sailing ahead, right? Six months later, though, you’ve failed to commercialize the solution with only a handful of customers managing payment acceptance through your application. By now, it’s painfully clear where it all went wrong: missteps in solutions engineering and the process of ensuring payments integrations align with market demands.
We hear this scenario recounted more frequently than you would think. But where exactly do the missteps happen and, more importantly, how can you avoid them?
Full-Service Partnerships vs. Payment APIs
Most prevalently, we see issues arise in self-service payment integrations where a software provider’s development team typically works autonomously to complete a payments integration through a development portal using a payment API. The software provider is on their own to define requirements without counsel from a payments expert. As a result, feature functionality necessary to be market competitive or that would allow for differentiation can (and does) get missed.
A second way features get missed is when product and development teams fail to align. As an example, in larger software shops, product owners define integration requirements and development departments are tasked to execute the work. A dependency exists between teams to communicate effectively and be on the same page. When alignment fails, the result is a payments integration that can’t compete.
In contrast with a self-service integration experience, with full-service providers, extra emphasis is usually placed on solutions engineering with the goal of ensuring payment solutions are optimally architected. This includes access to domain experts who deeply understand the solutions required for specialty verticals, including features that today’s modern users expect.
What does solutions engineering look like in action? Here are some of the steps you can expect, best practices your payments partner may follow, and considerations for each phase of the process.
Step 1: Requirements Gathering
During requirements gathering, solutions engineers seek to understand an ISV’s current processing environment (if applicable) or high-level solutions goals if embarking on a first-time integration. This includes understanding the drivers behind the integration and what the ISV is working to accomplish, including points of pain in the current solution. As an ISV, this is your chance to articulate integrated payments-related challenges and interests because the clearer the understanding, the better the engineer can solution a tailored integration to meet your unique needs.
Step 2: Onboarding
Providing a merchant onboarding experience with as little friction as possible is optimal for many reasons. For software providers, this means higher adoption rates and faster time to profitability, and for software clients, it results in a seamless setup experience. The goal of solutioning for onboarding is to understand today’s process and key consideration details that will influence which onboarding solution is right for you. For example, is your customer vertical consistent where factors like merchant category code (MCC), risk profile, and average tickets are similar, or is it variable? Does transaction processing take place in card-present or card-not-present environments, or both? With options spanning from instant boarding APIs to standard online merchant applications to white-glove inside-sales service and variations in between, your partner should strive to help you remove as much friction as possible from the onboarding process while considering all factors at play.
Step 3: Transaction Processing
Here’s where the payments tech stack takes center stage and begins to come together. The process begins with the basics: defining transaction types, payment types, acceptance methods, and value-added features to support:
• Transaction Types: Sales, Auths, Voids, Credits, etc.
• Payment Types: Credit (Visa, MasterCard, AMEX, Discover), Debit, ACH, Mobile Wallets, etc.
• Acceptance Methods: Cloud POS Devices (EMV/Contactless), eInvoicing, Hosted Solutions, Mobile Payments, Text-to-Pay, etc.
• Value-Added Features: Tokenization, Card Account Updater, Chargeback Management, etc.
Engineers seek to understand the current client experience with special attention paid to opportunities for optimization along the way. For example, if key transaction types like voids/refunds are not supported through the current integration, resulting in software clients having to work between systems, engineers will make recommendations to remedy this pain point. Likewise, domain experts will safeguard against missing out on tech crucial for market penetration in specialty verticals.
Step 4: Settlement Funding
Finally, the process concludes with defining how software clients will receive settlement funding. After understanding the current state, engineers will explain funding options, including flows and timeframes, and advise which are best suited/available to you. For example, same-day and next-day funding options, as well as flexible funding flows where settlement deposits are disbursed into multiple bank accounts in an automated process, may be available. Engineers will also advise on how to make your solution more marketable where applicable to your business model. This can include models where software providers can waive clients’ software subscription fees and instead assess a percentage-based fee calculated on transaction volume processed by their software clients. Funding for transactions can then be split between your client’s deposit account and your own.
With the culmination of settlement funding defined, you now have the blueprint for a payments integration that can be fully commercialized and ready to embark on development.
The Ideal Payments Integration Solution
Effective solutions engineering results in a market-competitive product offering that adds value for customers, aligns with vertical needs, enables software providers to differentiate, and makes broad commercialization possible.
At Paya, we place particular emphasis on solutions engineering, engaging our domain experts as part of the early sales process. Through a collaborative but simple hands-on process, we develop a deep understanding of our partners’ current processes and pain points and ensure platform and system capabilities and solution and needs align. With more than 25 years of industry experience and 2,000+ industry partners, Paya is the leader in delivering simpler, more efficient, and deeply integrated payment solutions. Learn more about our how our domain experts, solutions, and processes can benefit your organization.