DEV Community: Supermax

How to Sell Usage Credits in Your AI App (Pay-as-You-Go Without Surprises)

Supermax — Mon, 02 Nov 2026 04:40:31 +0000

Your app calls an AI model, and every time someone uses it, you pay a little. A flat monthly price works until one customer uses it a hundred times more than everyone else. Then you start wondering whether you should charge by use instead. Credits are the usual answer: the customer pays up front for a balance, and each use takes some of it away.

I'm Deepak, a developer in Hyderabad. I build side projects with AI agents and spend a lot of my time wiring payments into apps made with Claude Code, Cursor and Codex. This guide covers the ways to charge by usage, the choices you have to make before your agent writes anything, what Polar and Stripe offer, and what to test. No code needed.

Everything I say about Polar and Stripe comes from their own docs, as of 30 Oct 2026, linked so you can check again. Usage billing is one of the faster-changing parts of both, so re-read the docs before you rely on a detail.

The short answer

Pick a unit your customers understand, like "1 credit = 1 image". Decide what happens when someone runs out. Keep one clear record of each person's balance, and make sure two quick clicks can't spend the same credit twice. Add credits only when the payment provider confirms the payment, and only once per payment. Then test all of it in test mode before a real customer does.

Three ways to charge by usage

There are three common setups. They sound similar, but they feel very different to the customer.

Credit packs: the customer buys a pack (say, 100 credits), uses them, and buys another when they run low. They never pay more than they chose to. The risk is on the other side: they can run out halfway through something and get annoyed.
A monthly allowance in a subscription: the customer pays every month and gets a set number of credits each month. You have to decide whether unused credits carry over to the next month or reset. Often paired with packs for people who need extra.
Billing for usage afterwards: the customer uses the app freely and gets a bill at the end of the month for what they used. This is closest to how cloud providers charge. Nobody runs out mid-task, but a customer can get a bill they didn't expect, which is a quick way to lose trust.

For a small app, packs or a monthly allowance are usually easier to explain and harder to get wrong, because the customer has paid before they use anything. Billing afterwards makes more sense when your customers are businesses that expect it. I'm not going to pretend one of these sells better; it depends on your app and your customers.

If you're still deciding between one-time, subscription and credits in general, my guide on how to charge for your vibe-coded app covers that first choice.

Pick a unit people understand

"Tokens" mean something to you. They mean very little to most customers. A unit tied to what the customer actually gets is easier: one credit per image, per document summarised, per minute of audio. If different actions cost you very different amounts, give them different prices in credits ("a quick answer costs 1 credit, a long report costs 5") and show that price before the person clicks.

To set the price, work out what one use costs you: the AI model's charge for a typical request, plus anything else that use triggers, like storage. Your provider's pricing page and your own usage dashboard will tell you. Then add a margin that also covers the payment provider's fees and the uses that fail and get retried. I can't give you a number, because it depends entirely on your model and your app, so measure a few real uses rather than guessing.

Keep credits as whole numbers. "You have 37 credits left" is clear; "you have 3.72 credits" invites questions, and fractions are where balance bugs like to hide.

What happens at zero

Decide this before you build, because your agent will pick something if you don't.

Stop with a friendly screen. When the balance is too low for the next action, say so plainly and offer a top-up button. Don't start the work and then fail halfway.
Warn before zero. Show the balance somewhere visible and warn when it gets low, so running out is never a surprise.
Decide on going below zero. Some apps allow a small overdraft so a task in progress can finish. That's fine if you decide it on purpose. What you don't want is a balance that goes negative by accident because someone clicked twice quickly, or opened two tabs.

What Polar and Stripe offer (as of 30 Oct 2026)

On Polar, usage-based billing works like this: your app sends Polar a small message each time a customer uses something (Polar calls these events), and a meter counts or adds them up per customer. Polar labels usage-based billing a new feature.

Credits: the credits page says you attach a credits benefit to a product. On a one-time product, the credits are added once when the customer buys. On a subscription, they're added at the start of every billing period, and none are added while the subscription is "past due" (a renewal payment failed).
Credits only, or credits plus a bill: if the product also has a metered price, usage beyond the credits is charged as overage. If you want credits only, the page says not to add a metered price, so nothing extra is ever billed.
Adding credits by hand: you can add credits to a customer from the dashboard, for example as a goodwill gesture, and choose whether unused ones carry over to the next period. Credits added by mistake can be reversed within 7 days, but only the unused part.
What the customer sees: the customer portal shows their estimated charges for each meter.
The important warning: Polar's page says it doesn't block usage when a customer goes past their balance. Your app has to do that itself.

On Stripe, the usage-based billing page now says Metronome is part of Stripe and is the recommended starting point for new usage-based setups, including prepaid credits. The older "basic" usage billing, built on meters, is still fully supported and, according to the same page, works more fully with Stripe Checkout. If your agent suggests one or the other, this is why; ask it which one it's using and why.

Billing credits: in the basic setup, Stripe's billing credits page describes credit grants as an amount of money off a customer's future usage bills. They only apply to subscriptions that bill by metered usage, and they're used when the bill is finalised, not the moment someone uses your app.
Expiry: credits don't expire unless you set an expiry date on the grant.
Rules: Stripe says billing credits can't be sold as gift cards or as stored money to spend elsewhere. They're for your own product only.
Refunds: the same page says issuing a credit note doesn't give the credits back; you'd have to grant new ones.

So on Stripe, "1 credit = 1 image" packs aren't something you switch on. Many small apps keep that balance in their own database and use Stripe Checkout only to sell the packs. That's a perfectly normal setup; it just means your app owns the balance.

What your app has to do

Whichever provider you use, these are the parts your agent has to get right. Each comes with something you can ask it.

One record of the balance. Either your own database holds the balance, or the payment provider does. Never both by accident, or they'll drift apart. Ask your agent: "Where is each user's credit balance stored, and is that the only place we check before letting them use a credit?"
Spending in one safe step. Checking the balance and taking the credit away must happen together, so two quick clicks or two open tabs can't both spend the last credit. Ask your agent: "If a user with 1 credit clicks twice at the same moment, what stops both clicks from going through?"
Add credits only when payment is confirmed. The success page after checkout isn't proof of payment. Polar and Stripe send your app a payment message (a webhook) when a payment really goes through, and that's when credits should be added. Ask your agent: "Are credits added from the verified payment message, and not from the success page?"
Only once per payment. Payment messages can arrive twice. Adding the same pack twice is free credits; missing it is a customer who paid for nothing. Ask your agent: "If the same payment message arrives twice, are credits still added only once?"
Failed work gives credits back. If the AI call fails after you took the credit, give it back, once. Ask your agent: "If the AI request fails, does the user get the credit back, and only one time?"
A refund rule. Decide what refunding a pack means when some credits are already used: refund only the unused part, or take the credits away and refund in full. Write it on your refund policy. My guide to refunds and cancellations covers the access side.

