<story><title>Pains of building your own billing system</title><url>https://arnon.dk/the-14-pains-of-billing/</url></story><parent_chain><item><author>jchw</author><text>This is a great article for people who are in the situation where they have to make decisions about billing and don&amp;#x27;t have much experience (and as a handy reference for those who do, but want some reminders, too.)&lt;p&gt;However, I will admit, I had a hearty chuckle at this line:&lt;p&gt;&amp;gt; &amp;quot;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?&amp;quot;&lt;p&gt;Under no circumstances does my engineer brain think this is a good idea. At all.&lt;p&gt;But, I will dump one aspect of my engineer-brain thoughts: My favorite &amp;quot;billing architecture&amp;quot; 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) &lt;i&gt;and&lt;/i&gt; something like a Stripe integration &lt;i&gt;very&lt;/i&gt; easy. You should, of course, be &lt;i&gt;very&lt;/i&gt; careful to leave it open for extension in the future, but this seems to be a very nice decision that doesn&amp;#x27;t, in itself, limit you too much.&lt;p&gt;Obviously, this is not my original idea, but it&amp;#x27;s still something I&amp;#x27;ve grown to like a lot, especially after having tried other things less successfully.</text></item></parent_chain><comment><author>ylere</author><text>My experience has been that there are typically two types of engineers: those who have worked on billing systems before and those who haven&amp;#x27;t.&lt;p&gt;I think a lot of the issues arise from the difference between payments and billing [0]. When just starting out and signing up your first customers, you primarily care about collecting a few (recurring) payments - and it&amp;#x27;s really easy to set that up with Stripe (or even just manually invoicing your first customers).&lt;p&gt;However, over time, more billing requirements gradually sneak in, such as more complex entitlements, multiple plans, grandfathering, and eventually enterprise&amp;#x2F;high touch sales customers (where the money is!) who need custom billing cycles, terms, and entitlement provisioning. Since billing is never a technical focus, numerous additions and small hacks accumulate over time, taking engineering resources away from the actual product. Eventually, this turns into an unmanageable mess that can significantly slow down the sales process or limit what you can sell.&lt;p&gt;The complexity of billing is riddled with hidden pitfalls and edge cases, and it has become even more complex now that most plans include many different limits and usage-based components and that most SaaS companies sell globally. Many later-stage companies have teams of 15+ engineers working solely on billing. I fully agree with the author that, unless it&amp;#x27;s at the core of your product, no organization should build a billing system themselves (Disclaimer: I&amp;#x27;m the CTO of Wingback, a SaaS Billing Platform).&lt;p&gt;[0] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.wingback.com&amp;#x2F;blog&amp;#x2F;saas-payment-vs-saas-billing&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.wingback.com&amp;#x2F;blog&amp;#x2F;saas-payment-vs-saas-billing&lt;/a&gt;</text></comment>
<story><title>Pains of building your own billing system</title><url>https://arnon.dk/the-14-pains-of-billing/</url></story><parent_chain><item><author>jchw</author><text>This is a great article for people who are in the situation where they have to make decisions about billing and don&amp;#x27;t have much experience (and as a handy reference for those who do, but want some reminders, too.)&lt;p&gt;However, I will admit, I had a hearty chuckle at this line:&lt;p&gt;&amp;gt; &amp;quot;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?&amp;quot;&lt;p&gt;Under no circumstances does my engineer brain think this is a good idea. At all.&lt;p&gt;But, I will dump one aspect of my engineer-brain thoughts: My favorite &amp;quot;billing architecture&amp;quot; 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) &lt;i&gt;and&lt;/i&gt; something like a Stripe integration &lt;i&gt;very&lt;/i&gt; easy. You should, of course, be &lt;i&gt;very&lt;/i&gt; careful to leave it open for extension in the future, but this seems to be a very nice decision that doesn&amp;#x27;t, in itself, limit you too much.&lt;p&gt;Obviously, this is not my original idea, but it&amp;#x27;s still something I&amp;#x27;ve grown to like a lot, especially after having tried other things less successfully.</text></item></parent_chain><comment><author>spiffytech</author><text>Another great article from Arnon on doing exactly that:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;arnon.dk&amp;#x2F;why-you-should-separate-your-billing-from-entitlement&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;arnon.dk&amp;#x2F;why-you-should-separate-your-billing-from-e...&lt;/a&gt;</text></comment>