OneCart is an on-demand grocery delivery service, where customers can shop at multiple stores through one centralised platform. For their business to operate successfully, OneCart relies on over 140 shoppers who pick items off the shelves in store and pay for them with their OneCart debit card on behalf of the customer.
A problem arose when shoppers started using these cards to buy items that a customer had not ordered, leading to OneCart making a loss. Monitoring these cards became increasingly difficult for the team – and often, theft would only be picked up on after the fact, which didn’t help solve the problem.
OneCart decided to try out programmable banking as a way to give them more control over how their money was spent. Using the programmable banking tools, they’ve been able to monitor spending and pick up and prevent fraudulent activity instantly, which has saved them a significant amount of money. The technology has also enabled them to track profit in real time as purchases are made in much more granular detail.
Here, OneCart’s CTO, Michael Louis, shares how they used programmable banking to build out these more robust systems, and how they’ve benefited the business.
Click here to download the presentation slide deck.
Transcript of the demo
My name is Michael Louis. I’m the CTO at OneCart. I don’t know if anyone knows who we are or what we do, but we’re an on-demand grocery delivery platform. We allow customers to shop at all their favourite stores such as Woolworths, Pick ‘n Pay, DisChem, Makro, pet stores, health shops – anything you want – from one platform with one checkout, one payment, one delivery. We deliver to them in under two hours.
For the demo today, I’ll take you through how Roots made an impact on our business and how we utilised it. It’s great to show because it’s different from expense tracking categorisation, which is a lot of the work coming out now in terms of the demos.
It’s something slightly different, and this is live. It’s not that we’re working on it and testing it. It is live.
To give you some background about why we entered this exploring phase with Investec and the programmable card – we have around 140 shoppers across SA daily that are shopping – some days more, depending on the demand. Every single shopper now has their own debit card. Previously, we used Sasfin’s APIs that they gave us to regulate limits – so, as a shopper is shopping, their cards are unlocked, and as soon as they’re off an order, the card is locked again. There were a lot of shortcomings. For one, we never knew when a shopper swiped. We only found out or got recons of the card’s purchases about 24 to 48 hours afterwards.
We got SMSes, but when you’re getting SMSes from 140 shoppers every five minutes, you’re not going to see anything. It was hard for us to pick up or see the finer grain control in the field. What you can think about is that shoppers have this card that they don’t know the amount or limits on. They use this card to make purchases. We’ve had some shoppers that have spent about fifty thousand rand on our cards. I don’t want to sound like an idiot – we didn’t let that go. It would be shoppers who would change jobs, and on their last day, they would go to Sportsmans, Gucci, and spend the card limits.
Then there’s the usual case where they add a Coke or a pie to an order, which is still the case today. One thing that we’ve done now is we’ve put in a fine grain set of controls that gives us as much control as we want with our shoppers on the ground. I’ll walk you through the solution on how we do that. For us, it’s completely changed and reduced the amount of shrinkage that we experience with our shoppers.
In terms of the technology we use – I’ll get into it later – but we use the Serverless and Slack Webhooks, and QlikView. With most of the implementations we’ve done, it’s relatively quick and easy to set up. This took us a couple of hours in the night, and we went live the next day. That’s what’s great about being in a startup.
Ben said to add a quote that explains the problems, and this is the only one I could think of. As we grow there are more problems, more shoppers stealing and more money we lose. So, this was the most fitting.
How it works is we use the before and after webhooks. What’s great with Investec and which we couldn’t do before is we can stop theft before it happens. We go through a series of checks before we approve a transaction. One is, we know what’s in the order and what’s the type of amounts that the shopper should order. You must think about items being out of stock, items being substituted, how that changes the pricing, and what the shopper can buy. What first happens is, we do a time check. A shopper can only buy between eight in the morning and six pm. That’s the only time that we’re operational. Any time after that they can’t swipe the card, it will get declined. Two is, we do a merchant check. You know we only shop on Woolworths, Pick ‘n Pay, and DisChem.
We don’t shop at car dealerships, luxury stores, watchmakers, etc. That’s a quick check that we could do. Lastly, we check the card limit. One thing about our system is we have integrations with some of our partners but some we don’t. Also, pricing between stores differs. I’m not sure if you guys are aware that Makro for example, has national pricing, but Game, for example, has different prices in Cape Town than they do in Johannesburg for the same product. For retailers, we don’t have integrations with we don’t have that pricing and we have pricing discrepancies. We built into the card limit a standard deviation of about 10%. If any of those three kinds of checks fail, immediately it sends the Slack and instantaneously someone in our finance department checks on what they were trying to purchase, for what amount and they investigate it. Otherwise, it is approved.
That’s before the transactions even happen, which is great. One of the issues we had initially was the two-second latency, which was a challenge for us in the beginning. There was quite an easy solution for that. After the webhook, we simply set the card limit to nought. One thing that’s nice now on our platform, is that with Sasfin, shoppers would shop from Pick ‘n Pay and Woolworths, for example, and as they walk from Pick ‘n Pay to Woolworths, they would stop at other stores and buy things on the way, and we didn’t know because we didn’t know when they swiped the card. Investec has given us that ability now – as soon as they swipe, they’re only allowed to swipe once, it’s blocked instantaneously. We do that, then we save the transaction so that you know what was the order reference, what was the vendor, what was the amount, etc. and it goes into a business intelligence tool, Qlik, which allows us to look at the gross profit we’re making in real time.
Coming from a development point of view this is average, but for our accounting department, this is a massive saviour because we can see in real time what amount of money we’re making. We’re a cash business. We turn cash daily from the orders, so for them it was a massive thing. It helped us to know that as soon as we drop below a certain percentage, that it is one of two issues, either shopper theft or pricing discrepancies. We picked up with our integration with Makro that they were charging us different prices than the price sheet that they gave us. We were able to alert them and get this resolved within a couple of minutes.
That’s been a real game-changer since we can now do real time settlement of accounts. We know at any time how much money we’ve made, or how much profit in that day instantaneously. A massive saviour. This is what it looks like. This is a shopper that tried to buy something at Makro Woodmead when they weren’t even on an order. They’re obviously not here anymore. This is what QlikView looks like. As you can see, this order is suspicious. The order was worth R1600. This wouldn’t be allowed to go through. It automatically marks in real time how much profit or loss we made on an order, if it’s a problem or not, and if it’s expected. This is when our finance team would deal with the issue. In terms of the results, we can prevent fraud before it happens.
Now instead of detecting fraud 24 to 48 hours later because – before we were chasing people that have already spent R50 000. Shoppers obviously don’t have R50 000 to follow up at once after they’ve purchased the goods. It was always a case of getting them arrested. They would get released a couple of days later. We can never get that money back, and as a startup that’s a lot of money.
During April, when it was COVID, we lost R500 000 in one month. For us, it was a massive game-changer. As I said, track GP in the real time and real time settlement, which I don’t think a lot of retailers, at least the retailers that we deal with, don’t have that type of granularity, even though their POA systems.
In terms of the challenges encountered, I picked up a lot of issues that I didn’t find reported in GitHub but it was because we were pinging it a lot more and it was real life test cases and we were using it frequently.
The two-second latency was an issue. Our servers are on AWS in Ireland. It was fine when Root’s whole thing was hosted there, but they recently moved it to Cape Town. All we did was we keep our containers warm, they’re not cold starting. Now we went from response times of a second when they were cold starting to now being at 100 to 200 milliseconds. That solved that issue. Now, and I’m still waiting for it to be solved, sometimes the webhooks scores twice.
After I swipe my card, the after webhooks score twice. It doesn’t make a difference – we don’t allow duplicates in our database, but it is still an issue. We’ve had cases where transactions have been successful from Root’s side, but it wasn’t. We get the after transaction saying it’s successful, but the card was declined, and it’s not on our transaction log. It is still an issue that I know they’re working on. In the beginning, it was interesting implementing it since there were a lot of differences between the development environment and the production environment on the console. That’s something that’s being released soon and being fixed.
Currently, we have six live shopper cards. On Monday, we’re going live with another 40 in the field. To copy and paste all this code to 45 cards is a bit of a nightmare. A single repository of all code applied, many people brought that up before, and then central logging. Inspecting some of the issues we had when we were initially released, I had to keep going into separate cards and switching its containers, and cards to look at the logs. What we ended up doing was the entire after/before webhook would call our Serverless functions, and we were able to centralise all the logging there instead. We don’t log anything in the Investec console anymore.
In terms of the next steps, we’re going to 45 cards, and after that, we’re going to another 200. The only thing that’s slowing us down is to get this many cards authorised. They’re not FICA’D but assigned to the business. You need to automatically deactivate cards when suspicious activity occurs. We haven’t done this plus it’s a small feature. We haven’t found it necessary, but it’s something we thought about doing. All our use cases are covered. You saw from the results we’ve solved many of our issues already. In the next steps, we don’t have too many.
If you want to get in touch, Slack me. We’re hiring developers. If you’re interested in working here, you can DM me, and we can chat. Any questions?
Hi Michael. This is Grace. This was great. I have a question. It is a technical question. It’s about your containers. You were mentioning that you used to cold start them, and now you keep them warm. Where do you run them? AWS?
AWS is quite nice. As startups, we have $100,000 worth of credits, which is great, but we use a Serverless framework. It’s simply on top of AWS Lambda. We just run it like old school in terms of EC2 instances, but we’re slowly migrating our whole API to Serverless. We’re massive fans. We like to be lean and Serverless is a great technology to not have those infrastructure costs. We’re massive advocates for it. We’ve only seen the benefits of it since we’ve started implementing it. About 30% of our API’s are in Serverless. We have junior developers that are pushing a production with ci pipelines with tests. So Serverless for us is a no brainer, to be honest.
That makes sense. You’re saying that it’s your Lambdas that you try and keep warm. Right?
Only the card limits one, we keep warm. The transaction logging one, we don’t care.
I see. That’s not code related, right? You’re doing something in code to keep it warm, or is that a setting that you must set, where it doesn’t go down at all?
I don’t know if you’ve worked Serverless before, but there are two ways that you can do it. Either one is provision concurrency, which keeps one instance running the entire time. That didn’t work too well with us, that’s what it’s supposed to do. What we do is, we simply keep the containers warm. We ping them every 10 minutes, between 8:00 and 6:30. Because with provision concurrency, it’s like you’re running an EC2 instance. We save the costs of those eight hours that it’s not running.
Perfect. That’s what I wanted to know. Thanks, Michael. This is good.
I’ve got quite a few questions, but I’d love to hear questions from other people. Please don’t be shy.
Ben could ask these questions for weeks.
They came up as you were speaking. Have you thought of any spin-off opportunities after solving these problems for OneCart, or are you guys solely focused on building OneCart, or are you also looking to see if you can build some tech, some proprietary tech that you could resell or reuse?
Something quite interesting, with COVID a lot of businesses realise, I’m sure you guys are all aware of Woolies, Makro, and Pick ‘n Pay’s online stores all of them take three to five working days to deliver. Pick ‘n Pay got the stuff with Bottles, so they’re a lot faster now. That’s how COVID accelerated our development. To give you guys perspective – Ben knows – in April within three weeks, we hired 450 people, which was a horrible experience, to be honest, it’s not great. The one thing that’s accelerated is a lot of companies reach out to us to run their on-demand fulfilment. What that means is we do all their picking, packing and delivery. We do this by not impacting any of their existing operations, we can go into the store, we pay as if we’re a customer because of these credit cards.
We don’t have to have account settlements 30 days later, every seven days recons, all that stuff. The thing that separates us from other potential couriers or competitors is because we can seamlessly integrate. With Makro, we integrated in less than a week. Makro Liquor was in two days. That’s a spin-off service that we don’t advertise. But we do, do. I don’t know if that answered your question.
Yes, it was a bit of a vague question. What API features are you hoping to see in the future, or are you pretty excited about? Are there any now?
We’re trying to turn these credit cards into being the credit card of the shopper. We’ll do real time settlements into their account from our account. What’s nice about that is our shoppers can get lots of perks. And to be honest, it’s bougie with 140 shoppers buying things on Investec cards.
A great thing that we want to do is, sometimes people want cash, so changing whether some merchants are allowed or not, ATM withdrawals to withdraw cash and transferring of money between accounts. That’s all we’ve seen now. However, there’s a couple of things that we’re looking at that we potentially could do – I’ll chat to you and the Investec team about it – but now we’re focusing solely on this problem because, for us, it’s a massive problem.
Capturing receipts, how do you guys do that?
We use OCR tools, and I saw that you released something about it last week. The shopper takes a photo, and we use the receipt for recon purposes if we need to look at the receipt if it gets flagged by QlikView. We tried the whole thing about doing OCR etc. which we did at the beginning of this year, and we didn’t get good results. One is, the shopper is not taking good photos, his finger is in the photo. Receipts, depending on what they ordered, get super long. Those till slips, sometimes it’s well-inked, and sometimes it’s not. The whole thing with OCR, especially with receipts now the technology’s not there yet, because you must take the perfect photo, which unfortunately our shoppers have performance targets to meet, they’re not doing that. We didn’t have too much success with it. We now use it as an order tool.
You take paper receipts or how do you do receipts?
They take an image of it.
A customer gets an electronic receipt. We don’t give the customer the receipt.
Audience member [18:55]
I got a receipt today.
In your bag? Tell me who your shopper was. Was it Makro?
Audience member [18:55]
I’ll check now. I don’t want to get them into trouble.
It’s not live guys. Take it offline. It makes me both sad but also yes, of course, the long receipts thing makes a lot of sense. Devina’s got a raised hand. I hope that means she’s got a question.
I wanted to say hi to Michael. It’s good to put a face to the WhatsApps. The late-night WhatsApps. I wanted to let the guys know what an awesome collaboration it’s been from an Investec perspective with your team. It’s been a real learning curve, not only from a technical perspective but an operational perspective, a risk and compliance angle. I hear you – your cards are on their way – we’re getting there slowly but surely.
It’s been a real learning curve and what’s super exciting for me about this collaboration is, we’re doing stuff that’s breaking ground. For the first time, it feels like we are innovating, at a core product level which is very exciting for us at Investec. I love keeping our product guys on their toes because every time they see me coming, they want to hide and run because they know I’m asking for something that we potentially need to work and hack a solution on in the back-end. But it’s been great and amazing, so thanks, Michael, for your patience. One of the questions is, in about a year where do you see your business, or in two years, and where are you guys hoping to take it? Because for us, it’s about how do we make sure that this is scalable in some way, shape, or form and that other businesses can potentially leverage it?
I don’t know if any of our competitors are on the call, I don’t mind sharing anyway. We’re capitalising on the demand we’ve received from COVID, the on-demand space. The one thing is Takealot is getting better with their deliveries, even hitting the next day now, which is impressive for them. We want to turn it into on-demand.
Expanding our categories into health and beauty, wholesale, and fashion. We’ve had a lot of requests on those industries to bring them online. And we can do so quite quickly and quite easily. Retail shopping malls are not driving as much foot traffic, and we’re seeing them as fulfilment centres. We’ve good relationships in terms of retail centres. We think retail stores will more become flagship stores, and they’ll be shopping centres now turned into fulfilment centres because they’re closer to the consumers since that’s often been the downside of eCommerce. That’s positive. As well as doing medical deliveries, prescription, and chronic medical deliveries to you under 30 minutes. I hate when I’m sick, and I’m down and out, and I must either go to a DisChem to get stuff, or I get it in three to five days through Discovery. We’re working on that.
In terms of being a startup, that’s only two and a bit years now, with the things that we’re working on, these strategic partnerships that we’ve started building on, we’re planning to start hitting about 100 million a month, which for a startup this early, I’ve been involved in a few startups, and that growth is ridiculous. We’re very grateful and privileged to be in this position. It’s got its challenges, don’t get me wrong, and still a long road ahead. I would say that the on-demand spaces are exciting. It’s still in its infancy and eCommerce in South Africa is in its infancy. COVID sparked that to get customers to come more online and businesses.
Thanks, Devina, and thanks for all your work, hustling to get this project out. Devina, a question for you guys at Investec. What are you guys thinking about in the card-issuing side of things because there might be more applications for this type of thing where businesses might want hundreds or thousands of cards. What have you learned from doing this project, what are you going to be changing on your side?
There’s been a lot of learning. We’ve been in constant conversations from the start of programmable banking with Visa, who we partner with. They’ve been with us along the programmable banking journey as well as now with the initiative with OneCart. The real learning here is that there are many different things around the card space and where it’s going and what we need to be doing in that space.
We have an excellent, we call her the Oracle at Investec, who’s been in the industry for about 40 years in the card space, and she often says that she’s seen a lot of where the card has evolved over the years, and she truly believes, and this is what’s exciting for me, and I’ve known her for many years, and she wants to be part of what we’re doing here. She’s amazing. She’s taken us forward in a lot of this. She’s helped to get us Visa approval because she believes that what we’re doing here around programmable banking is truly transformative. Where I’m interested to see it go is what happens when physical cards become obsolete, what happens then? That’s going to be an interesting play, and we’re going to see it from there. Ben, I honestly have no idea in terms of where the industry is going right now. There was a lot of speculation around cards. From an issuing space, you make money off interchange, and the reality is, there’s a lot of speculation around interchange diminishing and not being a revenue stream anymore.
From a banking industry perspective, we are trying to look at more innovative alternative ways in terms of making money. At the heart of that is how we can innovate with our clients so that we can serve them better? That’s the point. The revenue angle is almost secondary right now. It’s more about how we ensure that we can develop products that meet the needs of our clients, rather than having a very inward-looking view. That’s been the idea with programmable banking all along.
In saying that, that’s also the power of it. You’re giving the power to the developers to create those products for your clients, open-source projects across the world. I’ve seen massive successes. That’s how I see this whole initiative, which is fantastic.
Michael, do you see at any point you guys leveraging the community aspect at all putting out challenges for the developer community to solve? It’s still early with you, you’re not sure where you want to go with this yet?
We will. We have strict hiring policies. We hire people that have shown value through side projects they’ve done or through things they’ve previously built. We can do community challenges. It’s how we get interested in individuals that we look to hire. We’ll do it. As we said, it’s early days for us in terms of using the API. It’s only the beginning as we evolve, and as our requirements change, we’ll definitely look to put some out.
Do you think any of your clients might be interested in programmable banking for their platforms, then maybe you guys could act as a partner? I don’t know if I’m pushing all of this too far.
I wouldn’t say – I think they would use it indirectly. They like the fact that we simply slot into their stores as a customer. The only thing that we require from the retailers is to have a faster checkout and skip queues. For them, that’s an easy solution. They’re using it indirectly. I can tell you that the no 30-day recons, etc., have been a massive sell to our clients to get our integrations moving a lot faster with them.
Ben, Can I add one last point?
The other angle that I wanted to ask Michael is, have you guys ever looked to partner strategically to leverage off strategic client bases? We’ve never, as Investec had the conversation around partnering with us to distribute and get OneCart’s brand out there amongst our client base, which might be quite interesting from that perspective, considering we are private banking clients and many of them from a high-income perspective are exactly the guys that are going to be very prevalent in your market. That would be quite interesting. I’m not sure if you’ve looked at strategic partners where you grow your client base in a much more deliberate manner?
We can, but we only look at strategic partnerships for national stores that have wide coverage. In terms of strategic partnerships, we integrated with the AVO app from Nedbank to become the preferred grocery delivery partner.
Nedbank has over 8 million customers, and they’re onboarding thousands of customers each day. That’s one strategic partnership, and we have a couple that is still being finalised. The only way that we’re going to hit our goal of 100 million a month is through strategic partnerships. There are no ways that our marketing budget of a small start-up is going to reach that. Strategic partnerships are all we’re focusing on now.
There’s one question from Jan in the chat. I don’t want to go on too long before we move onto Lesiba’s demo. From Jan – do you have an app layer on top of WhatsApp for the shoppers to communicate replacement options, or items not available? He was impressed with the speed they could communicate and confirm alternatives with exact descriptions.
It might seem impressive from your side, but it’s a hack from our side. Shoppers communicate via WhatsApp, and they have pre-made templates. We know what product you’re looking for, what product they want to substitute, and they click it, and it automatically formats the message to send to you. It saves a lot of time from when they started typing out everything and still gives it this professional feel. We’re busy building on our chat now, which will even be more personalised. You’ll see real time updates of the shopper shopping. As they’re shopping, you can recommend or see recommended substitutes and what’s in stock in real time. There’ll be no need to even communicate with the shopper, but you’ll simply select it on your app.
That’s how it happens. Feel free to reach out to me on Slack. Thanks for your time. I hope to see you guys soon.
Awesome. Thanks a lot, Michael.
Find out how programmable banking can work for your business!
If you’re interested to find out more about how you can use programmable banking at your business, please pop me a mail.