Case Study: trf.money

Shown in GDG Jogjakarta as part of Google #DevFest day 2

Transcript

1. Muhammad Mustadi Case Study: TRF.money An exploration of implementing remittance style transfer into e-money balances.
2. CREDITS meet the team MVP @mathdroid integration @teman_bahagia UI @resir014 integration @BukanYahya integration @morpiggg
3. OVERVIEW context This project was done last December (2019). Took a weekend to develop and release the MVP. Kept being improved and maintained until Feb 2019, until some issues happened.

 In this case study we will share about how we solved some of those problem, and how we use Firebase to do it.
4. overview structure (mvp) where we come in EWALLET a (USER) EWALLET A (TRF) EWALLET B (TRF) EWALLET B (USER)
5. The problem siloed experience I just finished another app called Cashbacc (https://cashba.cc), where you can compare discount price amount for multiple ewallets. When using it, I realized that there is no easy way to move your wallet balance from each wallets. The cost of moving money between these siloes are enough deterrent. VA transfer 1k Withdraw ~5k
6. Constraints stuff that make it interesting no official APIs The Platforms have no (publicly) official developer APIs yet. We have to use a combination of reverse engineering, Man-in-the-Middle snooping, and other creative ways to legally operate, and automate, our accounts. maximum floating value each ewallets has to comply by gov’s regulations. That is, any unverified accounts can only some small amount of IDR, and verified accounts can hold up to 2M. This limits our availability and size of transactions. different protection of user data Some ewallets send full info of a sender’s data. In this case we are using phone numbers as identifier. But some other wallets do not send info at all, or redacted some of the information. Muhammad Mustadi -> M******* ******i suspicious activity detection Excessive inbound and outbound transactions may alert the platform’s security system, which may think it’s a money laundering scheme, hacking attempts, or combination of other things.
7. Tradeoffs here are the things we considered — remittance - handle errors/detection by ourselves - still centralized (single point of failure) - need to identify which tx’s are valid and not (magic numbers) pure p2p/matchmaker - needs volume - no way for users to refund
8. Tech Stack Things we used to build React + Next.js Easy dev experience, paired with chakra-ui for even better DX Firebase was used due to its easy integration with React projects. Also we need the onCreate user hook which is achievable with . We use to store the relation between each mobile number and the metadata from all the providers, and other stuff Firebase Authentication Firebase Functions Firebase Cloud Firestore Vercel Easy integration with github (new build for every PR) and natural habitat for Next.js projects Heroku For queue runners (we use bullmq) to check balances, inbound and outbound transactions.
9. solutions here’s what really happened We created a way to move (transmute) people’s e-wallet balance via remittance. users ~ 300 users on launch week ~800 transmuters lifetime 100% positive feedback transmutes [REDACTED] Million IDR worth of transmutes
10. the challenges not everything went as planned Go-Jek banned the main account’s P2P feature We’re halting operations for now. We considered using other account, which will only delay until this happens again. Or we tried to do something creative with the way we can withdraw periodically in batches and send the money via VA. But it will increase the cost. We are still in talk about this. General confusion about the scheme We had a lot of people trying to send the money to other recipients, which is not allowed under current assumptions. The same with people who use different mobile numbers to use with different services.
11. process recap MVP Launch Day New team Blocked Next 2 days 2 days 1 day 300 users 2 months ~800 users Full P2P?
 OSS?
 We want your input!
12. Epilogue thank you! twitter/github @mathdroid