Design & Implementation: Subscription Payments & Account Management POC

In December 2018, Expo asked me to build subscription payments functionality using Stripe to support users of https://playcastle.io. I decided to implement a micro-service to focus on being predictable, reliable, and sustainable. I'm using Render for both server hosting and Postgres hosting. You can try Render with this invite.



I am excited to share the first iteration of the work! Let's dig in.





Requirements

The first version of this POC does not need every feature you can imagine in a payments service. That being said, certain requirements must be fulfilled.



Basics

1. Can a user update an account where the account can receive payments?

2. Can a user update an account where the account can make payments?

3. Can we keep track of account balances?

4. Can we withdraw money on behalf of the user?

5. Can we create a subscription contract between a payer and recipient?

6. Can we ensure the subscriptions are processed at the exact same time each month?

7. Can we ensure that each payer receives one and only one credit card bill during each billing cycle?

8. Can we ensure that any client with an API key can make a subscription network call?

9. Can you ensure that each payments account references one and only one user account?



Self Imposed

1. Any employee of Expo should be able to manage payments if asked to.

2. There should exist an internal tool that is a living example of how the implementation works.

3. There should be documentation.

4. There should exist an executable script that tests the entire functionality of the service and cleans up after itself.

5. Development for the service should be extremely easy and require minimal dependencies.

6. There should be a production database and test database so the team can experiment without harming customers.

7. Have a relationship with the company managing critical infrastructure. Special thanks to the folks at Render for being so helpful.



Execution

All of the requirements were fulfilled by a few tasks.



Create Clear Setup Instructions

I knew that developers wouldn't even try the code unless the steps are easy. The most junior employee should be able to use the tool. Therefore:



1. There should be minimal dependencies for the first time setup.

2. There should be minimal steps to run the code.





Even with this pre-emptive planning. Mistakes still happen, so this belief requires vigilance and you must understand you are not entitled to anyones attention.



Write Simple Documentation

I prefer documentation that is easy to copy and paste into a codebase. People want code to just work with minimal attention cost. Here is an example:





Some goals around the JavaScript:



1. Focus on the language that your team is using. Do not write examples that require understanding of a rendering library.

2. Do not assume that anyone on the team knows any complex language features.

3. Do not assume that anyone is comfortable making an npm install inside of the project they are working in.



All of the major endpoints are documented with this philosophy. Here is an overview:



POST /payers                  # list all accounts that can payPOST /payers/create           # create a new payerPOST /recipients              # list all accounts that are ready for subsPOST /recipients/create       # create a new recipientPOST /recipients/subscribe    # create/update a subscription between acctsPOST /recipients/unsubscribe  # cancel a subscription



Build an Internal Payments GUI

It is not enough for your team if the documentation fully covers the usage of your service API. Engineers should produce a living example (kitchen sink?). A living example teaches collaborators about the whole surface area of functionality. We do this because everyone should be able to help when needed.



Here is the progress on our internal tool:















Here are some more advantages to having an internal tool:



1. You know what your teammates need. If your teammate makes a request, implement the solution for everyone.

2. Each collaborator only needs to see what they need to see. Developers can dig into the source code to see how the implementation really works and everyone else can discover features through the GUI.



Setup Automated Deploys

We use Render, and when code is pushed to master the code is automatically deployed.







The team at Render was kind enough to make themselves readily available. Their team is easy to contact and discuss any concern with. They have a great sense of what developers need when it comes to server and database deployments.



Whats Next?

At Expo, our products and requirements are always evolving. There are many edge cases that need to be explored, such as:



1. Will payers want to make subscription payments to more than 20 recipients? If so will Stripe lift the limit for the number of plans in a subscription? How will we work around this if they won't?

2. Should this service bill payers on the 1st of the month? Or should this service bill payers on the 15th?

3. How does payments fit into the vision for the product? Should subscriptions only occur on the web? Should they also occur in the https://playcastle.io client? What about mobile?

4. Should any recipient of payments be able to withdraw money at their leisure? What are all of the requirements we should be aware of?

5. Should we make payers pay for the tax that the recipient would have had to pay?



Excited to work through these issues with the team! 🚀