What to test (in test mode, never with a real card)

Use Polar's sandbox or Stripe's test mode with their test cards. Go through this list as a customer would:

Buy a pack. Check the balance goes up by exactly the right amount.
Use the app. Check the balance goes down by the right amount for each action.
With 1 credit left, click the action button twice as fast as you can (and try it from two tabs). Only one should go through.
Run the balance to zero. You should see your friendly "out of credits" screen, not an error.
Top up and check you can carry on.
Get the same payment message delivered twice. Your agent can show you how to resend one in test mode (Stripe's dashboard lets you resend events). The balance shouldn't change.
Make an AI request fail on purpose and check the credit comes back once.
Refund a pack and check your refund rule happens.
If you have a monthly allowance, move time forward to the renewal and check the allowance resets or carries over the way you decided. On Stripe, test clocks do this.

If you want customers to try the app before buying, a few free starter credits work like a small trial; my guide to adding a free trial covers the trade-offs. And if someone ever says they paid but got no credits, my guide on why customers get locked out after paying walks through the usual causes.

Where ShipToPaid fits

I made ShipToPaid so AI agents get payments right in apps like yours. The full pack has a usage credits skill and an add-credits command that guide your agent through a credit balance in your own database and/or Polar usage billing, with credits added only from verified payment messages and spending done in one safe step. To be clear about its limits: the starter app itself sells subscriptions, not credits, and the skill says its Polar usage-billing examples are checked against Polar's code library but haven't been tested with live usage billing. You don't need any of it to follow this guide.

How to Add a Free Trial to Your Vibe-Coded App (Without Giving It Away)

Supermax — Thu, 29 Oct 2026 04:38:34 +0000

You built an app with an AI agent, it works, and you're ready to charge. Then the doubt creeps in: will anyone pay before they've tried it? A free trial is one answer. It's also one more thing your app has to get right, because now some people have the paid plan without having paid yet.

I'm Deepak, a developer in Hyderabad. I build side projects with AI agents and spend a lot of my time wiring payments into apps made with Claude Code, Cursor and Codex. This guide covers whether you need a trial at all, the choices you have to make, what Polar and Stripe offer, and what to test. No code needed.

Everything I say about Polar and Stripe comes from their own docs, as of 28 Oct 2026, linked so you can check again. These things change, so re-read the docs before you rely on a detail.

The short answer

A trial makes sense when people need to use your app for a few days before they can tell it's worth paying for. If one look at a demo video is enough, you may not need one. Decide three things before you ask your agent to build it: card up front or not, how long, and what happens on the last day. Then test it in test mode the way a real customer would use it.

Trial, free plan or money-back promise?

These three all lower the risk of paying, but they work differently:

Free trial: the full paid plan for a limited time. After that, the person pays or loses access.
Free plan: a smaller version that's free forever, with a clear reason to upgrade (a limit, or features only paid users get). Your app has to enforce those limits itself.
Money-back promise: people pay from day one, and you refund them if they ask within a set time. No special trial setup, but you do need to handle refunds properly (see my guide to refunds and cancellations).

None of these is right for every app, and I'm not going to pretend one sells better than the others. If you sell a one-time purchase rather than a subscription, a trial usually doesn't apply at all; my guide on how to charge for your vibe-coded app covers that choice.

Card up front or not

This is the biggest decision, because it changes what happens when the trial ends.

With a card up front, the person enters their card when they start. When the trial ends, they're charged and the subscription simply continues, unless they cancelled first. Fewer people start, because asking for a card is a bigger step. The people who do start have already decided they might pay. Be very clear about the date of the first charge, so nobody feels tricked.

Without a card, anyone can start with just an account. When the trial ends, nothing is charged; they have to come back and choose to pay. More people try it, but your app now has to handle a lot of people whose trial ended without paying, and you need to remind them. Stripe's own docs warn that no-card trials can attract spam sign-ups and suggest asking for an account and a captcha first.

Either way, tell people before they start: whether a card is needed, when the trial ends, what they'll be charged and how to cancel.

How long should the trial be?

There's no magic number. A good rule of thumb: long enough for a new user to reach the moment where they think "yes, this is worth it", plus a little slack.

Find that moment by timing it. Ask a friend who has never seen your app to sign up and use it while you watch. If they get real value on day one, a short trial is fine. If your app only shows its worth after a week of use (a habit tracker, a weekly report), the trial has to cover that week.

Longer isn't automatically kinder. Stripe's Checkout trial guide mentions that long trials can run into cards expiring before the first charge.

What Polar and Stripe offer (as of 28 Oct 2026)

On Polar, the trials page says you can set a trial on the product, on a checkout link, or when your app creates a checkout. The one on the checkout link or checkout wins over the product's. You pick a unit (day, week, month or year) and a number.

Card: Polar still collects payment details at checkout. The customer isn't charged until the trial ends, and isn't charged at all if they cancel before then. I didn't find a no-card option on that page.
Reminder emails: Polar emails the customer before the first charge: 3 days before for trials of 3 days or more, 1 day before for trials of 1 to 3 days, and none for trials shorter than a day. You can switch these off in your settings.
While trialing: the subscription has the status "trialing". When the trial ends, Polar charges the customer automatically and the billing cycle starts.
Repeat trials: there's a "Prevent trial abuse" setting. It blocks a new trial if the same email (ignoring tricks like name+alias@) or the same card has already used one, and the checkout continues at the normal price.
Changing a trial: from the dashboard you can add, extend or end a customer's trial. Ending it charges them straight away.

The trials page doesn't describe a failed first charge on its own. Polar's failed payments page explains what happens when a subscription charge fails (the subscription goes "past due", then retries). Test the first charge failing in the sandbox and see what your app does.

On Stripe, the Checkout free trials guide says you set the trial length when your app creates the checkout, up to 730 days.

Card: by default Checkout collects a card for after the trial. You can also start a trial without one. Then you choose what happens if no card has been added when it ends: the subscription is cancelled, or paused until they add one (free trial periods).
Reminder emails: you can turn on a reminder email in your Stripe settings. Stripe's trial rules page says it goes out 7 days before the trial ends (or right away if the trial is shorter than 7 days), and none are sent in test mode. The same page says you must follow card network rules for trials, so read it if you take cards up front.
While trialing: the subscription has the status "trialing". Stripe also sends your app a "trial will end" payment message a few days before the end. When the trial ends, Stripe creates the first bill and tries to charge it about an hour later. If that charge fails, it's handled like any other failed payment.
Something to know: Stripe now calls this kind of trial "legacy" and recommends a newer feature called trial offers for new setups. Its page says Checkout only supports trial offers for invited accounts, so for a normal Checkout setup the trial guide above is still the one to read. If your agent mentions either, this is why.

On Stripe, plan to handle "one trial per person" in your own app.

What your app has to do

Polar or Stripe runs the clock and the billing. Your app decides who can open what. That decision usually comes from a payment message: an automatic note Polar or Stripe sends your app when something changes (developers call these webhooks).

Give access during the trial. A subscription that is "trialing" should unlock the paid plan, just like "active". AI-written code often checks for "active" only, so trial users pay nothing and get nothing either.

What to ask your agent: "Treat subscriptions with status trialing the same as active for access. Show me where the app checks this."

End it at the right time if they don't pay. If the trial ends without a payment (cancelled, paused, or a failed first charge), access should end too. Base it on what the payment company says, not on a date your app worked out on its own.

What to ask your agent: "When a trial ends without a successful payment, remove paid access. Use the payment messages, not a timer in our code."

Keep access with no gap if they do pay. The switch from "trialing" to "active" shouldn't log anyone out or show the upgrade page for a moment.

One trial per person. Decide your rule (for example, one trial per account) and make your app enforce it. On Polar, also switch on "Prevent trial abuse".

What to ask your agent: "Only allow one free trial per account. If someone who already had a trial checks out again, start a normal paid subscription."

What to test (in test mode, never a real card)

Use test mode with test cards, which move no real money. After each step, check what your app shows, not just the dashboard:

Start a trial as a new user. The paid plan should unlock right away.
Log out and back in. Still unlocked.
End the trial early. On Polar, use "End trial" on the subscription in the sandbox dashboard. On Stripe, test clocks let you fast-forward time.
Check the first charge went through and access stayed on, with no gap.
Start another trial and cancel it during the trial. No charge should happen, and access should follow your cancel rule (usually it lasts until the trial would have ended).
Try a second trial with the same account. Your rule should kick in.
Make the first charge fail with a declining test card and check you follow your failed-payment rule. My guide to refunds and cancellations covers failed renewals in more detail.
If you went with no card, let a trial end without adding one. Access should end, and adding a card later should bring it back.

If a trial user ever says they can't get in, my guide on why customers get locked out after paying walks through the usual causes.

Where ShipToPaid fits

I made ShipToPaid so AI agents get payments right in apps like yours. Its starter and paywall skills already treat "trialing" the same as "active" for access, but the starter doesn't set up a trial for you; you switch that on in Polar or Stripe. The pricing skill helps you choose between a trial, a free plan and paid-only, and it tells your agent not to advertise a trial you haven't set up and tested. The launch audit walks you through checks like the ones above. You don't need any of it to follow this guide.

How to Handle Refunds and Cancellations in an AI-Built App

Supermax — Mon, 26 Oct 2026 04:43:29 +0000

Your first sale feels like the finish line. It isn't. Sooner or later someone asks for a refund, someone cancels, and someone's card stops working. Each should change what that person can open in your app, and that's the part AI agents tend to skip.

I'm Deepak, a developer in Hyderabad. I build side projects with AI agents and spend a lot of my time wiring payments into apps made with Claude Code, Cursor and Codex. This guide covers what should happen to access in each moment, how Polar and Stripe behave, and what to test. No code needed.

Everything I say about Polar and Stripe comes from their own docs, as of 23 Oct 2026, linked so you can check again. These things change, so re-read the docs before you rely on a detail.

Write your rules down first

Your agent can only build the right thing if you tell it what "right" is. A sensible starting point for a small app:

One-time purchase, refunded: access ends.
Subscription, cancelled by the customer: access lasts until the end of the period they already paid for, then ends.
Subscription, refunded: decide up front. Most makers also cancel straight away, so access ends now.
Renewal payment failed: a short grace period with a friendly "please update your card" banner, then access ends if nobody fixes it.
Chargeback (the customer asks their bank to reverse the payment): access ends.

Your rules can differ. What matters is that you choose, write it down, and test it. Put the short version on your refund page too, so customers know what to expect.

Keep "who has access, and until when" in your own database, and let payment messages update it. A payment message is an automatic note Polar or Stripe sends your app when something happens (developers call these webhooks). Your paid pages should read your database, never guess.

Refunds: getting the money back is not the same as losing access

A refund moves money. It doesn't always change what your customer can open.

On Polar, as of 23 Oct 2026, the refunds page says that for one-time purchases you can revoke the customer's benefits (like file downloads or license keys) when you refund, and that option is ticked by default. For subscriptions it's different: refunding an order returns the money but doesn't end the subscription. To end access, you cancel the subscription as well.

The same page says Polar may refund an order itself within 60 days of purchase to head off a chargeback, even if you have a "no refunds" policy, and when it does, it cancels any related subscription and revokes benefits at the same time. So a refund can happen without you clicking anything, and your app has to listen for it.

On Stripe, as of 23 Oct 2026, you can issue full or partial refunds from the dashboard (Stripe's refunds docs). Cancelling a subscription is a separate step: when you cancel one in the dashboard, Stripe asks whether to refund nothing, a prorated amount (the unused part of the period), or the last payment in full (cancel subscriptions). So refunding a payment on its own doesn't tell your app to lock anyone out.

On both, the original payment fees aren't returned when you refund, so a refund costs you a little more than the sale price you give back.

What to ask your agent: "When a refund payment message arrives, apply my rule: for one-time purchases, remove access. For subscriptions, check whether the subscription was also cancelled and follow that. Show me which messages you listen for."

Cancellations: "cancelled" doesn't mean "gone today"

Someone who cancels a monthly plan on day 10 has still paid for the rest of the month. The fair default, which both companies support, is to keep access until the period ends.

On Polar, as of 23 Oct 2026, a customer who cancels from the customer portal gets "cancel at period end": the subscription stays active and keeps its benefits until the end date, and it can be uncancelled before then (managing subscriptions). The detail that trips up AI-written code: according to Polar's webhook events page, the "canceled" message is sent immediately, while the subscription is still active. A second "revoked" message comes when the period actually ends. If your app locks people out on the first message, you've just taken away time they paid for.

On Stripe, as of 23 Oct 2026, a cancel through the API takes effect immediately by default; in the dashboard you choose immediately, at the end of the period, or a custom day. A cancel at period end can be reactivated any time before then (cancel subscriptions). Stripe's customer portal lets customers cancel by themselves, and that option is on by default (cancellation page).

Watch for three bugs: access ends the moment someone clicks cancel; access never ends at all; or the customer uncancels and your app doesn't notice, so a paying customer stays locked out (more on that in why customers get locked out after paying).

What to ask your agent: "When a customer cancels, keep their access until the end of the period they paid for, then remove it. If they uncancel before then, keep access. Base it on the end date the payment company sends, not on the cancel click."

Failed renewals: be kind, but don't be a free plan

Cards expire and banks decline. A failed renewal usually isn't a customer trying to leave, so don't lock them out the second it happens.

On Polar, as of 23 Oct 2026, a failed renewal moves the subscription to "past due", Polar emails the customer a link to update their card, and it retries 2, 7, 14 and 21 days after the first failure. If every retry fails, it revokes the subscription (recovering failed payments). By default, benefits are revoked as soon as the subscription stops being active, but there's a setting to keep them for 2, 7, 14 or 21 days while it's past due.

On Stripe, as of 23 Oct 2026, Smart Retries picks the retry times, and the recommended default is 8 tries within 2 weeks. After the last retry, your dashboard settings decide whether the subscription becomes cancelled, "unpaid", or stays past due. Stripe's subscription statuses say to revoke access once a subscription is unpaid.

A note for makers in India: the same Smart Retries page says Stripe doesn't retry payments on India-issued cards. So with Indian customers on Stripe, a failed renewal may not get a second try, and a clear "update your card" banner matters even more.

Whichever you use, pick a grace period, show a banner linking to your billing page while the customer is past due, and make sure access comes back by itself once the payment goes through.

What to ask your agent: "When a renewal fails, keep access for my grace period and show a banner linking to the billing page. If payment succeeds, remove the banner. If the subscription ends after the retries, remove access."

Chargebacks, briefly

As of 23 Oct 2026, Stripe's cancel subscriptions page says a disputed subscription keeps renewing unless you change a setting to cancel it automatically. Worth switching on, so a disputed customer isn't charged again. On Polar, the automatic early refunds mentioned above are meant to head off chargebacks on lower-value sales before they're filed.

What to test (in test mode, about 20 minutes)

Use test mode, where test cards move no real money (Polar and Stripe both ask you not to test with real card details). For each line, check what your app shows, not just the dashboard:

Buy a one-time product, refund it in the dashboard. Access should follow your rule.
Subscribe, then cancel from the customer billing page. Access should stay until the period ends.
Uncancel before the end. Access should stay, with no lockout.
Let the cancelled period run out. Access should end. (On Stripe, test clocks let you fast-forward time. On Polar, revoking the subscription in the dashboard shows you the end state.)
Refund a subscription payment without cancelling. Does your app do what you wrote down?
Make a renewal fail (on Stripe, a test clock plus one of the declining test cards does it). You should see the banner, keep access during the grace period, and lose it afterwards.
Fix the card. Access should come back without you touching the account.
Log out and back in after each step, to rule out old login info.

If you haven't run the basics yet, start with the pre-launch checklist in my guide on how to add payments to an app you built with AI. If you're still choosing between one-time and subscriptions, see how to charge for your vibe-coded app; one-time sales skip most of this. And if you haven't picked a provider yet, here's my Polar vs Stripe comparison for indie makers.

Where ShipToPaid fits

I made ShipToPaid so AI agents handle these moments without reminders. Its paywall skill covers cancellations and failed payments, and its launch audit walks you through tests like these. The free lite pack has the Polar basics. The full pack adds Stripe, subscriptions that control access and a customer billing page. You don't need either to use this guide.

Polar vs Stripe for Indie Makers: Which One Should You Pick?

Supermax — Thu, 22 Oct 2026 04:37:03 +0000

You've built your app with Claude Code, Cursor or Codex, and you've decided how to charge for it (if not, start with my guide on how to charge for your vibe-coded app). One decision is left before your first sale: Polar or Stripe?

I'm Deepak, a solo developer in Hyderabad, and I spend a lot of my time wiring both into apps built with AI agents. Short answer: both are good. The real difference is who is the seller on paper, and so who deals with sales tax.

Every fee, country and feature below comes from Polar's and Stripe's own pages, as of 20 Oct 2026, linked so you can check them again. Prices and rules change, so treat this as a map, not the final word.

Who's the seller? Merchant of record in plain words

Whoever is the seller on paper has to charge the right sales tax or VAT for the buyer's country, pay it to the right tax office, and send a proper receipt.

Polar is a merchant of record: a company that acts as the seller for you. Your customer buys from Polar, Polar collects and pays the tax, then pays you what's left after its fee. Polar's own explanation says it takes on the liability for international sales taxes.

With Stripe, you are the seller (in its standard setup), so tax is your job. Stripe has an add-on for that, Stripe Tax. As of 20 Oct 2026, its pricing page lists two plans: Tax Basic, which works out and collects the right tax where you're registered, and Tax Complete, which also handles tax registrations and filings for you. Even then, you're still the seller, so those registrations are in your name.

Stripe now also has its own merchant of record option, Managed Payments, for digital products like software. It's only open to businesses based in certain countries.

Fees, without the guesswork

Standard published rates, as of 20 Oct 2026:

Polar (fees page):

The free Starter plan charges 5% + 50Â¢ per sale, for accounts created on or after 27 May 2026.
Paid plans, from $20 a month, lower that rate. The page shows roughly how much you need to sell before each one pays for itself.
Add 1.5% for cards from outside the US.
Payouts to your bank go through Stripe and carry Stripe's payout fees, which Polar lists on the same page.
Tax handling is included. There's no tax add-on to buy.

Stripe (US pricing page):

2.9% + 30Â¢ per successful payment with a US card.
Add 1.5% for international cards, and another 1% if the payment needs a currency conversion.
Subscriptions run on Stripe Billing, and Billing's pay-as-you-go price is 0.7% of billing volume.
Tax is separate: Stripe Tax Basic is 0.5% per transaction where you're registered (for its no-code setups), and Tax Complete starts at $90 a month on a one-year contract.
Managed Payments, if you can use it, adds 3.5% per transaction on top of the normal payment fees.

Stripe's rates depend on where your business is (its India pricing page, for example, lists different rates), so look at the page for your country.

So on the sticker, Polar's fee per sale is higher than Stripe's basic card rate. That's expected: part of what you pay Polar for is the tax work. To compare fairly, add to Stripe's rate the things Polar already includes:

the tax add-on, or your own time doing tax,
the Billing fee, if you sell subscriptions,
the extra for international cards and currency conversion,
an accountant's time for registering and filing in the places you sell.

Which comes out cheaper depends on where your customers are, what you sell and how much, so run a normal month you'd hope for through both pricing pages. One thing is the same on both: if you refund a sale, the original payment fee isn't given back (Polar, Stripe).

Payouts by country: check this first

This is the step people skip, and it can stop you cold. Before you build anything, check that the company can pay money into a bank account in your country.

Polar pays you out through Stripe Connect Express, and its supported countries page lists every country it can pay out to. Its payout account page adds that the bank account must be in the same country as you (or your business), in the local currency, and that most "borderless" accounts like Wise or Payoneer won't pass. Polar also reviews every account, with an ID check, before the first payout, and its account reviews page says that can take up to 14 days. Build first, then submit.

Stripe lists the countries where you can open an account on its global availability page. If your country isn't there, you can't use Stripe directly. Managed Payments has a shorter list of supported business locations.

A note for makers in India

I'm in India, so I read these pages carefully. As of 20 Oct 2026:

Stripe's India page says Stripe is invite-only here, the account must be a registered Indian business (sole proprietorship, LLP or company), not an individual, and taking payments from abroad needs export details such as a transaction purpose code.
India is on Polar's payout list. Polar's FAQ says payouts work here even though Stripe is invite-only, because your customers buy from Polar and Stripe only sends you the money.
India isn't on the list of business locations for Stripe's Managed Payments.

These rules change. Read both pages yourself, and talk to a CA before your first real sale.

Features a small app actually needs

For a typical small app, both cover the basics:

Checkout page: both give you a ready-made checkout page, so card details never touch your app (Polar checkout links, Stripe Checkout).
Subscriptions: both.
A billing page for customers: Polar's customer portal lets customers cancel, update their card and download invoices, and it's always on. Stripe has a no-code customer portal for updating payment details and subscriptions.
Refunds: both do full and partial refunds. Worth knowing: Polar's refunds page says it may refund a sale itself within 60 days to head off a chargeback, even under a no-refunds policy.
Discount codes: both. Polar calls them discounts, Stripe calls them coupons and promotion codes, and both can apply once, for a few months, or forever.
License keys: Polar has license keys built in, with device limits and automatic removal when a subscription ends. I didn't find a built-in license key feature in Stripe's docs, so plan on your app creating them.
Usage and credits: both let you charge by usage and give customers credits (Polar credits, Stripe usage-based billing).

Also check what you're allowed to sell. Polar is built for software and digital products, and its acceptable use page rules out things like physical goods and human services. Stripe's standard setup isn't limited to digital products, but Managed Payments is.

And on both, test with test cards, not your own real card: Polar's account reviews page and Stripe's testing docs both say so. To check your live Polar setup, Polar suggests a free product or a 100% discount code.

Switching later

Products and prices are easy to set up again in the other dashboard. Saved cards, active subscriptions and customer history are not.

Polar has a guide for moving from Stripe that covers customers, products, subscriptions and saved cards (copied through Stripe's own secure process). As of 20 Oct 2026 it says the tool is rolling out gradually, and that Stripe accounts in India can't use the automatic flow. Going the other way, Stripe says it will transfer your card data to a new provider that meets the card industry's top security level.

Either way, switching is a project, not a button. What makes it smaller is keeping "who has access" in your own database, and letting payment messages update that one place. (Developers call these webhooks: automatic notes from Polar or Stripe saying "this person paid" or "this person cancelled".) If payment details are spread through every page of your app, a switch touches every page. If they live in one place, you change one place.

That habit also protects you from the most painful bug: customers get locked out the same way on both. I wrote up the fixes in I paid but can't get in.

My rule of thumb

Solo, selling software or a digital product to people in many countries, and you don't want to deal with tax? Start with Polar.
Already on Stripe, have a business set up to handle tax, or need something only Stripe does? Use Stripe.
Want Stripe, but with Stripe as the seller on paper? Look at Managed Payments, if your business is in one of its supported countries.

Whichever you pick, check payouts to your country first, read what each lets you sell, and have a short chat with an accountant. Then, before launch, run through the pre-launch checklist in my first guide. The bugs it covers happen on both.

Where ShipToPaid fits

I built ShipToPaid so this choice doesn't change how you work with your agent. The free lite pack covers Polar: checkout tied to the logged-in user, properly checked payment messages and a short launch check. The full pack adds the same for Stripe, plus access that follows payments. You don't need either to use this guide.

This post first appeared on the ShipToPaid blog.

"I Paid but Can't Get In": Why Customers Get Locked Out of AI-Built Apps (and How to Fix It)

Supermax — Mon, 19 Oct 2026 04:49:59 +0000

It's the email every app maker dreads: "I just paid. Why can't I get in?"

The checkout worked, the money moved, and your customer is still looking at a locked page. If you built your app with Claude Code, Cursor or Codex, it's worth being ready for this before it happens.

I'm Deepak, a solo developer in Hyderabad, and I spend a lot of my time wiring payments into apps built with AI agents. This is the calm, step-by-step guide I'd want open the moment that email lands: what to do first, where the problem usually hides, and how to stop it happening again. No code needed.

If you haven't set up payments yet, start with my bigger guide on how to add payments to an app you built with AI. This post zooms in on the most painful bug from that list.

First, the next 10 minutes

Don't start debugging yet. Look after the person first.

Check the payment is real. Open your Polar or Stripe dashboard and search for their email. If you see a successful payment, they paid. If not, ask for their receipt; they may have used another email.
Give them access by hand. Mark their account as paid yourself, or ask your agent to update that one user. Do it now.
Reply kindly. Something like: "Thanks for buying, and sorry about that. You should have full access now. Could you log out, log back in, and tell me if it works?" Short, human, no excuses.
Write down the details. Their checkout email, login email, plan and payment time.

Fixing one account by hand is a rescue, not a fix. If it happened once, it will happen again.

How access is supposed to work (30-second recap)

When someone pays, this is what should happen:

Your customer pays on the payment company's checkout page.
The payment company sends your app a payment message saying "this person paid for this plan." Developers call this a webhook. It's just an automatic message from Polar or Stripe to a web address in your app.
Your app checks that the message is genuine, using a secret from the payment dashboard.
Your app finds the right user and saves "this person has Pro" in your database.
Your paid pages read that saved note and let the person in.

Notice what's missing: the thank-you page. It proves nothing. Access should come from step 4. When someone is locked out, one of steps 2 to 5 broke. Here they are in the order I check them.

Where it breaks, and how to tell

1. The payment message never arrives

What happened: the payment company tried to tell your app, but the message went nowhere. Usually the address saved in the payment dashboard is wrong: a typo, an old address, or one that only worked on your own computer. Or you set it up in test mode and never added it in live mode, which has its own separate settings.

Two sneakier ones: the saved address redirects (say, it has no "www" and your host forwards to "www"), which payment companies count as a failed delivery, or your app's login protection blocks it.

How to tell: open the payment dashboard and find the list of payment messages it has sent (both Polar and Stripe show this in their webhook settings). Find the attempts for this customer's payment. Failed deliveries mean this is your problem. No attempts at all usually means no address is saved for live mode.

What to ask your agent: "This is the address saved in my live payment dashboard for payment messages. Does my live app actually accept messages there, without a redirect or a login check in the way? List everything that differs between my test and live setup."

2. It arrives, but your app rejects it

What happened: the message reached your app, but the "is this real?" check failed, so your app threw it away. Right for fake messages, wrong for real ones. The usual cause is the wrong secret: the test secret is still saved in your live app, or the live secret was pasted with a character missing.

How to tell: in the same dashboard list, the delivery shows an error from your app instead of success. Your hosting logs often show it too.

What to ask your agent: "My live payment messages are being rejected. Check which secret my live app uses and whether it's the live one from the dashboard. Don't turn off the check. Fix the secret."

Never "fix" this by switching the check off. That's the door fake payment messages walk through.

3. It's accepted, but matched to the wrong person

What happened: your app got a genuine message but couldn't tell which of your users it belongs to. This happens when someone logs in with one email and types another at checkout, or when checkout was never linked to the logged-in user, so the app only has an email to go on.

How to tell: compare the email on the payment with the email they log in with. If they differ, this is probably it. You may also find a new, empty account under the checkout email.

What to ask your agent: "When a logged-in user starts checkout, link the checkout to their account, so the payment message points back to that exact user instead of matching by email."

4. It's matched, but the wrong plan is saved

What happened: your app found the right person but saved the wrong thing. Maybe it saved a product name your paid pages don't recognize, or the paid pages look for "Pro" while the app saved "Pro Monthly." Or the product was re-created in live mode and your app only knows the test one.

How to tell: look at what your database says about this user. If it says they paid but names a plan your paid pages don't know, that's the gap.

What to ask your agent: "List every product and price my app knows about, for test and live, and compare them with my live dashboard. Then show me exactly what my paid pages check before letting someone in."

5. Everything is saved, but the app shows old info

What happened: your database is correct, but the customer's login still carries their old "free" status.

How to tell: ask the customer to log out and back in. If that fixes it, this is your problem.

What to ask your agent: "After a payment, make sure paid pages read the user's current plan from the database, not from old login info, so access updates without logging out."

A 10-minute test you can run yourself

Once you think it's fixed, prove it. Do this in test mode, the practice mode where you use test cards and no real money moves:

Sign up as a brand-new user with an email you've never used.
Buy your plan with a test card from the payment company's docs.
Open the payment dashboard and check the payment message was delivered successfully.
Go back to your app without touching anything. Are the paid pages unlocked?
Log out, log back in, and check again.
Sign up as another new user, and this time type a different email at checkout. Does the right account get access?
If you sell several plans, check that the cheapest one doesn't open a pricier plan's pages.

If every step passes, check live mode too, but not with your own real card: Polar and Stripe both ask you not to test with real card details. On Polar, buy with a 100% discount code made just for you and check access the same way. On Stripe, make sure the live keys and the live payment-message address are saved, then check access the moment your first real sale lands.

Make it impossible to miss next time

You can't promise a bug never comes back, but you can hear about it before a customer has to write.

Watch for failure emails. Polar and Stripe both email you when messages to your app keep failing. Make sure those emails reach an inbox you actually read.
Give customers a way out. Put a small "Paid but still locked? Restore my purchase" button, or at least a support email, on your paid pages. A restore button just asks the payment company again about that user.
Re-test after every payment change. New price, new plan, new secret, new domain: run the 10-minute test again. The pre-launch checklist in my first guide covers the rest.
Keep test and live in step. When you change something in test mode, note the matching change for live mode.

If you're still choosing between one-time, subscription or credits, my guide on how to charge for your vibe-coded app helps you decide. Subscriptions add a few more things to test, like cancellations and failed renewals. If you haven't picked a payment company yet, my guide to Polar vs Stripe for indie makers compares fees, payouts by country and features.

Where ShipToPaid fits

I wrote ShipToPaid so AI agents get these steps right the first time. Its skills cover linking checkout to the logged-in user, checking every payment message is genuine, and a launch audit that walks you through a test like the one above. The free lite pack has the Polar pieces. The full pack adds Stripe and access that follows payments. You don't need either to use this guide.

This post first appeared on the ShipToPaid blog.

How to Charge for Your Vibe-Coded App: One-Time vs Subscription (and How to Set It Up)

Supermax — Sun, 18 Oct 2026 05:03:29 +0000

You built an app with Claude Code, Cursor or Codex. People are using it, a few have even said they'd pay for it. So now you're stuck on two questions: how should I charge, and how do I actually set that up without breaking anything?

I'm Deepak, a solo developer in Hyderabad, and I've wired payments into a lot of apps built with AI agents. This guide walks through the choice between charging once and charging every month, which payment company to pick, and the exact steps to get money flowing. No code required to follow along.

If you want the bigger picture on what goes wrong after someone pays, read my first post: How to add payments to an app you built with AI. This one is about the decision that comes before that.

The three ways to charge

Almost every small app uses one of these, or a mix:

One-time payment. The customer pays once and keeps access. Think of a template, a tool, a lifetime deal, or a downloadable pack.
Subscription. The customer pays every month or every year, and access stops if they stop paying.
Credits (pay as you go). The customer buys a bundle of uses, like 100 image generations, and buys more when they run out.

There's no "correct" answer. The right one depends on one simple question.

The one question that decides it

Does your app cost you money every time someone uses it?

If yes, you probably want a subscription or credits. If no, a one-time payment is often simpler and easier to sell.

Here's why. Many vibe-coded apps call an AI model, send emails, store files or run on a server that charges by use. Those costs keep coming as long as the customer keeps using the app. If you charge once, a heavy user can end up costing you more than they paid. A monthly price, or credits that run out, keeps what you earn in line with what you spend.

If your app is mostly a fixed thing, like a calculator, a template, a desktop tool or a set of files, your costs don't grow much with each user. Charging once is honest and easy for buyers to say yes to.

One-time payment: when it fits

Good for: tools that don't cost you much to run, templates and starter kits, downloadable products, and "lifetime access" launch offers.

Why people like it: buyers don't have to worry about another monthly bill. It's easier to explain, and there's nothing to cancel.

The catch: you get paid once. To keep earning, you need a steady flow of new buyers, or paid upgrades later. And be careful with "lifetime" deals on apps that call AI models, because those costs don't stop.

What you need to set up:

A product in your payment company's dashboard with a single price.
A "Buy" button that sends people to the payment company's checkout page.
Your app listening for the payment message (developers call this a webhook: an automatic note from the payment company saying "this person paid") and marking that person as a buyer.
Paid pages that check "is this person a buyer?" before letting them in.

That's it. No renewals, no cancellations, just refunds to handle.

Subscription: when it fits

Good for: apps people use regularly, apps with ongoing costs (AI, hosting, data), and apps you keep improving.

Why makers like it: income that repeats every month, which makes it easier to plan and to keep paying for servers.

The catch: more moving parts. People cancel, cards expire, payments fail, and some customers switch between plans. Your app has to react correctly to every one of those, not just the first payment. And buyers think harder before signing up for something that bills them forever.

What you need to set up:

A product with a monthly price, and optionally a yearly price (often offered at a discount).
A "Subscribe" button that goes to checkout.
Your app listening for payment messages, not just "paid" but also "renewed", "cancelled", "payment failed" and "refunded", and updating the person's access each time.
Paid pages that check "is this subscription active right now?"
A "Manage billing" page where customers can change their card or cancel by themselves. Both Polar and Stripe offer a ready-made one, so you don't build it from scratch.

Step 3 is where most AI-written setups go wrong. The agent handles the first payment and forgets the rest, so cancelled users keep access forever. My first post has a checklist to catch that.

Credits: the middle ground

If your costs depend heavily on how much someone uses the app, credits can be fairer than either option. Customers buy a pack, each use takes some away, and they top up when they run low. Light users pay little, heavy users pay more, and you never lose money on one person.

The trade-off: your app has to keep an accurate balance for every user and never let it go below zero, even if someone clicks twice quickly. It's very doable, but test it carefully.

Not sure? Start simple

If you can't decide, here's a reasonable default:

Low running costs: start with a one-time price. You can add a subscription tier later.
Real running costs (like AI calls): start with one monthly plan. Just one. Add a yearly option or a second tier when people ask for it.

Whatever you pick, you can change it. Your first price is a guess, and that's fine. Real customers will tell you more than any pricing article.

Polar vs Stripe for indie devs

Once you know how you'll charge, you need a payment company. For most solo makers the choice is Polar or Stripe. Both handle one-time payments and subscriptions well.

Polar is a merchant of record. In plain words, Polar is the seller on paper: it collects and pays sales tax and VAT in the countries your customers buy from, then pays you. If you're selling worldwide on your own, that saves a lot of paperwork. The trade-off is a higher fee per sale than Stripe's basic rate, so check their current pricing page.

Stripe handles the payment, but you're the seller, so tax is your job. Stripe Tax can work out the right amount to charge, and its paid Tax Complete plan can also handle tax registrations and filings for you. You're still the seller, though, so those registrations are in your name. In return you get more control and a huge set of features. Stripe also has its own merchant of record option, Managed Payments, for businesses based in the countries it supports.

My rule of thumb: solo, selling digital products or subscriptions to many countries, and don't want to think about tax? Start with Polar. Already have a Stripe account or a business set up to handle tax? Use Stripe. Either way, first check that the one you pick can pay out to your country. And if tax worries you, a short chat with an accountant is money well spent. I compared the two in more detail (fees, payouts by country, features and switching later) in Polar vs Stripe for indie makers.

How to set it up, step by step

This works whether your app is in Next.js (the most common setup for vibe-coded web apps) or something else. You'll ask your AI agent to do most of it, but you stay in charge of checking it.

Create an account with Polar or Stripe and stay in test mode (a practice mode where no real money moves).
Create your product and price in the dashboard: one-time, monthly, or both.
Ask your agent to add checkout. Be specific: "Add a Subscribe button that sends logged-in users to Polar checkout for my Pro monthly product."
Ask it to handle payment messages, and list them all: paid, renewed, cancelled, payment failed, refunded. Ask it to verify each message is genuine using the secret from the dashboard.
Ask it to lock paid pages so they check access in your database, not just whether someone saw the thank-you page.
Add the billing page so customers can cancel or update their card themselves.
Test everything with a test card: buy, log out and in, cancel, refund, and try the billing page as a free user.
Switch to live mode, copy over the live keys and add the live payment-message address. Don't test with your own real card: Polar and Stripe both ask you not to. On Polar, a 100% discount code made just for you lets you check the live setup. On Stripe, double-check the live settings and watch your first real sale closely.

Step 7 is the one people skip, and it's the one that saves you from angry emails.

The one-prompt way: ShipToPaid

I got tired of writing those prompts by hand and fixing the same mistakes, so I turned the tested steps into written instructions, called skills, that Claude Code, Cursor and Codex can follow. That's ShipToPaid.

Instead of steps 3 to 6 above, you type /add-paywall in your agent, say whether you want one-time or subscription, and it follows a checklist that already covers the traps: checking that payment messages are real, handling cancellations and failed payments, and locking paid pages properly. A launch audit then walks you through the testing.

Want to try it first? The free lite pack on GitHub includes Polar checkout, Polar payment messages and a short launch check. The full pack adds Stripe, subscriptions that control access, a customer billing page, credits, license keys and a working Next.js starter app. Every skill is a plain file you can read and change.

You don't need either to use this guide. Pick how you'll charge, pick a payment company, test the whole flow in test mode, and go get your first paying customer.

This post first appeared on the ShipToPaid blog.

How to Add Payments to an App You Built With AI (Without It Breaking)

Supermax — Sat, 17 Oct 2026 04:56:35 +0000

You built an app with Claude Code, Cursor or Codex. It works, and people like it. Now you want to charge for it, so you type "add payments" into your agent, and a few minutes later there's a checkout button. It feels done.

It usually isn't. I'm Deepak, a solo developer in Hyderabad, and I've spent a lot of time wiring payments into apps built with AI agents. The checkout button is the easy part. The bugs hide in what happens after someone pays, and they don't show up in a demo. They show up when your first real customer emails you asking why they can't get in.

This is the guide I wish I'd had: how the money moves, the five mistakes I keep seeing, how to check for each before launch, and how to choose between Polar and Stripe. You don't need to read any code to follow it.

How the money actually moves

Here's the whole flow in plain words:

A customer clicks "Upgrade" in your app.
Your app sends them to a checkout page run by the payment company (Polar or Stripe). They type their card details there, not in your app. That's a good thing: you never touch card numbers.
The payment goes through, and the customer is sent back to your app's "thank you" page.
Separately, behind the scenes, the payment company sends your app a short message: "this person just paid for Pro." Developers call this a webhook. I'll just call it the payment message.
Your app reads that message, checks that it's real, and writes down in your database: "this person has Pro."
Every time that person opens a paid page, your app checks what it wrote down before letting them in.

The key idea: the thank-you page proves nothing. Anyone can visit a thank-you page. The payment message in step 4 is what should unlock things. Similar messages later tell your app when someone cancels, gets a refund, or their card stops working. Almost every bug I see lives in steps 4 to 6.

The five things that go wrong (and how to check each one)

1. The customer pays, but stays locked out

What happens: checkout works and the money arrives, but the app never updates the customer's account. Usually the payment message never reaches the app, or it arrives and gets ignored. Sometimes the app can't match the payment to the right person, for example when they used a different email at checkout.

How to check: in test mode, sign up as a brand-new user, pay with a test card, and see whether the paid features unlock without you touching anything. Then log out, log back in, and check they're still unlocked. If you ever have to fix someone's account by hand, it's broken. Also open your payment company's dashboard: it shows whether its messages to your app were delivered or failed.

2. Cancelled users keep the paid features

What happens: someone cancels, but your app never takes access away. There's a sneakier version too: payment messages can arrive late and out of order. An old "this person is active" message shows up after the "cancelled" one, and your app happily gives access back.

How to check: in test mode, subscribe and then cancel. Access should last until the end of the period they paid for, and then stop. Not right away, and not never. Do the same with a refund. Then ask your agent: "If an older payment message arrives after a newer one, does the app ignore it?"

3. Fake payment messages unlock premium

What happens: your app has a public address where it listens for payment messages. If it doesn't check that each message really came from Polar or Stripe, anyone who finds that address can send a fake "this person paid" message and get premium for free. Payment companies stamp every message with a secret so your app can tell it's genuine, but AI agents sometimes skip that check, or get it wrong and then "fix" it by switching the check off.

How to check: ask your agent to send a made-up "payment succeeded" message to your app without the secret stamp. Your app must reject it. If it unlocks anything, stop and fix that before launch. While you're there, make sure the secret is stored in your app's settings, not pasted into the code.

4. The AI invents payment features that don't exist

What happens: payment companies update their tools often, and AI agents learned from older versions. So the agent confidently writes something that looks right but uses options that were renamed, removed, or never existed. The worst case is when it fails quietly and you only find out when a real payment doesn't unlock anything.

How to check: tell your agent to follow only the payment company's official docs for the version your app actually uses, and to tell you which doc page each step came from. Then run the full flow in test mode, from clicking "Upgrade" to seeing paid features unlock. "It builds without errors" is not the same as "it works."

5. The billing page breaks for free users

What happens: you add a "Manage billing" button so customers can update their card or cancel. A free user clicks it, and because they've never paid, the payment company has no record of them, so the page shows an error.

How to check: log in as a free user who has never paid and click everything billing-related. Either hide "Manage billing" from people who never paid, or show them a friendly "You're on the free plan" message instead.

One bonus check if you have more than one plan: buy the cheapest one and make sure it never unlocks the features of a more expensive one.

A simple pre-launch checklist

Run through this in test mode before you switch to real money. It doesn't take long, and it heads off the "I paid, why can't I get in?" emails.

A brand-new user pays with a test card, and paid features unlock on their own.
They log out and back in, and features are still unlocked.
They cancel, and access ends at the end of the period they paid for.
They get a refund, and access goes away.
A fake payment message without the secret stamp is rejected.
A free user opens the billing page, and nothing breaks.
The cheapest plan never unlocks a more expensive plan.
Your payment dashboard shows messages to your app as delivered, not failing.
Your secret keys live in your app's settings, not in the code.
Terms, Privacy and Refund pages exist and are linked from your site. Payment companies often ask for them.
After going live, you make one real purchase yourself with a real card, check that it unlocks, then refund it.

That last one matters. Test mode and live mode use separate keys and settings, and it's easy to update one and forget the other.

Polar or Stripe, in plain terms

Both are solid. The biggest practical difference is who deals with sales tax.

Polar is what's called a merchant of record. In plain words, Polar is the seller on paper: it collects and pays sales tax and VAT in the countries your customers buy from, then pays you out. For a solo maker selling worldwide, that removes a pile of paperwork. The trade-off is a higher fee per sale than Stripe's basic rate, so check their current pricing.

Stripe processes the payment, but you are the seller, so tax is your job. Stripe has a tax add-on that can work out and collect the right amount, but registering and filing is still on you. In return you get more control, which suits you if you already have a Stripe account or need something specific.

My rule of thumb: if you're solo, selling a digital product or subscription to people in many countries, and you don't want to think about tax, start with Polar. If you already use Stripe or have a business set up to handle tax, use Stripe. Either way, before you build anything, check that the one you pick can pay out to your country. And if tax questions worry you, a short chat with an accountant is worth it.

The checks above apply to both: the bugs are about how your app reacts to payments, not which company handles them.

Where ShipToPaid fits

I hit every one of these problems myself while building a real app, so I turned the fixes into written instructions, called skills, that Claude Code, Cursor and Codex can follow. That's ShipToPaid. Instead of hoping your agent remembers to check the secret stamp or ignore late messages, you type a plain request like "/add-paywall add payments to my app," and it follows tested steps with those traps already written down. A launch audit then walks through a checklist like the one above.

If you want to see how it works first, there's a free lite pack on GitHub with three skills: Polar checkout, Polar payment messages, and a short launch check. The full pack adds Stripe, access that follows payments, a customer billing page, credits, license keys, five ready-made commands and a working Next.js starter app. Every skill is a plain file you can read and change.

You don't need either one to use this guide. Run the checklist in test mode, fix whatever fails, and your first paying customer will get exactly what they paid for. That's the whole goal.

This post first appeared on the ShipToPaid blog.