The Vibe Coder’s Guide to Accepting Payments

Vibe coding has massively lowered the barrier to releasing your own software. You can now turn an idea into an MVP in a matter of hours.

Then you decide you want someone to pay you. For many of us, the first instinct would be to open Cursor, Claude or Codex and type something along the lines of:

“Add subscriptions to my app.”

However, when you ask your agent to add payments, you may skim over the choice of provider. That decision is worth a closer look because it can determine who is actually responsible for the sale.

I've had to make this call several times while building Thenty, StreamShift and other projects. You might expect the choice to come down to APIs and fees. What is easier to miss are the obligations behind the transaction: VAT, GST and the role of a Merchant of Record.

Payment processor or Merchant of Record?

Stripe is usually described as a payment processor, although Payment Service Provider is the more accurate term. It gives a business the infrastructure required to accept payments, store payment methods, manage subscriptions and issue refunds.

The relationship looks roughly like this:

The important bit is the second line. You are the seller.

That means the tax obligations created by the sale generally belong to your business. Sell software internationally and you may need to work out where to register your business, which rate to charge and how to file or remit the tax you collect.

Stripe Tax helps monitor these obligations and automate the calculation and collection. In the standard Stripe Payments model, however, the merchant remains responsible for understanding its registrations and filing requirements.

A Merchant of Record changes the second line:

Providers such as Paddle, Lemon Squeezy and Polar use this model for eligible products. The customer buys from them, they handle the transaction and applicable sales tax, VAT or GST, and you receive the remaining proceeds.

You still run a business and may owe tax where you are based. A Merchant of Record does not make every tax problem disappear; it takes responsibility for much more of the individual sale.

The simplest explanation I found is:

A payment provider gives you the infrastructure to sell something. A Merchant of Record sells it on your behalf.

Even Stripe now covers both sides of this distinction. Stripe Managed Payments is its Merchant of Record product for digital goods. The decision is no longer simply “Stripe or a Merchant of Record?” It is which selling model you want, followed by which provider best implements it.

Why I would start with a Merchant of Record

Let’s say I have vibe coded some SaaS on a Saturday. It has no customers, no revenue and no evidence that anyone but a few friends will use it.

At that point, I am trying to move from:

$0 → $1

A Merchant of Record will generally cost more per transaction. In return, it can absorb work involving tax collection, remittance, invoices, refunds, chargebacks and selling into different jurisdictions. For an unproven side project, that sounds like a reasonable trade.

There are constraints. The provider may support fewer unusual pricing models, restrict what can be sold and control parts of the checkout. Its name may also appear on the customer's receipt or bank statement.

That is the normal trade-off of a higher-level abstraction: less work and less flexibility.

When the fees start to matter

Providers charge a percentage plus a fixed amount and add fees in different situations. Here's a useful comparison.

Say a US business charges $20 per month and every customer pays with a domestic card. Stripe's public pay-as-you-go price is 2.9% plus 30¢ for Payments, with another 0.7% of billing volume for Stripe Billing. That makes the subscription stack 3.6% plus 30¢ per payment.

For the Merchant of Record providers mentioned above, the published subscription prices are Paddle at 5% plus 50¢, Lemon Squeezy at 5.5% plus 50¢ and Polar at 4.5% plus 40¢. A simple average is therefore 5% plus roughly 47¢ per payment.

Monthly revenue    Stripe    Average MoR    Difference
$1,000             $51       $73            $22
$10,000            $510      $733           $223
$100,000           $5,100    $7,333         $2,233

At $1,000 per month, I would happily pay roughly $22 extra if it saved me several hours of tax administration. At $100,000 per month, the difference is about $26,800 per year. Spending engineering and accounting time on the payment stack suddenly seems much more sensible.

International cards, currency conversion, tax-inclusive pricing, chargebacks and volume discounts can all move these numbers. The point is that the right provider at $0 monthly revenue may not be the right provider at $100,000.

That is fine. The decision can change when the constraints change.

What I would check before writing any code

Price would not be the first tab I opened. I would check:

• Can I use the provider from my country and sell into the markets I care about?
• Does it support subscriptions, trials and the billing model I need?
• What products are prohibited?
• Who handles refunds, chargebacks and payment support?
• Which currencies can customers pay in, and which currency will I receive?
• What appears on the customer's receipt and bank statement?
• Can I export customer and subscription data if I leave?

That last question matters because payment integrations spread quickly. Customer IDs enter the database, webhooks shape subscription state and the billing portal becomes part of the product.

I would not build an elaborate provider-agnostic framework for a side project with three users. I would keep one small boundary between the provider and the rest of the application.

The application should care about:

user.hasActiveSubscription

Not:

user.stripeSubscriptionStatus === "active"

It will not make a migration easy, but it stops one provider's terminology from spreading through the codebase.

My extremely scientific decision tree

This is roughly how I would make the decision today:

In an established business with specialised payment requirements and accounting support, I would look more closely at the control offered by a traditional payment-provider model.

For a new side project, I want the shortest reasonable path from $0 to $1. If that means giving up a couple of percentage points so somebody else worries about VAT in Germany, I am probably taking that deal.

AI can write the checkout, webhook and database integration. The part worth understanding yourself is who is actually selling the product and which responsibilities come with that decision.

Vibe code the product. Vibe code the checkout. Just do not vibe code your understanding of who is taking the payment.