[{"data":1,"prerenderedAt":37},["ShallowReactive",2],{"blog-post-build-vs-buy-for-billing":3},{"slug":4,"title":5,"description":6,"date":7,"updated":8,"tags":9,"pillar":13,"draft":14,"image":15,"imageAlt":16,"html":17,"markdown":18,"faq":19,"readingTimeText":35,"readingTimeMinutes":36},"build-vs-buy-for-billing","Build vs buy for billing: when Stripe is enough","For most early products a hosted processor is enough. It stops being enough at four moments: global tax, usage-based pricing, marketplaces, and provider limits. Here is which layer to own.","2026-05-06T00:00:00.000Z",null,[10,11,12,13],"billing","build-vs-buy","merchant-of-record","founder-engineering",false,"/blog-covers/founder-engineering.png","Founder engineering cover","\u003Cdiv class=\"post-tldr\">\u003Cdiv class=\"post-tldr-label\">TL;DR\u003C/div>\u003Cp>Buy a hosted processor like Stripe by default and own only the logic that is truly yours, usually metering and rating. The four moments to watch: global tax, usage-based pricing, becoming a marketplace, and hitting provider limits.\u003C/p>\u003C/div>\n\u003Cp>For almost every early product, a hosted processor like Stripe is enough, and building your own billing engine is a mistake you pay for twice. Buy first. What matters is knowing the specific moments a hosted processor quietly stops being enough, because they are predictable, and hitting one unprepared turns a planned migration into a scramble. The four that actually force the question: global tax, usage-based pricing, becoming a marketplace middleman, and the provider’s own limits colliding with your product.\u003C/p>\n\u003Cp>I have built billing on top of hosted processors and I have built the layers they do not give you. The instinct to build early is almost always ego or a bad estimate. The instinct to keep buying forever is how you end up owing back taxes in a country you forgot you sold into. Both are avoidable if you know where the line is.\u003C/p>\n\u003Ch2 id=\"what-%E2%80%9Cbuy%E2%80%9D-actually-gets-you\" tabindex=\"-1\">What “buy” actually gets you\u003C/h2>\n\u003Cp>A payment service provider (Stripe, Braintree) handles the card network, PCI scope, storage of card data, retries, and a decent subscription model. That is a lot of genuinely hard, boring, regulated work you should not want to own. For a product with one or two plans, monthly and annual, in one or two countries, a hosted processor plus webhooks plus the \u003Ca href=\"/blog/three-questions-before-i-write-billing-code\">three habits I never skip\u003C/a> (source of truth, idempotency, audit log) is a complete billing system. Building your own here buys you nothing but PCI liability and a worse retry engine. The scarce resource at that stage is not a billing engine, it is \u003Ca href=\"/blog/the-first-hire-who-touches-your-billing-should-be-boring\">an engineer who treats that code as boring on purpose\u003C/a>.\u003C/p>\n\u003Cp>So the default is buy. The interesting question is the exits.\u003C/p>\n\u003Ch2 id=\"quiet-failure-one%3A-you-owe-tax-everywhere\" tabindex=\"-1\">Quiet failure one: you owe tax everywhere\u003C/h2>\n\u003Cp>The moment you sell to customers in many countries, you inherit tax obligations you probably did not model. VAT in the EU, GST elsewhere, US sales tax that now applies to software in a growing list of states. A plain PSP like Stripe processes the payment but does not become the seller of record. You are the seller, which means you are the one who owes the filings.\u003C/p>\n\u003Cp>This is where a merchant of record changes the math. A merchant of record (Paddle, Lemon Squeezy, and similar) is legally the seller. They collect and remit the tax, they take on the compliance, and you get one payout and one relationship instead of forty tax registrations. The tradeoff is a higher cut and less control over the checkout and the customer data. For a small team selling globally, that cut is usually cheaper than a part-time finance hire plus the risk of getting remittance wrong.\u003C/p>\n\u003Cp>The trap is discovering this after you have crossed a threshold. Tax obligations do not wait for you to notice them.\u003C/p>\n\u003Ch2 id=\"quiet-failure-two%3A-your-pricing-outgrows-flat-plans\" tabindex=\"-1\">Quiet failure two: your pricing outgrows flat plans\u003C/h2>\n\u003Cp>Hosted subscription billing is excellent at “twenty nine dollars a month”. It gets awkward fast when pricing becomes usage-based, seat-based with \u003Ca href=\"/blog/subscriptions-are-licensing-that-bills-on-time\">proration mid cycle\u003C/a>, or a hybrid of a base fee plus metered overage. You can bend a PSP’s metered billing to do a lot, but at some point you are metering, aggregating, and rating usage in your own system and only using the provider to move the money.\u003C/p>\n\u003Cp>That is the signal that you are already building billing, whether you admit it or not. The question stops being build vs buy and becomes which layer you own. Usually the right split is: you own metering and rating (because it is your product’s logic and nobody else can do it), and you keep buying the payment rails, tax, and card handling. Owning the whole stack including the card vault is almost never worth it.\u003C/p>\n\u003Ch2 id=\"quiet-failure-three%3A-you-become-the-middleman\" tabindex=\"-1\">Quiet failure three: you become the middleman\u003C/h2>\n\u003Cp>The day you pay out to third parties (a marketplace, a platform where creators or vendors get a share) your billing problem changes shape. Now you have split payments, payout schedules, onboarding and identity verification for the people you pay, and a reconciliation problem in two directions. This is genuinely hard, and it is also exactly where the providers have built products (Stripe Connect and its equivalents). Buy that too. Writing your own payout and KYC layer is a way to spend a year building a worse version of a regulated product.\u003C/p>\n\u003Ch2 id=\"quiet-failure-four%3A-the-provider%E2%80%99s-limits-become-your-product%E2%80%99s-limits\" tabindex=\"-1\">Quiet failure four: the provider’s limits become your product’s limits\u003C/h2>\n\u003Cp>Sometimes the thing that forces a change is not scale, it is fit. The provider does not support a currency you need, a payment method your market actually uses, a dunning flow your customers expect, or a data residency requirement a large customer demands. When the processor starts dictating what your product can do, you either add a second processor and route between them, or you build an abstraction so the processor becomes swappable.\u003C/p>\n\u003Cp>That abstraction is the one piece of “build” I recommend early, and it is cheap: do not let the vendor’s SDK types leak into your domain. Wrap it.\u003C/p>\n\u003Cpre class=\"shiki shiki-themes github-light github-dark\" style=\"background-color:#fff;--shiki-dark-bg:#24292e;color:#24292e;--shiki-dark:#e1e4e8\" tabindex=\"0\">\u003Ccode>\u003Cspan class=\"line\">\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">interface\u003C/span>\u003Cspan style=\"color:#6F42C1;--shiki-dark:#B392F0\"> PaymentGateway\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\">{\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">    public\u003C/span>\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\"> function\u003C/span>\u003Cspan style=\"color:#6F42C1;--shiki-dark:#B392F0\"> charge\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\">(\u003C/span>\u003Cspan style=\"color:#005CC5;--shiki-dark:#79B8FF\">Money\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\"> $amount, \u003C/span>\u003Cspan style=\"color:#005CC5;--shiki-dark:#79B8FF\">Customer\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\"> $customer, \u003C/span>\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">string\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\"> $idempotencyKey)\u003C/span>\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">:\u003C/span>\u003Cspan style=\"color:#005CC5;--shiki-dark:#79B8FF\"> ChargeResult\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\">;\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">    public\u003C/span>\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\"> function\u003C/span>\u003Cspan style=\"color:#6F42C1;--shiki-dark:#B392F0\"> refund\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\">(\u003C/span>\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">string\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\"> $chargeId, \u003C/span>\u003Cspan style=\"color:#005CC5;--shiki-dark:#79B8FF\">Money\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\"> $amount)\u003C/span>\u003Cspan style=\"color:#D73A49;--shiki-dark:#F97583\">:\u003C/span>\u003Cspan style=\"color:#005CC5;--shiki-dark:#79B8FF\"> RefundResult\u003C/span>\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\">;\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#24292E;--shiki-dark:#E1E4E8\">}\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003C/span>\u003C/code>\u003C/pre>\n\u003Cp>You are not building a billing engine here. You are making sure that the day a second processor becomes necessary, it is a new implementation of an interface and not a rewrite of half your app. This costs a day now and saves a quarter later.\u003C/p>\n\u003Ch2 id=\"how-to-actually-decide\" tabindex=\"-1\">How to actually decide\u003C/h2>\n\u003Cp>Run the decision against these, in order:\u003C/p>\n\u003Col>\n\u003Cli>One or two plans, one or two countries, cards only. Buy a PSP. Do not build. Do wrap it behind an interface.\u003C/li>\n\u003Cli>Selling globally, tax is now your problem. Strongly consider a merchant of record before you build a tax engine.\u003C/li>\n\u003Cli>Pricing is usage-based or hybrid. Own the metering and rating. Keep buying the rails.\u003C/li>\n\u003Cli>You pay out to third parties. Buy the marketplace product. Do not build KYC and payouts yourself.\u003C/li>\n\u003Cli>The provider cannot do something core to your product. Add a second processor behind your interface. Do not rewrite.\u003C/li>\n\u003C/ol>\n\u003Cp>Notice that “build the whole thing” never appears. In every early-stage team I have worked with, I have not met one that was right to build the card handling layer from scratch. The real skill is not building or buying. It is knowing which layer to own and buying everything under it, so that when you hit one of these quiet failures, you are extending a system instead of replacing one while customers are trying to pay you.\u003C/p>\n\u003Cdiv class=\"post-takeaway\">\u003Cdiv class=\"post-takeaway-label\">The takeaway\u003C/div>\u003Cp>Buy the boring, regulated layers and own only the logic that is genuinely yours. The four quiet failures (global tax, usage-based pricing, becoming a marketplace, and provider limits) are predictable, so treat them as planned exits rather than emergencies. Do that, plus wrap your processor behind an interface on day one, and every one of these transitions becomes extending a system instead of replacing one while customers are trying to pay you.\u003C/p>\u003C/div>\u003Ch2 id=\"faq\" tabindex=\"-1\">FAQ\u003C/h2>\n\u003Cdiv class=\"post-faq\">\u003Cdiv class=\"faq-item\">\u003Cdiv class=\"faq-q\">When is Stripe genuinely enough?\u003C/div>\u003Cdiv class=\"faq-a\">\u003Cp>When you have one or two plans, monthly and annual, in one or two countries, cards only. A hosted processor plus webhooks plus source of truth, idempotency, and an audit log is a complete billing system at that stage.\u003C/p>\u003C/div>\u003C/div>\u003Cdiv class=\"faq-item\">\u003Cdiv class=\"faq-q\">What is the difference between a payment service provider and a merchant of record?\u003C/div>\u003Cdiv class=\"faq-a\">\u003Cp>A PSP like Stripe processes the payment but leaves you as the seller of record who owes the tax filings. A merchant of record like Paddle or Lemon Squeezy is legally the seller, so they collect and remit tax in exchange for a higher cut and less control.\u003C/p>\u003C/div>\u003C/div>\u003Cdiv class=\"faq-item\">\u003Cdiv class=\"faq-q\">Should I ever build my own card handling?\u003C/div>\u003Cdiv class=\"faq-a\">\u003Cp>Almost never. It buys you PCI liability and a worse retry engine, and “build the whole thing” does not appear anywhere in a sane decision path.\u003C/p>\u003C/div>\u003C/div>\u003Cdiv class=\"faq-item\">\u003Cdiv class=\"faq-q\">What is the one piece of build worth doing early?\u003C/div>\u003Cdiv class=\"faq-a\">\u003Cp>Wrap the provider behind your own payment interface so its SDK types do not leak into your domain. It costs about a day and saves a quarter when a second processor becomes necessary.\u003C/p>\u003C/div>\u003C/div>\u003Cdiv class=\"faq-item\">\u003Cdiv class=\"faq-q\">How do I know I am already building billing without admitting it?\u003C/div>\u003Cdiv class=\"faq-a\">\u003Cp>When you are metering, aggregating, and rating usage in your own system and only using the provider to move the money. At that point the question is which layer you own, not build vs buy.\u003C/p>\u003C/div>\u003C/div>\u003C/div>","\n## TL;DR\n\nBuy a hosted processor like Stripe by default and own only the logic that is truly yours, usually metering and rating. The four moments to watch: global tax, usage-based pricing, becoming a marketplace, and hitting provider limits.\n\nFor almost every early product, a hosted processor like Stripe is enough, and building your own billing engine is a mistake you pay for twice. Buy first. What matters is knowing the specific moments a hosted processor quietly stops being enough, because they are predictable, and hitting one unprepared turns a planned migration into a scramble. The four that actually force the question: global tax, usage-based pricing, becoming a marketplace middleman, and the provider's own limits colliding with your product.\n\nI have built billing on top of hosted processors and I have built the layers they do not give you. The instinct to build early is almost always ego or a bad estimate. The instinct to keep buying forever is how you end up owing back taxes in a country you forgot you sold into. Both are avoidable if you know where the line is.\n\n## What \"buy\" actually gets you\n\nA payment service provider (Stripe, Braintree) handles the card network, PCI scope, storage of card data, retries, and a decent subscription model. That is a lot of genuinely hard, boring, regulated work you should not want to own. For a product with one or two plans, monthly and annual, in one or two countries, a hosted processor plus webhooks plus the [three habits I never skip](/blog/three-questions-before-i-write-billing-code) (source of truth, idempotency, audit log) is a complete billing system. Building your own here buys you nothing but PCI liability and a worse retry engine. The scarce resource at that stage is not a billing engine, it is [an engineer who treats that code as boring on purpose](/blog/the-first-hire-who-touches-your-billing-should-be-boring).\n\nSo the default is buy. The interesting question is the exits.\n\n## Quiet failure one: you owe tax everywhere\n\nThe moment you sell to customers in many countries, you inherit tax obligations you probably did not model. VAT in the EU, GST elsewhere, US sales tax that now applies to software in a growing list of states. A plain PSP like Stripe processes the payment but does not become the seller of record. You are the seller, which means you are the one who owes the filings.\n\nThis is where a merchant of record changes the math. A merchant of record (Paddle, Lemon Squeezy, and similar) is legally the seller. They collect and remit the tax, they take on the compliance, and you get one payout and one relationship instead of forty tax registrations. The tradeoff is a higher cut and less control over the checkout and the customer data. For a small team selling globally, that cut is usually cheaper than a part-time finance hire plus the risk of getting remittance wrong.\n\nThe trap is discovering this after you have crossed a threshold. Tax obligations do not wait for you to notice them.\n\n## Quiet failure two: your pricing outgrows flat plans\n\nHosted subscription billing is excellent at \"twenty nine dollars a month\". It gets awkward fast when pricing becomes usage-based, seat-based with [proration mid cycle](/blog/subscriptions-are-licensing-that-bills-on-time), or a hybrid of a base fee plus metered overage. You can bend a PSP's metered billing to do a lot, but at some point you are metering, aggregating, and rating usage in your own system and only using the provider to move the money.\n\nThat is the signal that you are already building billing, whether you admit it or not. The question stops being build vs buy and becomes which layer you own. Usually the right split is: you own metering and rating (because it is your product's logic and nobody else can do it), and you keep buying the payment rails, tax, and card handling. Owning the whole stack including the card vault is almost never worth it.\n\n## Quiet failure three: you become the middleman\n\nThe day you pay out to third parties (a marketplace, a platform where creators or vendors get a share) your billing problem changes shape. Now you have split payments, payout schedules, onboarding and identity verification for the people you pay, and a reconciliation problem in two directions. This is genuinely hard, and it is also exactly where the providers have built products (Stripe Connect and its equivalents). Buy that too. Writing your own payout and KYC layer is a way to spend a year building a worse version of a regulated product.\n\n## Quiet failure four: the provider's limits become your product's limits\n\nSometimes the thing that forces a change is not scale, it is fit. The provider does not support a currency you need, a payment method your market actually uses, a dunning flow your customers expect, or a data residency requirement a large customer demands. When the processor starts dictating what your product can do, you either add a second processor and route between them, or you build an abstraction so the processor becomes swappable.\n\nThat abstraction is the one piece of \"build\" I recommend early, and it is cheap: do not let the vendor's SDK types leak into your domain. Wrap it.\n\n```php\ninterface PaymentGateway\n{\n    public function charge(Money $amount, Customer $customer, string $idempotencyKey): ChargeResult;\n    public function refund(string $chargeId, Money $amount): RefundResult;\n}\n```\n\nYou are not building a billing engine here. You are making sure that the day a second processor becomes necessary, it is a new implementation of an interface and not a rewrite of half your app. This costs a day now and saves a quarter later.\n\n## How to actually decide\n\nRun the decision against these, in order:\n\n1. One or two plans, one or two countries, cards only. Buy a PSP. Do not build. Do wrap it behind an interface.\n2. Selling globally, tax is now your problem. Strongly consider a merchant of record before you build a tax engine.\n3. Pricing is usage-based or hybrid. Own the metering and rating. Keep buying the rails.\n4. You pay out to third parties. Buy the marketplace product. Do not build KYC and payouts yourself.\n5. The provider cannot do something core to your product. Add a second processor behind your interface. Do not rewrite.\n\nNotice that \"build the whole thing\" never appears. In every early-stage team I have worked with, I have not met one that was right to build the card handling layer from scratch. The real skill is not building or buying. It is knowing which layer to own and buying everything under it, so that when you hit one of these quiet failures, you are extending a system instead of replacing one while customers are trying to pay you.\n\n## The takeaway\n\nBuy the boring, regulated layers and own only the logic that is genuinely yours. The four quiet failures (global tax, usage-based pricing, becoming a marketplace, and provider limits) are predictable, so treat them as planned exits rather than emergencies. Do that, plus wrap your processor behind an interface on day one, and every one of these transitions becomes extending a system instead of replacing one while customers are trying to pay you.\n\n## FAQ\n\n**When is Stripe genuinely enough?**\nWhen you have one or two plans, monthly and annual, in one or two countries, cards only. A hosted processor plus webhooks plus source of truth, idempotency, and an audit log is a complete billing system at that stage.\n\n**What is the difference between a payment service provider and a merchant of record?**\nA PSP like Stripe processes the payment but leaves you as the seller of record who owes the tax filings. A merchant of record like Paddle or Lemon Squeezy is legally the seller, so they collect and remit tax in exchange for a higher cut and less control.\n\n**Should I ever build my own card handling?**\nAlmost never. It buys you PCI liability and a worse retry engine, and \"build the whole thing\" does not appear anywhere in a sane decision path.\n\n**What is the one piece of build worth doing early?**\nWrap the provider behind your own payment interface so its SDK types do not leak into your domain. It costs about a day and saves a quarter when a second processor becomes necessary.\n\n**How do I know I am already building billing without admitting it?**\nWhen you are metering, aggregating, and rating usage in your own system and only using the provider to move the money. At that point the question is which layer you own, not build vs buy.\n",[20,23,26,29,32],{"q":21,"a":22},"When is Stripe genuinely enough?","When you have one or two plans, monthly and annual, in one or two countries, cards only. A hosted processor plus webhooks plus source of truth, idempotency, and an audit log is a complete billing system at that stage.",{"q":24,"a":25},"What is the difference between a payment service provider and a merchant of record?","A PSP like Stripe processes the payment but leaves you as the seller of record who owes the tax filings. A merchant of record like Paddle or Lemon Squeezy is legally the seller, so they collect and remit tax in exchange for a higher cut and less control.",{"q":27,"a":28},"Should I ever build my own card handling?","Almost never. It buys you PCI liability and a worse retry engine, and \"build the whole thing\" does not appear anywhere in a sane decision path.",{"q":30,"a":31},"What is the one piece of build worth doing early?","Wrap the provider behind your own payment interface so its SDK types do not leak into your domain. It costs about a day and saves a quarter when a second processor becomes necessary.",{"q":33,"a":34},"How do I know I am already building billing without admitting it?","When you are metering, aggregating, and rating usage in your own system and only using the provider to move the money. At that point the question is which layer you own, not build vs buy.","8 min read",8,1785070532920]