Background
Flux's API connects a retailer POS to a bank transactions feed, allowing retailers to enrich the transactions of their customers with digital receipts, offers, and loyalty directly in their banking app.
For the first couple of years, we onboarded each retailer onto the Flux network manually. Each retailer meant a new payment provider to support, a new data source to add in our system, a new POS to integrate with.
Over time, as we scaled and added more merchants, we automated as much of the process as possible.
Challenges
We had two very distinct categories of retailers to support:
- Large chains; whose payment and POS infrastructure frequently relied on custom built, legacy, systems that required ad-hoc work and engineering resources to integrate with.
- SMEs; using Zettle, Stripe and similar services to process their transaction and manage their inventory.
Our experience and research with the first category of retailers suggested that a self-onboarding platform was not gonna work. For them, integrating with a new data partner was not only complex from a tech perspective, but also required many layers of management buy-in before something would go through.
We opted for two different strategies:
- We would support and facilitate large chains by creating developer's tools that their tech team could use to integrate with our API. This would go into reducing the integration cost, their primary concern.
- We would focus our self-onboarding efforts on SMEs (small and medium-sized retailers)
A quick MVP with Zettle
A couple of years earlier, I and another engineer were asked to work on a self-onboarding project as an experiment. We built a small functional MVP over a couple of weeks, limited to Zettle merchants. We picked Zettle for their merchant network (small retailers that can move fast) and for their API (it was quite easy to integrate with).
We targeted retailers in our area, and walked store to store to see if they were willing to try our platform, learn what worked, what didn't. We successfully onboarded a few of them, but the company ultimatedly decided it wasn't in their interest at the time. The experiment did however inform our decisions when, a couple of years later, it became a company priority to build such tool again.
Design
I designed the app as the single interface that a retailer had to use to:
- Sign up to Flux
- Find out, set up and manage Flux services (digital receipts, offers, and insights)
- Access support
- Access our API tools (if needed)
Onboarding
Retailers were able to authenticate a POS via Oauth and sign up to Flux without using up any engineering resource.
Welcome screen
Sometimes, the first sync took a while. We also had to manually check the quality of the item-level data we were receiving, before switching on digital receipts for our bank partners. In these scenarios, we made sure the retailer was always up to date to what was happening behind the scenes.
Data sources gallery
Some retailers use multiple POS, one for their e-commerce and a different one for their physical store. Others have specific systems for running loyalty programs, or use a third-party provider to process payments.
None of that was a problem — a retailer could connect multiple sources and manage their existing ones via our gallery of integrations.
Monitoring offers
Post-onboarding, the platform allowed retailers to:
- Check insights on their customers
- Launch and monitor the offers they were running on our network
