Stripe does not work in Bangladesh. Here is what actually does.

Every few weeks someone building a product from Bangladesh — or Pakistan, or Nigeria — hits the same wall. They have built the thing. They wire up Stripe. Stripe asks for a business registered in a supported country, and Bangladesh is not on the list.

Then the workarounds start: a friend's US LLC, a relative's account abroad, a service that promises to "solve" this for a percentage. All of these carry real risk, and most of them violate someone's terms of service.

Here is the actual map, verified against the providers' own documentation, and the architectural consequence that most people miss until it costs them.

What is unavailable

Stripe does not support Bangladesh as a merchant country. Its signup expects a business incorporated in a supported jurisdiction with a matching local bank account.

PayPal lets people in Bangladesh send money and, through Xoom, receive remittances. It does not issue a Bangladeshi merchant account for taking card payments on your own site. These are different products and conflating them wastes a lot of time.

Wise offers personal accounts in Bangladesh. Personal accounts cannot receive business payments. The multi-currency receiving details that make Wise so useful elsewhere are not available here.

What works, and for what

The critical thing — the thing that changes your architecture — is that the answer is not one provider. It splits by what you are selling.

Digital products and SaaS: a merchant of record

A merchant of record sells your product on its own behalf and remits your share. It handles global VAT and sales tax, which is otherwise a genuinely hard problem, and it does not require you to be incorporated in its country.

Lemon Squeezy lists Bangladesh among its supported bank-payout countries. Paddle and Polar operate the same model.

This works for software, SaaS subscriptions, templates, component libraries, eBooks and courses.

Services: not a merchant of record

This is the part that catches people, and it is worth reading twice.

Lemon Squeezy's prohibited-products list includes, verbatim:

Services of any kind (including marketing, design, web development, consulting or other related services)

Not a grey area. Selling a web-development package, a retainer, a consultation or a design service through it puts your store at risk of being placed in review or suspended without notice. Paddle and Polar have equivalent restrictions — it is inherent to being a merchant of record, because they cannot be the legal seller of a service they do not perform.

The same list also prohibits "advertising in newsletters, on websites, or in social media posts", which means blog and newsletter sponsorships cannot be billed through it either, and "job boards".

One more trap worth flagging: "business-in-a-box" appears in their regulated-products list, alongside get-rich-quick schemes. A website template product is perfectly legitimate — but do not name it "industry-in-a-box", because you are naming your product after a phrase on the prohibited list.

So for service work, what is left is:

• Payoneer payment requests — the practical default for international B2B. You send an invoice, the client pays by card or bank transfer, funds land in your Payoneer balance and withdraw to a local bank in taka.
• Bank transfer — slower, higher friction, but appropriate for larger engagements where the fee percentage matters more than the convenience.
• bKash merchant and SSLCommerz — for clients inside Bangladesh.

What this means for pricing pages

There is no instant card checkout for service work from Bangladesh. Not at $199, not at $19,000.

That is a real constraint and it should shape the page. A "Buy now" button that leads to an invoice request is a broken promise; a clearly-labelled "Request this package — invoice sent the same day" is an honest one, and it converts better than a button that does something other than what it says.

The architectural consequence

Most payment abstractions are written to select a provider by currency or country. If you do that here, you will eventually route a service purchase to a merchant-of-record checkout, and find out about it when your store is suspended.

The first discriminator has to be what kind of thing is being sold:

type TransactionKind =
  | 'service_engagement'   // custom work, retainers, consultation
  | 'digital_product'      // templates, starter kits, ebooks
  | 'subscription'         // your own SaaS
  | 'sponsorship';         // blog or newsletter placements

// Resolution order that reflects the actual constraints:
//   transactionKind -> customerType -> country -> currency -> provider

Currency and country still matter, but they matter after the policy question has been answered.

If you can, push the constraint down into the schema rather than leaving it to application logic. On this site, the services table simply has no checkout_url column. Not "has one and we are careful not to fill it in with a merchant-of-record link" — it does not exist. A future version of me, in a hurry, cannot violate the policy by accident, because there is nowhere to put the mistake.

That is generally the better move when a constraint is external and permanent: encode it in a place where violating it is not expressible.

The honest summary

Being outside the supported-country list is a real disadvantage. It costs a percentage and adds friction, and pretending otherwise helps nobody.

But it is workable, entirely within everyone's terms of service, and it is worth an afternoon to set up properly rather than a year of hoping nobody looks closely at whose LLC that is.