[ Removed by moderator ]

[u/Significant_Rate5448]

[u/webdev-ModTeam]

Your post/comment has been determined to be a low-effort post or comment. This includes title-only posts, easily searchable questions, vague/open-ended discussion prompts, LLM generated posts or comments, and posts/comments that do not provide enough context for meaningful replies or discussion.

[u/Background-Catch4359]

I wouldn’t build payouts before you need them, but I would make sure the provider you choose can support that direction. There’s a difference between not implementing something yet and choosing an architecture that makes it painful later.

[u/Significant_Rate5448 → u/Background-Catch4359]

don’t wanna build for users I don’t have yet lol, but also don’t wanna redo the whole payment setup later. What do I have to check so I can leave the door open to that later?

[u/Background-Catch4359 → u/Significant_Rate5448]

I just shipped with checkout and subs, nothing fancy. I mainly made sure the payment logic wasn’t one giant monolith so I wouldn’t have to rip everything out later. I went with Whop for that layer and subs have been straightforward but I’ve still got the option to add things like international payments and payouts if the product gets there. I recc build what you need now, just don’t box yourself into a setup that’s painful to expand later.

[u/Significant_Rate5448 → u/[deleted]]

Thats what Im leaning toward too, just to get checkout and subscriptions working and ship. The only thing making me look beyond the obvious option is whether something else makes more sense if payouts become part of the product later.

[u/webdev-ModTeam → u/[deleted]]

Your post/comment has been determined to be a low-effort post or comment. This includes title-only posts, easily searchable questions, vague/open-ended discussion prompts, LLM generated posts or comments, and posts/comments that do not provide enough context for meaningful replies or discussion.

[u/andrewsmd87]

You're over engineering it. Build out the MVP and deal with international stuff when you actually have the issue.

Assuming you are using a third party payment processor, they can likely handle international payments for you anyways and they will do a better job at it than anything you try to build.

Just let them handle it for you, take their cut, and move on with your project.

As someone who leads teams I see this a lot with younger engineers and your goal here is to literally build the least amount of features you can to think it's viable, get it to market, and see if it lands. Spoiler, most ideas don't. And that's not because you did a bad job, it's the nature of building something new.

[u/Digital-Chupacabra]

None.

If your building your own payment solution for a real product then you're making a mistake. It's FAR better to use one of the many well tested, well regulated, existing solutions.

As to worrying about all the possibilities, solve the problems your actually facing, otherwise you could spend years solving problems that won't matter.

[u/Significant_Rate5448 → u/[deleted]]

this is maybe the approach i had in mind but im curious what did you use for payments? im trying to keep things simple now without choosing something I ll have to completely replace later on

[u/Born-South2361 → u/Significant_Rate5448]

I used Whop for my saas, handles subs and payouts without needing to swap later. Kept it simple upfront and didn't have to rip anything out

[u/webdev-ModTeam → u/[deleted]]

Your post/comment has been determined to be a low-effort post or comment. This includes title-only posts, easily searchable questions, vague/open-ended discussion prompts, LLM generated posts or comments, and posts/comments that do not provide enough context for meaningful replies or discussion.

[u/irajangpt]

Ship checkout and subscriptions now, but do the two things that are painful to retrofit. Store the provider's customer and subscription IDs on your own user record, and make the webhook handler idempotent by saving processed event IDs, so a retried event can't double-activate a plan. Payouts can wait until you need them, and when you do, most of the work is onboarding the people you pay, which the provider handles in its own flow.

[u/winky9827]

I typically build with a dummy payment provider. It's one of the last things I'll implement. Caveat: you need to know your intended currency support and plan for that up front regardless.

[u/pdfops]

Just wire up Checkout + Billing for subscriptions now and don't overbuild. The checkout/subscription layer is cheap to swap later since it's mostly API calls, the part that actually hurts to retrofit is payouts to users (Connect, KYC, tax forms) because that touches your data model and onboarding flow, not just billing code. If payouts are a "maybe later" thing, at least leave a nullable stripe_connect_id type field on your user model now so you're not doing a schema migration under pressure when it becomes real.