By Adebayo Opesanya
- Basic monetary units will disgrace you
For amounts and stuff like balances, always work with cent values of currencies and not basic monetary units for API input, response, computation and storage i.e work with Kobo instead of Naira, or Cents instead of Dollars. Research and experience have showed me that 99.95764873526% of human beings don't play with their money (yes, I've had a customer cause a scene over 0.01 Naira). This will help greatly with precision issues (now look at 99.95764873526 again and imagine it was someone's balance).
- Something on number types
As an extension of point 1, please make sure amount and balance field inputs to your API are integers, and make sure they are saved as Decimal (or Numeric if you're working with MySQL or PostgreSQL) types.
- Of course, validate input 🤷🏽♀️
Yeah, this is because I don't think you want people sending negative amounts to your API. First, you could be a victim of integer overflow. Second, imagine debiting someone a negative amount and crediting someone else that negative amount. Think about that 🤔
- Use Database Transactions
In many cases, instead of performing related transactions as separate database operations, it is better to do all the related transactions in a database transaction. An example is a system where P2P transfers can be done. Instead of debiting A's account and crediting B's account as separate database writes, do the debit and credit in a database transaction. This is important because you want to make sure that if one or more of those operations fails, everything fails. It messes up your records when one part is successful, but the other part fails.
- References are everything
Honestly, I can't stress this enough. Transaction references are essential for customer service, debugging, reconciliation, e.t.c. Make sure these references are unique, and are stored against important details of a transaction. e.g IDs of the parties involved, amount, balances of the parties involved before/after the transaction, e.t.c.
- Expect the weirdest of things from third party APIs
This could be a blog post on it's own, but I've seen things! Expect the worst of things to happen when it comes to interacting with 3rd party APIs. I've had a third party send balance as a negative number when I queried the balance on a card. Another time, a third party sent as "2,000,000.00" (yes, that string) as the value of an amount field.
- Your automated tests should be as close to real-life scenarios as possible
As an extension of point 6, your automated tests are most useful when they mirror all possible possibilities in real-life scenarios. If you're mocking API and function responses, mock every scenario, not just scenarios where everything happens normally. Anticipate scenarios such as API timeouts to third party services, inconsistent API responses from third party services, and other edge cases that you can think of.
- Log as much (insensitive) information as possible.
- You definitely need audit trails.
- Be careful with retries
Personally, except unavoidable, I run from retrying operations that impact accounts. You just really need to be careful. Things can go south pretty quickly.
This list may grow with time, but these are the things that have stood out the most to me in my experience. What do you think? Are there others? Let me know. You can find me on Twitter or LinkedIn