SaaS payment processing is easy to treat as a final integration: build the product, add a checkout, then start collecting revenue. A recent post in r/SaaS is a painful counterexample—and a useful lesson for every indie founder: a product is not truly launch-ready until its creator can legally and reliably get paid.
The post, written by an Iranian developer, describes spending roughly five months building three SaaS products before discovering that mainstream international payment options were unavailable to him. After months spent investigating alternatives, the products remained unlaunched—not necessarily because the ideas lacked merit, but because monetization infrastructure was inaccessible. (reddit.com)
The story drew sympathy, but the most valuable community response was practical. Commenters urged the founder to seek users before revenue, consider selling a validated asset, and investigate legitimate business partnerships or merchant-of-record arrangements. The crucial caveat: none of those paths should be assumed to solve sanctions, banking, tax, identity-verification, or payout restrictions.
The overlooked dependency in SaaS payment processing
Founders are trained to validate demand: talk to customers, build a landing page, run a preorder, and measure willingness to pay. But willingness to pay is only one part of the transaction. A viable SaaS business also needs a lawful path to onboard a merchant, accept funds, manage recurring billing, issue refunds, handle tax obligations, and receive payouts.
That full chain can fail for reasons unrelated to product quality. Geography, residency, legal entity structure, banking access, identity verification, supported payout countries, customer location, sanctions screening, and a processor’s own risk policies can all determine whether a founder can operate.
This is particularly stark for entrepreneurs in sanctioned jurisdictions. OFAC’s Iran-related rules generally restrict many direct and indirect transactions involving Iran when there is a U.S. nexus, unless an activity is exempt or authorized. Its guidance also specifically identifies concealing Iranian involvement in cross-border payment flows as an evasive practice. (ofac.treasury.gov)
That means casual advice such as “just open a foreign LLC,” “use someone else’s account,” or “take crypto” is not a business strategy. It can create serious legal, contractual, tax, fraud, and account-closure risks. A lawful structure requires accurate disclosures, genuine ownership and control arrangements, and professional advice appropriate to the jurisdictions involved.
Why merchant-of-record tools are not a universal workaround
Several commenters suggested merchant-of-record, or MoR, services. The model is useful to understand: the MoR is the legal seller in the customer transaction and typically handles payment collection, tax, refunds, chargebacks, and PCI-related responsibilities. (docs.lemonsqueezy.com)
For a founder in a supported jurisdiction, that can reduce global selling complexity dramatically. It does not, however, guarantee eligibility for every seller everywhere. Merchant-of-record providers still conduct compliance reviews, follow banking-partner rules, and maintain country restrictions.
Paddle, for example, says it cannot support suppliers operating from listed unsupported countries due to sanctions, anti-money-laundering requirements, and banking-partner policies; Iran is explicitly included on its current list. It also says the list may change and that it may request further information before releasing payments. (paddle.com)
The lesson is bigger than any single provider: founders should distinguish between a payment product’s customer coverage and its merchant eligibility. A checkout may accept buyers in dozens of markets while the platform cannot onboard a founder where they live or cannot pay out to their bank account.
A launch-readiness checklist before you write the full product
The r/SaaS poster later acknowledged a hard truth raised by commenters: payment feasibility should have been checked earlier. That is not a reason to blame a founder facing structural constraints. It is a reason to make operational validation as normal as market validation.
Before committing months to a SaaS build, verify these items:
- Merchant onboarding: Can you personally and truthfully pass verification with at least one processor or MoR? Check residency, entity, beneficial-owner, identification, and business-document requirements.
- Payout capability: Can the provider send money to a bank account you legitimately control, in a supported country and currency? Do not confuse buyer acceptance with seller payouts.
- Compliance fit: Check sanctions, export controls, prohibited-business policies, and customer-location restrictions. These are not checkbox details to solve after launch.
- Billing requirements: Confirm support for subscriptions, invoicing, trials, refunds, chargebacks, taxes, and the payment methods your target customers actually use.
- Failure plan: Identify a second compliant provider, exportable customer and billing data, and a process for what happens if an account is paused for review.
- Local professional review: Where cross-border ownership, sanctions, or tax exposure is involved, speak with a qualified lawyer or accountant before relying on an online workaround.
This takes hours or days, not five months. It also sharpens product strategy. If a founder cannot take international card payments today, they may decide to build for a domestic market, offer services through an employer or licensed partner, pursue open-source adoption, or develop an asset designed for acquisition. None is equivalent to unrestricted global SaaS revenue, but each is more grounded than discovering the constraint at launch.
If you cannot monetize yet, validate the asset anyway
The strongest constructive suggestion in the thread was to launch a free version and seek traction. That does not remove the founder’s payment problem, but it can change the economics of the project.
A codebase with no users is mostly a claim: it may be technically polished, but nobody knows whether a market wants it. A product with active users, usage data, testimonials, retention evidence, a clear acquisition channel, and a waitlist for paid features is different. It becomes proof that the underlying problem is real.
For founders blocked from immediate monetization, a free or open-core launch can create several options:
- Validate which of several ideas has genuine demand.
- Build an audience and email list that a future compliant operator can serve.
- Create evidence for a legitimate co-founder, distributor, employer, or acquirer.
- Learn whether users will pay before negotiating any commercial arrangement.
- Package the product as a saleable asset rather than an untested code repository.
There are limits. Free users do not pay infrastructure bills, and traction does not solve legal eligibility. But it can prevent the second mistake: assuming that a finished product is automatically a business. As one thread participant put it, visitors and users provide proof of concept in a way an unlaunched product cannot. (reddit.com)
Build for the whole business, not just the demo
The deeper issue in this story is not simply that one developer missed a Stripe integration. It is that the startup world often presents global software entrepreneurship as an even playing field: build online, sell worldwide, and let code erase borders.
In practice, the internet is global while the financial system is jurisdictional. Even exceptions meant to support internet access do not automatically authorize commercial hosting or payment operations; OFAC’s updated guidance, for instance, distinguishes certain communications-related authorizations from web-hosting services for commercial entities located in Iran. (ofac.treasury.gov)
For founders with easy access to payments, this should create humility and better habits. Treat SaaS payment processing as core product infrastructure. Validate it before the feature list gets long, document it alongside your technical architecture, and never advise someone in a restricted jurisdiction to obscure their location or ownership.
For founders who face these barriers, the immediate goal may not be a perfect workaround. It may be preserving optionality: validate demand, collect credible evidence, build public proof, and seek properly structured opportunities rather than risky shortcuts. That is not a complete answer to unequal access, but it is a more honest foundation for the next move.
Conclusion: payments are part of product-market fit
A SaaS launch is not complete when the app works. It is complete when customers can discover it, buy it, receive value, get support, and pay through a system that can legally deliver revenue to the business behind it.
The r/SaaS post is a reminder that founders should test their business model as rigorously as their software. Product-market fit matters, but so does payment-market fit: the practical ability to sell, settle, and sustain the company you are building.