Redefining Melio’s Entity Model
What Does an Entity Model Stand for?
The first thing that comes to mind when trying to explain what that means may be a database table. While that is technically correct, a model stands for much more.
The model is used as the company’s business domain language which is used to communicate within and between teams.
It defines the business capabilities and constraints and is the toolset available for solving new problems.
The model is, in fact, the core of the business.
Melio’s Platform in a Nutshell
Melio’s platform helps small businesses pay suppliers, but unlike other money transfer services such as Stripe or Venmo, Melio is an open network. Payors can pay their bills without payees knowing it was done using Melio.
Our customers love this model because it enables them to send and receive money through their preferred payment method without worrying about the preferences of the other party.
Payors can pay whichever way they like (via ACH, credit card, etc.), and payees can receive the funds however they choose (via check, ACH, wire, single-use card, etc.).
ACH transfer is the electronic movement of money between banks through the Automated Clearing House network. Or in short, a bank transfer.
Some suppliers, for example, prefer receiving funds via paper checks, yet their business clients prefer to pay using a more sophisticated method like a card
The Payment Model
Our payment model is a one-to-one representation of the above core business flow.
It contains the amount, debit and credit dates, the bank through which to perform the transactions, and the accounts to perform transactions (see image below).
In this case, ”bank” refers to an FBO (for the benefit of). It is a pooled account that allows Melio to manage funds on behalf of our users without assuming legal ownership of that account.
The payment is processed twice. First, when funds are debited from the payor’s account, and the second time when funds are credited to the payee’s account. Between debit and credit, the funds are stored in one of Melio’s bank accounts, which makes it possible for a payment to be debited using one payment method and credited using another.
Model Constraints: Not That Trivial After All
There is a special type of feeling when you know you grow out of a model. It’s similar to a code smell but is more painful.
A partner we use for payment dispatching required us to credit their account before crediting the payee account, meaning
- Debit the payor.
- Credit the third-party account.
- Credit the payee account.
(three steps instead of the standard two).
This means that while we could previously process the payment twice, once for debit and once for credit, we now have to process it three times!
As if that wasn’t complicated enough, the new step of transferring funds between internal accounts affects the payment processing time but is not visible to our users. Users are only exposed to transactions in their own accounts.
The Transfer Model
While this pain was real, we didn’t want a tailor-made solution for this specific case. Instead, we built an adaptive solution that empowers Melio to innovate further on its payment flows.
Slowly, we began to realize we need to create a new transfer model, which we dubbed the “N transfer model”.
The new transfer model represents a single transaction between two accounts and contains all the necessary information. One payment in the old model will now be associated with N transfers in the new model.
Instead of processing a payment twice, we process transfers. Before this shift, a payment could only be associated with two transfers, but now we could easily associate it with more.
Once all transfers are done we mark the payment as completed.
Our payments processing service had to be refactored into a “transfer processor;” this was not an easy task.
A Story Of Success
It feels good when new product ideas come knocking at your door and fit your model like a glove. This happened thanks to the changes we made in the transfer model.
Switching Payment Method
With the N transfer model, we can now support switching delivery methods even after the payment is initiated.
Users use this functionality when they need the funds sooner (receiving funds via card is much faster than a paper check delivered in the mail). We do this by letting two debit transfers race against each other, the first one that is completed, cancels out the other one.
- First transfer debits payor.
- Second transfer credits payee’s paper check account.
- Payee requests a switch to card, third transfer created crediting payee’s card account.
- Card transaction success, second transfer canceled (voided in the case of paper check).
We Now Also Have the Capability to Support Third-Party Financing
A financing provider would provide funds in place of the payor, and, 60 days later, the payor would pay them back. This could be done on our system using four transfers.
- The first transfer debits the financing provider.
- The second credits the payee.
- The third happens 60 days later and debits the payor.
- Then, finally, the fourth transfer credits the financing provider.
As you can see it opens a 🌍 of possibilities 🤓
Please Don’t Break the Business
The core model reaches beyond the technical domain. Finance still needs to reconcile payments, Risk still has to evaluate each payment, and Customer Support continues to provide users with payment information and adjustments.
Mitigation and backward compatibility is something we cannot neglect. Melio processes a volume of billions of dollars a year (and growing). This change can not affect day-to-day processing or other teams’ work.
In order to give other teams within Melio the time to adjust and to make the transition smoother, we continued to update legacy payment properties other teams are using, such as accounts.
Although most internal consumers are only aware of the old payment model, we are actually processing transfers, storing them in a new database, and referencing and updating payments. For consumers, a payment simply represents funds movement from a payor’s to a payee’s account, while, behind the scenes, the payment can hide N transfer flows.
Accessibility and Visualization
One of the hardest parts of nailing changes is making sure everyone involved understands the original pain, the solution model, and the business flow.
The hard work of properly sharing knowledge returns the investment multiplied by the number of people it is shared with. No one could implement such a huge change by themselves, and even if they did it wouldn’t be effective since other people would still use the model in a different way than originally intended.
Some of the knowledge sharing tools we use:
- Flow diagrams (we use Miro https://miro.com)
- Database model visualization (https://dbdiagram.io)
- A Google Doc with a verbal description of each model’s purpose shared with anyone involved (not only technical people). It’s always surprising how some “obvious” models’ purposes are not so obvious as they may seem when put in writing.
- Multiple hands-on sessions with as many people as possible using the above-mentioned tools (separate meetings). Everyone has an opinion and, in this case, that’s a good thing. However, all of these thoughts and ideas need to be organized together.
Hope you had a good read, if you like these kinds of challenges, come work with us at Melio! https://www.meliopayments.com/careers
