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.