A deeper look at integrating payments
Over the past week I’ve put in quite a bit of time looking at the next step in the banking project. One of the more pressing issues I’ve been wanting to get done is real world payment integration. This post is a follow up to a previous post.
The goal
The end result I am aiming for is quite simple: to let Alice pay Bob from their mobile. Alice could also request payment from Bob, and Bob can pay Alice without having a user account on the system. Alice could also be a small merchant, where peer-to-peer payments make more sense.
There are many services that offer payments for developers. Are any of these suitable for the above use case though?
Current options
Out of companies offering developers a way to do integration, the following seem to be good options:
All of the above payment providers offer the peer-to-peer payment services we are looking for.
Merchant accounts
In order to provide peer-to-peer payments through any of the above providers (indeed, every third party provider I came across) the recipient user must be a merchant. This also requires that the user also has an account at the service provider, which by itself is not an issue as it can be done in the background (see Stripe’s managed vs standalone accounts for one example).
Each service offers different benefits around these accounts, for example some will take responsibility for fraud while others leave that in your hands.
Going direct
Both Visa and Mastercard have their own developer zones. Mastercard seems to let you develop until you need to flick the switch to production, where Visa has onerous rules even to use their sandbox.
Unfortunately, both of these payment providers require you to have one of the following:
- Have membership at the institution
- Be backed by a third party who has the required membership
- Have your own license from the payment provider
All of the above is understandable but pushes this integration out of our reach currently. To be fair, I have yet to reach out to Visa or Mastercard to find out exactly what the requirements are. Once I have their feedback I’ll be better able to gauge the situation.
Fees
It is worth mentioning that all these services charge basically the same price for transfers: 2.9% and $0.30 per transaction. Our service would have to add fees on top of that. This would reduce our competitiveness and margin, but would be an interim step before doing the payments processing ourselves.
On the fence
Stripe, WePay and Braintree all offer a close enough version of what we are looking for to create a peer-to-peer payment solution. In order to get to the ideal, we would need backing from a financial institution or get licensed ourselves as a partner with Visa or Mastercard.
With close enough integration being our current best option, I’m on the fence with next steps. The broad goal is to create banking infrastructure which involves payments between accounts (inside and outside of the banking project). The payments, since they are linked to third party accounts not the bank account in the banking project, would be unrelated to the account in our application. An example: I have a Visa card with Bank Of America, and I have an account on our banking project, The Bank Of Today(TBOT). If I transfer money from my BoA card, the balance and transfer amount are completely delinked from my TBOT account.
When you look at integrating these two elements, it starts to look a lot like a sticky-tape solution. The alternative is to have this be a separate project, built for the sake of learning about payments in an isolated fashion.
Payments project
In order to implement peer-to-peer payments in a sane fashion, the project would have to be separate from TBOT project. This new project would offer the functionality of peer-to-peer and merchant-to-peer payments. In doing research around this, this project would need to have the following:
- Mobile app
- Web app, for callbacks and account management
- HTTP API for linking to the mobile app
The above is doable but a fair amount of work in itself. The question then remains where to put the hours into: the banking project, or a new payments project.
Banking project vs standalone payments
With everything considered, especially the broad goal of building out banking infrastructure I am leaning towards leaving the payments project and keeping my focus undivided on the banking project.
This would mean that real world payments are a long way away, and the payments project’s offer of immediate real-world functionality is very tempting. At the end of the day though, it comes down to this: the banking project aims to become a payments processor. If time and effort is put into integrating a third party payments processor, it’s time and energy taken away from building our own.
Conclusion
After many hours of thought and research, I’ve broken down what it would take to build out a peer-to-peer payments solution as well as the level of integration we could offer. The end result is an attainable product which would require a separate project to build out.
I’ll continue looking into the different payment providers, but for now building out banking infrastructure is still the most attractive option. One of the parts about being full stack is doing the payments yourself - it’s more valuable to look into how to become a Stripe, WePay or Braintree, over how to integrate their services.