When I joined Roblox 5 years ago, we were not the payments platform that could power an annual economy of $1.9 billion in bookings (as of 12/31/2020), using 11 payment partners with 59 different currencies across 99 supported countries. I’ll tell you how we got here, and how building a generic payment platform upfront enabled us to ramp up as quickly as our business. Payments are often overlooked as a source of innovation and impact. But building your payments platform the right way up front can open up new opportunities, allow for innovation and optimization, and create a competitive advantage for your company.
First, what is a “generic payment platform?” I am using this phrase as a wrapper for any gateway or processor that facilitates the receipt of payments from customers. I’ll be referring to the third parties that do the payment orchestration as payment providers or gateways. A generic payment platform opens up centralized logging, fraud, metrics, security, and swapability of payment providers. A generic payment platform enables you to AB-test providers that may have better credit card completion rates in particular geographies or fraud rates in certain areas. It also allows for automatic fallback if a provider goes down, which happens more than any of us would like.
You are bound to change payment providers, especially credit card providers, down the road. If you believe your company will be successful, the rates you’ll get as a five-person garage shop vs. a global ecommerce platform are widely different. Also, the provider you chose early on may not fit your needs as you grow — some of the most popular providers have limited international penetration. There are many reasons to switch providers and tying yourself to one may mean you are hurting your bottom line with every purchase.
Roblox uses a wide range of payment providers, and has also discontinued working with just as many. We currently have desktop providers, prepaid card providers, and app store providers. We have parted ways with at least 4 payment providers since I’ve joined Roblox.
I am going to draw a high-level architecture of what I mean by plug and play payment providers. Roblox is on a microservice architecture, but if you’re just starting out, you probably shouldn’t be. The logic below can be either a service or just separated at the application layer.
Notice how payment processing is just one step in the overall flow of the payment. Starting out with one provider is the right call, but be sure to think about what would happen if you decided to add a second. Would it be easy to update the routing logic or would it be another project with a lot of refactors? The encapsulation early on will also help with thinking about security and PCI Compliance.
I won’t go into many details of how we lay out our data, because it may not fit your use case, but at a high level, I want to emphasize that the payment processing step should be a step that can easily be replaced and changed. Do not tie your data stores to the payment processor’s data layouts. I would even suggest looking at different providers and how they handle the concepts of auth, capture, and subscriptions, and decide on a generic data store with all payment provider-specific logic encapsulated in a completely separate table.
Data will most likely be most difficult for you to update later. Think about what you’ll need from persistent vs. not-persistent data, and how long you will need this data stored. I would strongly recommend structuring the data to allow for later integrations with a subscription product. Even though you may not be thinking about subscriptions now, if your business even has a chance to move down that road, plan the data stores to accomodate for that. I won’t go into all the benefits of a subscription-based monetization strategy (there are a lot of resources online for that), but predictable revenue allows for you to plan further ahead for your company.
Subscriptions are another area that will benefit from generalizing away from payment provider-specific logic. The subscription architecture for payment providers is vastly different. Most one-time payment purchases follow the same model of “charge the user now.” For subscriptions, however, a couple different models exist:
Make sure that all your subscriptions come through one central data pipeline with generic renewals, cancellations, and (most importantly) grace periods. Some modals like the pull modal will allow a subscription to stay active unless you hear back from the provider. If your service goes down or has continuous timeouts you will be stuck providing a product without actually charging the user. This may be okay depending on what subscription offering you have, but our virtual currency has an intrinsic value so we need to be extra careful on subscription renewals and cancellations.
I hope I was able to convince you of going the generic route from your early implementation of your payment gateways. I won’t suggest what payment provider you should implement, but hopefully you see that your choice of payment provider isn’t the most important decision. The most important decision is how to architect your system in the right way to have the option to easily replace your payment provider in the future.
— — —
Dmitri Essiounine is a Senior Engineering Manager at Roblox. His teams are responsible for supporting a thriving economy in the Roblox Metaverse.
Neither Roblox Corporation nor this blog endorses or supports any company or service. Also, no guarantees or promises are made regarding the accuracy, reliability or completeness of the information contained in this blog.
©2021 Roblox Corporation. Roblox, the Roblox logo and Powering Imagination are among our registered and unregistered trademarks in the U.S. and other countries.