When building a Dwolla platform application it’s important to understand the Customer Types you can use. These are building blocks for your funds flows and the right end user experience. There are 3 Customer Types to understand. They are outlined on the Dwolla developer website but lately I find myself drawing them on a whiteboard frequently.
These building blocks are all Customer Types. They belong to the end users of the application a client builds. A Customer Type is a type of Customer Record.
There are 3 you need to know as you think about your building blocks.
- RO – Receive Only
- uCR – Unverified Customer Record
- VCR – Verified Customer Record
The documentation also mentions a Dwollabalance, which is a wallet on the VCR Record. The Master Balance isn't mentioned but it's essentially the Dwollabalanceassociated with the Client Account. The Master Balance is an important building block as well. We'll get more into that later but for the sake of separating the building blocks, the Master Balance is owned by the clients account, referenced as the Master Account in the docs. Customer Records defined by Customer Types are separate from the Master Balance and Client Account. When I think about these in my head. It looks like this :)
The Client Account (which owns the Dwolla Master Account) is the company who owns the actual account on the Dwolla platform. If you log in at Dwolla.com and manage customers, transactions, and other things you have a client account by default. The Client account has all kinds of cool features (50+ of them!) that an be enabled to help your company scale.
Customer Types and the associated money movement
- ROs can only receive money from a VCR or a Master Balance.
- uCRs can send or receive money to a VCR or a Master Balance.
- VCRs can exchange funds between themselves or any other account type including… You guessed it! The Master Balance.
Each Customer Type has a funding source attached. Depending on the Customer Type there might be automation you can assume will occur.
For example, when using a RO record anytime funds are sent to it those funds will automatically just show up in the bank account that is attached as the funding source. Using a uCR record, multiple funding sources might be used depending on the settings with the application. Using a VCR or Master Balance, there is the added capability of a balance which can store funds.
Now that I’ve mentioned the Client Account which owns the Master Balance a few times let’s separate out these out.
A Client account is the owned by the company who holds the contract with Dwolla and is operating the software end users, who end up with Customer Records. The Client account is not a CustomerType but it can interact with them.
Customer Accounts can exchange money between one another, and also with the Client Account.
If you start thinking about how money can technically move between the Client Account and Customer Types you can see how it gets complex even with a smaller number of accounts.
It’s possible to move money with instructions alone
A powerful element of building with the Dwolla platform is the ability for money to move between client accounts without it going to the Client Account, or master balance.
All of the funds flows are initiated through the Client Account master API credentials based on usage in the Client application. The Client application could be a mobile app, web app, or any app that’s able to connect to our API.
Using the Dwolla platform it’s possible to build an application that has incredibly complex funds flows where the application owner doesn’t touch the money, just enables the movement of it based on end user instruction.
Leveraging the API to send instructions
In the Dwolla platform the Client Account owns a set of API credentials which allow it to interact with Customer Records on behalf of the end user.
In some software the developer who owns the Client Account wants to enable commerce between end users but doesn’t actually want to be in the funds flow. In other cases, the Client Account might be owed by a business who wants to be in the funds flow.
For example, a marketplace is probably paying from a Master Balance to RO records that represent their sellers. If it’s a 2 sided B2B marketplace, they might be collecting funds from a uCR belonging to business buyers and paying out to uCRs belonging to the business sellers.
Many different entities can have accounts
VCR accounts are incredibly flexible. They can be owned or opened by any entity that can effectively own money through Client Applications. A person, company, government, bank, or credit unions can all own accounts.
The financial institution (bank or credit union) part of that is something we’ve found to be really special over the years because while the end users of many client applications are people and businesses, there are a great number of financial institutions that enable unique funds flows or products. The FI might be a part of the funds flow but may be more abstracted from the end user experience.
The other Customer Types are flexible too
The ownership variety is diverse with all Customer Types. Anyone can own a uCR, RO, VCR assuming the account and identity is real. There is plenty of compliance that happens behind the scenes to help our clients scale but that is a subject for another day.
Dwolla is really fortunate. We’ve built what I’m fairly sure is the most robust bank transfer technology ever built and what you can do with it is really a function of your imagination. This could get a lot longer if we began to unpack reconciliation, reporting, webhooks, automation, and the rest of the stack but for today I’m going to stop here. Understanding the Dwolla CustomerType account structure as building blocks is a great first step in building powerful software with them.
How many VCR accounts can you create?
There is no limit on the number of VCRs you can create.