[jsumrall]

Hi, very interesting segment of the market!

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.

[anta81]

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.

[AnkaOne]

Thanks for your edge cases! If you are doing PSP routing in your own system, how exactly VGS helped you with Payments automation?

[primerapi]

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.