We are Anta and Karthik of Inai (https://www.inai.io/), a platform for setting up and operating your payment stack. We let you offer local payment methods, support multiple business models (e-commerce, subscriptions , platforms) and localise the checkout experience by region of operation.
Setting up and maintaining a payment stack, especially if you operate in multiple regions, takes months of developer time. Most merchants set up their stacks ad hoc, leading to loss of revenue (e.g. if you don't display Apple Pay in a certain way at checkout, Apple will penalize; same for Paypal) and wasted admin time (multiple dashboards for refunds, coupons etc). Working with a single payment provider locks the merchant in, as customer data is vaulted with the Payment Service Provider (PSP) making switching difficult. Meanwhile customer payment methods are exploding with newer rails like BNPLs (Buy Now Pay Later), open banking, QR code based and even crypto emerging rapidly
Karthik and I previously ran a DTC fitness business. Tailoring the payment stack to each market that we expanded into was a big pain. We spent weeks on every payment integration and our payment stack was a mess. We were after all running a fitness business and not a payments one.
At Inai, we provide a single unified API that connects to multiple payment providers (Stripe, Braintree), alternate payment methods (wallets, BNPLs etc). We make it easy to launch into new markets and to keep your service agnostic of PSP. For B2B companies, we make it easy to allow your customers to send invoice links and accept payments across cards and ACH.
We plan to give merchants a IFTTT dashboard to set up custom business logic (e.g. show Klarna, SOFORT, and cards in Germany but cards, Paypal, and Apple Pay in US). Merchants can view all transactions across providers, and very shortly will be able to manage chargebacks, refunds, and coupons, and get analytics on transactions (e.g. success rates by card/PSP, insights on why transactions were declined).
Payment orchestration as a concept is not new, but medium sized merchants were not being served well with the existing solutions. We found that many merchants in this category had a knowledge gap with respect to payments and therefore needed someone to hand-hold and deliver outcomes for them, so fixing this is what we are focussed on.
We are building this product for merchants so if you have a use case that is currently not being served by our product, we would love to hear from you. Your problems and pain points will drive our roadmap.
How do you compare yourself to Spreedly? How would you compete with their offering?
I think these solutions are really neat, but I wonder how you can handle some edge cases which I think are really difficult. For example, let's say I want to use credit cards with Adyen. Now after a year of this, I have a lot of customers with their credit cards connected to my business via Inai so recurring payments go smoothly. Now, Stripe comes knocking and will give me a much better price on credit cards. Can I just switch the backend to start routing card payments to Stripe? Will all the customers need to re-enroll their credit cards when trying to pay now? If not, then I guess you're managing the card data on you side?
I think this and Spreedly are interesting, but I can imagine that for large companies, you want more control over your payments flow even than what's provided here, which is why when compared to Spreedly, we personally went with VGS and do the PSP routing in our own system.
IF my assumption about that is true, then that leaves you with the smaller merchant market. Of those users, I think just sticking with one of the reliable PSPs with global coverage (Stripe/Adyen) might be simpler.
Hey - thanks much for your question.
Specific to your use-case on subscriptions - we have decoupled the subscriptions software layer from the payment rails. So yes, we can do exactly what you mentioned - which is switching providers for subscriptions without customer friction. Traditional orchestration companies will allow you to vault the cards and reuse them for recurring payments - but would require you to manage the logic around subscriptions (in your case).
With inai, we allow businesses to manage their subscriptions and associated payment logic from within our dashboard.
Hi, Paul here - head of engineering at Primer.io. There are a lot of "payments orchestration" companies floating around, but we think of ourselves as an automation platform for payments - Similar to Zapier in many ways.
I previously worked for Braintree/PayPal where I worked closely with Spotify, Uber, Ticketmaster and many of PayPal's marquee merchants on their payments integrations and payments strategies. We think about these things in terms of end-to-end payment flows.
You're outlining a scenario in which another PSP may give you better pricing at some point down the line. So typically, you'd rip out the Adyen integration and then go about integrating Stripe.. and you'd also need to request that Adyen migrate raw payment information over to Stripe, and hope they'd pass along all the respective network transaction information as well as any 3DS/SCA data that has been stored to ensure you don't see a drop in auth rates, or need to re-authenticate with 3DS or request CVV information on subsequent payments (lots of friction, lots of drop-off).
And that's just for cards. Apple Pay and other mobile wallets now enable vaulting, as well as other payment methods such as PayPal, Klarna, etc.
So you see that the issue here is bad separation of concerns for engineers. You should have custody of your payment method data, and be able to decide when and where to process payments (or indeed, pass payments data to other, independent downstream services). With Primer, we've decoupled every single area of traditional payments acceptance, enabling you to connect any number of payments, and non payments specific services using drag-and-drop workflows.
In your case, you'd simply change this route on your workflow from Adyen to Stripe, and voila.. everything just works - even the checkout! You may decide to get more detailed than that. Over time, you'll discover some PSPs perform better than others, that you can improve conversion or reduce risk by introducing third-party fraud providers, that you can optimise for cost and reduce cross-border fees with more refined routing and conditions... the list is endless!
In that sense, we've designed something akin to a developer framework for payments. A unified way of integrating and reasoning about payments completely decoupled from any specific providers. There are tons, and tons of security, infrastructure, and payments specific considerations that need to be made when building an agnostic platform such as this and would be happy to take any questions you may have about it.
Not to cause a fuss, but the reason for my posting this here is inai "borrowed" their concept from us after they signed up for a Primer account under their previous business, and set about ripping off every part of our product from the website to the job board! (All since updated... partially.) It is what it is :/
But Primer is built by payments folks and engineers who have experienced first-hand the complexities of payments as companies scale, and I'd be super happy to answer any questions you might have on solving more complex use-cases.
I'm (among other things) a fintech consultant specializing in payments; my company primarily works with Stripe, sometimes with Adyen/Worldpay/Xsolla.
Like you said, payments orchestration is nothing new. What differentiates you from any other middleman in the field?
I'll give you one example as a test scenario: A current client of mine is a small business incorporated in the US, doing business in both the US and South Korea with $10/mo subscriptions. They want to offer native South Korean payment methods in SK such as KakaoPay and Samsung Pay. I've had to set them up with Smart2pay (Nuvei) because, after months of negotiations, Adyen wouldn't take a contract with them because they're too small a fish to care about. In the US, they offer Paypal and Stripe but their current gateway middleman (Uscreen) takes an obscene cut and doesn't offer good subscription management features to make up for it.
Their current payment stack is inconsistent, hard to manage, lacks lots of admin features and costs them more than it should. If you can do something for them, I'll be super impressed :) (Email in my profile!)
Is this like an aggregator of aggregators given that Stripe, Adyen already aggregate several payment providers? What's the long game here if someone like Stripe starts supporting every payment method?
Setting up and maintaining a payment stack, especially if you operate in multiple regions, takes months of developer time. Most merchants set up their stacks ad hoc, leading to loss of revenue (e.g. if you don't display Apple Pay in a certain way at checkout, Apple will penalize; same for Paypal) and wasted admin time (multiple dashboards for refunds, coupons etc). Working with a single payment provider locks the merchant in, as customer data is vaulted with the Payment Service Provider (PSP) making switching difficult. Meanwhile customer payment methods are exploding with newer rails like BNPLs (Buy Now Pay Later), open banking, QR code based and even crypto emerging rapidly
Karthik and I previously ran a DTC fitness business. Tailoring the payment stack to each market that we expanded into was a big pain. We spent weeks on every payment integration and our payment stack was a mess. We were after all running a fitness business and not a payments one.
At Inai, we provide a single unified API that connects to multiple payment providers (Stripe, Braintree), alternate payment methods (wallets, BNPLs etc). We make it easy to launch into new markets and to keep your service agnostic of PSP. For B2B companies, we make it easy to allow your customers to send invoice links and accept payments across cards and ACH.
We plan to give merchants a IFTTT dashboard to set up custom business logic (e.g. show Klarna, SOFORT, and cards in Germany but cards, Paypal, and Apple Pay in US). Merchants can view all transactions across providers, and very shortly will be able to manage chargebacks, refunds, and coupons, and get analytics on transactions (e.g. success rates by card/PSP, insights on why transactions were declined).
Payment orchestration as a concept is not new, but medium sized merchants were not being served well with the existing solutions. We found that many merchants in this category had a knowledge gap with respect to payments and therefore needed someone to hand-hold and deliver outcomes for them, so fixing this is what we are focussed on.
We are building this product for merchants so if you have a use case that is currently not being served by our product, we would love to hear from you. Your problems and pain points will drive our roadmap.