This post has been sitting in my drafts to write for some time now but the news I read this week about Formance raising a $3.1m seed round from Hoxton Ventures and others provided the nudge to actually put my thoughts down on paper and write it.
Nice post - and you've hit on many of the key value drivers behind "payment orchestration". But even though Primer has, by all accounts rejuvenated what was once an ailing space (payment orchestrators never really took off in a big way..) -- we do not see ourselves as a payment orchestrator, and feel "payments orchestration" is an exceptionally narrow worldview.
We would never have been able to gain the reach, traction and funding we have had we decided to build a "payment orchestration platform". As I said, totally dead category at the time. Now becoming all the rage, due to a misunderstanding of what we're building (IMO).
Payment orchestration is a feature. It would be like calling AWS a hosting provider.
The reason we started Primer was due to a lack of *any* technical infrastructure across merchants' payment and commerce stacks. This is a technology problem we're tackling, which certainly unlocks many of the challenges merchants face around optimising payments, but introduces with it many new and interesting opportunities to help merchants build better commerce experiences for their customers, gain greater reach and empower themselves with unique insights across the entire commerce lifecycle.
Our approach was to build the world's first automation platform for payments and commerce, which prior to Primer had never before existed (now being widely replicated). This provides many capabilities around optimising + orchestration payments -- and boosting payments success and conversion, but more importantly -- enables merchants to build comprehensive end-to-end commerce flows.
It's not about PSPs. As far as we're concerned, as PSP is no different to a fraud platform, or a card issuing service, or a KYC platform, or a payouts product, or even Slack. It's about decomposing the payments and commerce stack, and enabling merchants to build their ideal payments and commerce experiences in a unified way.
We're working on becoming the biggest enabler for all of commerce -- for third-parties as well as for merchants, and their customers. I can talk about this for hours -- but we envision a future in which PSPs are not the primary source of distribution for the products and services merchants need to create the best experiences for their customers. Merchants do not see the world in a "PSP-centric" way, and neither do we. We're an application framework, and PSPs, and hundreds of other third party tools, products and services are the libraries merchants need to build their ideal "applications".
Q: do the orchestrators also handle the red edges payout part or only the purple edges part in your diagram?
IF Yes they handle the payout part also; this part of orchestration is nothing but "implicit split payments" (v/s explicit split payments) > essentially one buyer payment split into multiple receivers for settlement (can be done via api level at time of processing or can be done at reporting level after processing). Also some niche PSP's offer this implicit split payments to their big merchant customers already.
Your merchant related questions are very valid - particularly the single point failure.
I don't know but wanted to ask;
- who would own the transaction data? is it the orchestrator or merchant or both?
- is there any ai/ml models that help optimize and / or route to cheapest processor and still have higher auth success rates? I have heard that for some big merchants, payment processing is the 3rd/4th biggest cost component, so can be beneficial.
The graphic you mention is from Payauts website and shows everything that they do, so they also handle payouts. The splitting of payments from what I can tell is especially important for marketplaces.
What do you mean when you say "own"?
Yes I believe that orchestrators optimise the route of a payment based on models and past behaviour to maximise successful payments
- when a user buys an item on amazon, that trasaction data is owned by amazon (because they own the customer who did that transx) even if ti was processed via a processor (any payment stack entities) which they can utilise for their advertising business.
In that sense of 'own'ing the data; when a transx is completed at a amerchant site/app but if that merchat is using one of the orchestrator > who owns the transx data?
- own can also be asking the question of 'what rights does the orchestrator have over that transx data'?
Nice post - and you've hit on many of the key value drivers behind "payment orchestration". But even though Primer has, by all accounts rejuvenated what was once an ailing space (payment orchestrators never really took off in a big way..) -- we do not see ourselves as a payment orchestrator, and feel "payments orchestration" is an exceptionally narrow worldview.
We would never have been able to gain the reach, traction and funding we have had we decided to build a "payment orchestration platform". As I said, totally dead category at the time. Now becoming all the rage, due to a misunderstanding of what we're building (IMO).
Payment orchestration is a feature. It would be like calling AWS a hosting provider.
The reason we started Primer was due to a lack of *any* technical infrastructure across merchants' payment and commerce stacks. This is a technology problem we're tackling, which certainly unlocks many of the challenges merchants face around optimising payments, but introduces with it many new and interesting opportunities to help merchants build better commerce experiences for their customers, gain greater reach and empower themselves with unique insights across the entire commerce lifecycle.
Our approach was to build the world's first automation platform for payments and commerce, which prior to Primer had never before existed (now being widely replicated). This provides many capabilities around optimising + orchestration payments -- and boosting payments success and conversion, but more importantly -- enables merchants to build comprehensive end-to-end commerce flows.
It's not about PSPs. As far as we're concerned, as PSP is no different to a fraud platform, or a card issuing service, or a KYC platform, or a payouts product, or even Slack. It's about decomposing the payments and commerce stack, and enabling merchants to build their ideal payments and commerce experiences in a unified way.
We're working on becoming the biggest enabler for all of commerce -- for third-parties as well as for merchants, and their customers. I can talk about this for hours -- but we envision a future in which PSPs are not the primary source of distribution for the products and services merchants need to create the best experiences for their customers. Merchants do not see the world in a "PSP-centric" way, and neither do we. We're an application framework, and PSPs, and hundreds of other third party tools, products and services are the libraries merchants need to build their ideal "applications".
Thanks so much for your valuable insights Paul, much appreciated.
Q: do the orchestrators also handle the red edges payout part or only the purple edges part in your diagram?
IF Yes they handle the payout part also; this part of orchestration is nothing but "implicit split payments" (v/s explicit split payments) > essentially one buyer payment split into multiple receivers for settlement (can be done via api level at time of processing or can be done at reporting level after processing). Also some niche PSP's offer this implicit split payments to their big merchant customers already.
Your merchant related questions are very valid - particularly the single point failure.
I don't know but wanted to ask;
- who would own the transaction data? is it the orchestrator or merchant or both?
- is there any ai/ml models that help optimize and / or route to cheapest processor and still have higher auth success rates? I have heard that for some big merchants, payment processing is the 3rd/4th biggest cost component, so can be beneficial.
The graphic you mention is from Payauts website and shows everything that they do, so they also handle payouts. The splitting of payments from what I can tell is especially important for marketplaces.
What do you mean when you say "own"?
Yes I believe that orchestrators optimise the route of a payment based on models and past behaviour to maximise successful payments
own;
- when a user buys an item on amazon, that trasaction data is owned by amazon (because they own the customer who did that transx) even if ti was processed via a processor (any payment stack entities) which they can utilise for their advertising business.
In that sense of 'own'ing the data; when a transx is completed at a amerchant site/app but if that merchat is using one of the orchestrator > who owns the transx data?
- own can also be asking the question of 'what rights does the orchestrator have over that transx data'?