This is a great article for people who are in the situation where they have to make decisions about billing and don't have much experience (and as a handy reference for those who do, but want some reminders, too.)
However, I will admit, I had a hearty chuckle at this line:
> "why can’t we just dump a file of what we need to bill on S3, and have a CRON job pick it up and collect payment?"
Under no circumstances does my engineer brain think this is a good idea. At all.
But, I will dump one aspect of my engineer-brain thoughts: My favorite "billing architecture" decision is to try to decouple billing as much as possible from credit in a system. For example, if you have a subscription system where the user pays ahead for a given billing period, I prefer to have the entitlement itself just store the expiration date and the details about what entitlements the subscription grants during the time period it is active. The billing system can store the subscription and sync back to the entitlement as-needed. This makes both manual billing by human operators (not to mention debugging and patching around momentary issues) and something like a Stripe integration very easy. You should, of course, be very careful to leave it open for extension in the future, but this seems to be a very nice decision that doesn't, in itself, limit you too much.
Obviously, this is not my original idea, but it's still something I've grown to like a lot, especially after having tried other things less successfully.
However, I will admit, I had a hearty chuckle at this line:
> "why can’t we just dump a file of what we need to bill on S3, and have a CRON job pick it up and collect payment?"
Under no circumstances does my engineer brain think this is a good idea. At all.
But, I will dump one aspect of my engineer-brain thoughts: My favorite "billing architecture" decision is to try to decouple billing as much as possible from credit in a system. For example, if you have a subscription system where the user pays ahead for a given billing period, I prefer to have the entitlement itself just store the expiration date and the details about what entitlements the subscription grants during the time period it is active. The billing system can store the subscription and sync back to the entitlement as-needed. This makes both manual billing by human operators (not to mention debugging and patching around momentary issues) and something like a Stripe integration very easy. You should, of course, be very careful to leave it open for extension in the future, but this seems to be a very nice decision that doesn't, in itself, limit you too much.
Obviously, this is not my original idea, but it's still something I've grown to like a lot, especially after having tried other things less successfully.