Migrating to Stripe Connect
How to design & deliver a big-impact, risk-free PSP migration
With PSD2 being pushed downstream from European parliament to countries implementations and new requirements coming into play, we decided it was time for us to choose a new payment partner.
As a marketplace, changing your main payment processor is no small feat; this article reflects the strategy we used at Selency to deliver that big switch.
The case for Stripe Connect
Flexibility
Marketplaces face complex payment flows. The mantra is to always stay as close to 1:1 as possible: money should get out the same way it got in, and you should delegate as much as possible to your processor. This however is not always easy, due to corner cases well known to marketplaces (e.g. 100€ comes in but 200€ are redistributed to the merchants, because the customer paid using a coupon you sponsor).
Stripe’s Separate Charges and Transfers solution occupies a nice spot in the flexibility / compliance spectrum, providing an API that lets you handle the money-splitting logic while still remaining fully PSD2 compliant.
Reliability
The multiplicity of actors, integration challenges, and legislation evolutions make for a complex payment ecosystem. Failures are common, and vendors offer varying levels of shielding from these failures. Our previous partner, in addition to providing little shielding, added their own extra layer of failures. Accountability was also an issue, as it was our responsibility to provide logs when things went haywire on their side.
Reliability is especially important as you scale, as any time spent on manual repairs will grow non-linearly following your company growth function and rapidly become unmanageable.
Stripe’s reliability is demonstrated in various ways, from their status page to their precious in-dashboard API requests logs.
Establishing the migration framework
The last thing you want is to find yourself pushing a big red button and suddenly have all your transactions processed by your new processor. By establishing a clear migration framework, we can focus on the objectives we want to maximize, namely:
☑️ Safety
This one is a given. At any moment in time, should you be in control of the migration, i.e. have the ability to monitor, rollout and rollback.
☑️ User Experience
Ultimately your users, especially your merchants, will be the one experiencing the migration. It should not come as a surprise-surprise-emergency to them and be the lesser of a burden as possible.
☑️ Room for learning
While general concepts can be grasped from documentation and sandboxes, it takes time and real-world transactions to learn all the intricacies of any new solution.
In addition to these objectives, we identify sanity metrics that will be followed during and after the migration:
📊 Conversion
Conversion is the easiest metric to monitor and speaks for itself: this one shouldn’t drop on cash-in made with the new system.
📊 Adoption
How many merchants have completed the migration process and are ready for Stripe cash-out?
📊 Time to cash-out
We measure time to cash-out as the delay in days between the payout request for a sale by a merchant and the actual processing of the payout. Averaging it provides a simple and efficient proxy to the cash-out pipeline health.
With these objectives and metrics in mind, we can start to design our migration plan.
Sequencing
The first step to establishing your plan is to lay out its sequencing, relative to cash-in and cash-out releases.
We choosed to order the stages as-is to fight the hardest battle first: migrating the cash-out. Before starting to issue transfers with Stripe, you will need to onboard your existing merchants base which, as Account Tokens are either recommended or mandatory depending on your country, will require an in-browser action on their side (more on that below in Selling the switch).
Handling overlaps
Once the sequencing is laid out, it is easy to identify overlaps in cash-in and cash-out.
Overlaps induce their own funds management problems. How can funds cashed in with legacy PSP be cashed out with Stripe?
To solve this issue, we introduced to our order system an audit layer with funds management capabilities. The audit layer in itself could be the main subject of another article. For the sake of this migration, its role was to continuously keep in check inputs and outputs: if the output gateway didn’t match the input gateway, the system would take note of the required funds movements to make to reach equilibrium.
It is especially important to involve Stripe while designing your overlaps and funds movements strategy so they can greenlight it.
Migration plans without overlaps are possible, but overlaps allow for a safe and progressive rollout of the new cash-in and cash-out. Without designed overlaps management, you’ll be resorting to a big-bang with no AZ-5.
Segmentation
Once the sequencing is clear, it is time to bucket your users to allow for a progressive rollout. The strategies we used were different for cash-in and cash-out.
For cash-out, we bucketed our merchants according to their current state of account usability: priority was given to merchants failing to get their account validated on our legacy PSP, which helped us to confirm our integration was working well on our most complex cases as well as give them the chance to solve their validation problems faster.
For cash-in, a simple roll-out by 10% increments of our user base was put in place.
Selling the switch
I’m no wiz but can assure you no one wants to wake up one day and have to fill an identity & payment details form over the Internet. That’s precisely why we invested time designing a migration process as frictionless as possible for our merchants.
We used a popin for the migration form, as it could be displayed on any page, triggered by sellers actions related to their orders and payments.
The popin itself was structured as above, with the hard work (personal info steps) prefaced by a marketing pitch. We also used the migration as an opportunity to implement a very-much-awaited “Automatic Payout Requests” merchant feature, which further helped the pitch.
As Stripe’s account tokens system let you the opportunity to collect the user data in your own forms, we were able to pre-fill the personal info steps as much as possible.
Final thoughts
The time required to complete a migration to Stripe Connect is largely dependent on your company unique characteristics and current state of payments infrastructure. You will possibly end-up with another sequencing, another segmentation, alternative metrics to monitor.
What’s most important is to spend time designing your migration framework. The structure we recommend is the one described in this article:
Objectives + Metrics ➡️ Sequencing + Overlaps ➡️ Segmentation + Rollout
At Selency — a pretty complex marketplace with thousands of sellers — we were able to complete the cash-out migration in a solid month, with one developer working on it full-time and another as an active reviewer. Implementing the cash-in took another two short weeks, most of the work lying in the progressive rollout part.
We’d also like to use this article as an opportunity to thank Stripe’s team: shoutout to Pierre, Carlo and Martin for their help and engagement in making this migration a success.
PS: We are looking for talents ;-)
