Hi everyone, my name is Paul and last year, a colleague and I left our positions at PayPal to found primer.io.
For my part, Primer was a response to the ever-increasing technical complexity around managing and integrating multiple payments services, and other APIs from across the web as part of a payment lifecycle.
I'm most excited about how we've tackled the developer experience around integrating payments, and future-proofing this regardless of how complex your payments flows become. And - we've managed to achieve this through a unified payment lifecycle so you only have to reason about payments once.
Happy to answer any questions you might have, and how we're thinking about scaling this in the future - or facilitating other complex use-cases :)
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.
Primer is an early stage startup backed by Europe's leading investors (Revolut, MySQL, TransferWise, UiPath). Our mission: enable online merchants to power the world's greatest payments experiences for their customers. (We know, it's vague... but we're in stealth mode!)
You may be thinking, "should I be joining an early-stage startup right now?". Well, we've just closed a significant round of funding from Europe's leading fintech investors during this tumultuous time. And we're hiring like crazy :)
Online payments is due a significant shake up, and we believe our technology will change the landscape of online payments forever.
Primer | Backend, Full-stack Engineer | Full-time | London UK, Remote (Europe)
Primer is an early-stage startup with backing from Europe's leading fintech investors (early stage investors in Revolut, TransferWise, Monese, UiPath). We're on a mission to help online merchants power the best commerce experiences in the world (we know, it won't be easy).
We're looking for super ambitious folks to form part of our founding engineering team, help define our underlying technical architecture and get involved in product-making decisions. We're an engineering-led organisation which believes the best functionality comes as a result of deep technical insights.
We've found our product market fit, and we even have engaged customers ready and willing to use our product! If you're a product-centric engineer who would like to contribute towards the long-term vision of an early-stage startup and share in the success, get in touch.
Primer (early stage startup) | London, UK | Onsite | Backend Developer, Frontend Developer
Primer is an early-stage startup with backing from Europe's leading fintech investors (early stage investors in Revolut, TransferWise, Monese, UiPath). We're on a mission to help online merchants power the best commerce experiences in the world.
We're currently building out a 4-5 person engineering team to play a critical role in the development of our platform and MVP for go-to-market early 2021. If you're looking for an enormous challenge, and the opportunity to build a leading-edge commerce toolkit from scratch, get in touch by applying or reach out for a casual chat.
For my part, Primer was a response to the ever-increasing technical complexity around managing and integrating multiple payments services, and other APIs from across the web as part of a payment lifecycle.
I'm most excited about how we've tackled the developer experience around integrating payments, and future-proofing this regardless of how complex your payments flows become. And - we've managed to achieve this through a unified payment lifecycle so you only have to reason about payments once.
Happy to answer any questions you might have, and how we're thinking about scaling this in the future - or facilitating other complex use-cases :)