Every week, we run a meetup for the Investec Programmable Banking community. Developers demo cool projects they've been working on and everyone has the chance to ask questions. If you've been wondering where programmable banking is at, here's your sneak peek!
In this demo, Loic Ndame shares how he built a transaction and receipt application that stores bank transactions and lets you associate a receipt with a transaction. His goal in building this tool is to help people keep less paper receipts in their wallets, which make them look bigger and more appealing to pick-pockets. Ultimately, he hopes this tool will help make the world a safer place.
The tech he worked with includes Flutter, Dart, Flask (Python), Firebase and the Investec OpenAPI.
Click here to download Loic’s presentation slide deck.
Repo coming soon!
Transcript of the demo
Loic [00:09]
All right. Thanks for joining me tonight.
Loic [00:11]
The app that I will be going through is a simple one, but there's integration of quite a few technologies in there. My name is Loic, and I am currently an Android developer for DVT but working on the Discovery project, doing the intro stuff.
Loic [00:47]
The app that I decided to create for this project is a receipt capture app. I wasn't particularly good with the name so thanks, Ben, for that as well.
Loic [01:00]
The purpose of the app is to keep track of receipts that we have. Hopefully, this will reduce the size of some people's wallets. Currently, my personal wallet is full of these things, and I can't keep track of any receipts in there. Then sometimes you get to a shop, and you see that guy with that huge wallet, and he has all those receipts that he keeps in there.
Loic [01:30]
So the name of the app, I would say, makes the world a little bit safer because when you have that big wallet, somebody can notice you from far away and say, “Oh, sure he has something in his pocket, it could be interesting, let's see what it is.”
Loic [01:47]
The app is built in Flutter using the OpenAPI, which is wrapped in a Flask microservice, and then the receipts themselves – I am storing them in Firebase right now. The stack, how does it work? I'm taking the content from the OpenAPI that was released to the Investec community, putting it in the Flusk microservices API and then the whole thing is deployed in Heroku.
Loic [02:27]
Then, the API into the wrapper, which is also stored in Heroku. I get the transaction from there, and then I can pick up a transaction, add the receipt and install the receipt in Firebase. Let's see how that works in practice.
Loic [02:56]
The app is open, and it's coming in there with some of the transactions that I received. Just for the demo purpose, none of the numbers are real, I'm getting the real amount from the invoice from the API, but then I multiply them with a random number every time to screw the numbers up and make them look good.
Loic [03:21]
Since I'm in the emulator, if I select a transaction, let's say I was sitting back, and I want to add a receipt, then it gets me to the page where I want to add the receipt for that one. Let's pretend this is a receipt – it looks much better than a receipt, but let's pretend I'll pick up that and then I'll say save the receipt. Right.
Loic [03:58]
Once this is done, it gives me confirmation that I got the receipt, and then I can go back and see all the receipts that I've saved. Here are some of them and here's an actual receipt in there.
Loic [04:27]
The wrappers, which are sitting on Heroku, give me all the data that I need. I can get the accounts in there, and I can also see some of the transactions from it. So, that's what I'm getting from it.
Loic [04:49]
Okay, back to the presentation. If anyone wants to get involved with the idea and give me more ways to do it better, I will share my details now.
Loic [05:09]
Most of the challenges that came in were due to the limitation of the API. So far, we are only working with what we got so we have to do it the best way, but I'm confident as we go along as we propose more ideas, we can get a little bit more flexibility on the API, and then do things better with it.
Loic [05:31]
If you want to get in touch with me, my email address or Skype is usually the fastest way to reach me.
Loic [05:41]
The next step that I want to do is to improve on the UI, make it better and, I would like to add some graphs into the application that would be able to show the fluctuation on my transactions. If I can have a better OCR, I can read the actual amounts in the transaction, and then add some filtering into the application.
Loic [06:16]
Thank you for having listened to my TED talk. Any questions?
Willem [06:21]
I've got a question. Yeah. Maybe elaborate on the API's restrictions, or I think you've mentioned that there are restrictions, but maybe, can you elaborate on that a bit, maybe refer to something that would have helped you during this process – anything apart from the transaction ID.
Loic: [06:49]
The transaction ID wasn't that much of a problem because for me, when associating the receipt to a specific transaction, the hash works just fine so I can pick it up from there. Using this as an ID is just as good. If for instance, I want to, call for filtering, right now, if I want to do filtering, it's up to me to actually, write it up instead of …
Willem [07:28]
What kind of folders would you want to see apart from the date filtering that we currently have available?
Loic [07:35]
For instance, if we can have five types of categories – because now the type fits only debit or credit – but if we can have a little bit more, perhaps getting categories from the actual transaction we're making I guess or something else or whatever.
Willem [08:06]
We'll look into that.
Audience member [08:16]
We don't get the pending transactions. Is that correct?
Willem [08:21]
Not separately, no. That is all the transactions that we are currently getting from our underlying host systems. Actually, to my knowledge, we have started with the investigations and seeing how we could provide you guys with just pending transactions, but we're going to have to essentially integrate with a separate API downstream to make that happen.
Willem [08:55]
I need to have a look and get a confirmation on that, but to my knowledge from an Investec online perspective, they are consuming a separate API to get those pending transactions, but it will be quite useful.
Willem [09:14]
Another thing that we've got in the pipeline is a running balance. That is something that we realised we do get from the underlying host systems. I don't know if it will be very useful, but I guess it's not a major task to implement it and provide you guys with that as well.
Audience member [09:41]
Excellent, because I presume that would be very helpful if you have the receipts and you don't have a pending transaction yet.
Willem [09:48]
I think it was one of the guys at OfferZen that we had a conversation about one of the systems that they were building and there was an ask for the running balance, and since we've got it, it's not a big deal to edit it.
Willem [10:08]
Yeah, we will always be quite transparent with you guys so just some feedback with regards to that transaction ID. I think the common thing is it seems something very trivial to do, it's there to do it, but the problem that we are facing at this point is that, as a development team, we don't have control over that response payload.
Willem [10:39]
We have to deal with what we get from the host systems. We have been in conversations with the relevant dev teams, to get it but there is a bit of a capacity issue at this point. I think at the end of the day, we can produce a transaction ID, but the problem that I've got with that is at the moment the underlying host system actually provides us with a transaction ID but, it will essentially render all of these, shall I say, hacked transaction IDs, redundant.
Willem [11:22]
I don't know what impact that would have with your current implementations because I'm, assuming you guys are constantly mining these transactions. I don't want to introduce a transaction ID that might be deprecated in the near future. It is on their priority list – it is on the backlog.
Willem [11:47]
There's another thing that I wanted to mention to you guys – we are getting in our production environment, our OpenAPI is raising a lot of 401 alerts, and that is generally if you consume it, if you're attempting to get a token from the identity product, or the identity API has invalid credentials, that will raise a 401 and that subsequently gets alerted on our side.
Willem [12:22]
If you are trying to obtain accounts, transactions or balances with an invalid bearer token, also that will raise a 401. We can see quite a few of these being raised. I don't know if somebody in the community is building a prototype that polls for transactions constantly with either expired bearer tokens, or invalid credentials. So I just wanted to bring that to light to you guys, as well, it's not a big issue at this point, it is just something that we can see is raising quite a lot of noise.
Willem [13:02]
Yeah, that's it and then also, what we did is just maybe as a little update – it's not a feature update, but essentially, what we did over the last two weeks is we've done some work with regards to environmental changes.
Willem [13:24]
Essentially, all of your lambdas are now kept warm. The execution time should come down quite a bit. Our route engine, or programmable core engine, is running in our Kubernetes environment and we've done a few upgrades in that regard. It's not necessarily a transaction ID, but at the end of the day, it's all contributing towards the platform.
Michael [14:10]
Willem just on the volume of those 401s – what was the volume on that?
Willem [14:16]
It's quite a lot – to the point where our ops teams asked us to stack it together and only report every 15 minutes. I think there's quite a few of those.
Michael [14:32]
I was doing a change into spam, but this is more automated, not manual.
Willem [14:39]
Yeah. I guess there are many prototypes in the community where people are probably polling the OpenAPI every five minutes. I just wanted to let you guys know and maybe say, make sure that your tokens are still valid. It does expire so every time you do a sweep, get a new bearer token, and do the sweep, and then ensure that your credentials are correct. It's not, causing havoc. It's just something that I can see and just wanted to raise with you guys.
Ben [15:25]
Cool. Have you considered rate-limiting?
Willem [15:34]
There is a default rate limit, and obviously, we do have the general DDoS protection and all the rest. We are just using the default rate, and there are no real quota restrictions for now. I don't think there's a big need to, but obviously, if you want to request or do 100 requests per minute or whatever, we'll probably start limiting you but I think, for now, it's not that big of an issue. Cool.
Ben [16:12]
Thanks. Loic, that was an awesome demo. I like what you built. I noticed there was a card at the top and there was another card to the side. Can you see different accounts?
Loic [16:24]
Yeah. All the accounts that the API gave me, I can present them in that way. If I go back to that a little bit on my side, it will be different accounts that come back.
Ben [16:52]
And the transaction, can you also change them to transactions per account?
Loic [17:01]
I didn't implement that, but I can because I get the account ID that has a transaction.
Ben [17:08]
Okay, so those transactions that are shown there are just on your private bank account at the moment. Yeah. Okay, cool. I want to use that app, but I don't know if I can use it on iOS – if that's possible, let me know.
Loic [17:23]
It's a Flutter app so, yeah so that won't be difficult.
Audience member [17:34]
Can I ask a question about Flutter?
Ben [17:37]
Please do.
Audience member [17:38]
What made you choose Flutter, and what was your overall experience?
Loic [17:44]
I've liked Flutter for the past few years, and it is a very cool platform. It has one, I would say, a bit of a drawback, if you are someone who likes to work visually when designing your UI, as opposed to those who can imagine while typing what it will look like. That's a bit of a drawback, but in terms of building an app, the learning curve is not that big. It's a very interesting platform.
Michael [18:30]
Loic, in my day job, I'm busy playing with Adobe XD – it's a free tool from Adobe – and they have a Flutter output plugin, which is why I'm starting to play with it. Unfortunately, I'm not a UI guy so I still need to see how well it works with generating UI from that, but at the very least, the components look like you can export them straight through NC, might be something for you to try.
Loic [18:56]
I will take a look – Adobe XD.
Ben [19:03]
We can have more questions at the end, but just in terms of time, I think it's good to maybe move on to the next demo. Loic, thank you so much. That was an awesome demo. I'm pretty excited about that because I'm hacking it at the moment with telegram, emails, and my Wave app, but I think it'd be quite cool if we get an open-source receipt app going. That's a great start.
Loic is currently working at DVT as a Senior Software Engineer. He has been in the industry for many years and has a lot of experience both in software engineering and research. You can check out his website here.
Get involved in the Programmable Banking Community
If you’re not part of our community yet, sign up and join the fun. You can also see more of the demos from our meetups on our YouTube channel here.
For those of you in the community, check out our GitLab to see more of the awesome projects members of our community are working on. You can also sign up for challenges, where you can help find solutions for real life problems.
For more information, get in touch!