Why SNDR bills in USD through Paddle — and what that means for Saudi customers

When we started SNDR, the plan was to bill in SAR through a local processor. The thinking: local cards, native Riyal pricing, VAT handled by us. Five months in, we made the opposite call — SNDR now bills in USD through Paddle, who acts as our Merchant of Record. Here is why.

The wedge: tax compliance

The moment a Saudi software company sells outside KSA, the tax surface explodes. Customers in the EU need their reverse-charge VAT handled correctly. Customers in the UK need a separate tax registration. Customers in California need sales tax collected at checkout. Doing this right means staffing a finance function. Paddle, as Merchant of Record, owns all of that — they sell to your customer, collect any applicable tax, remit it to the right authority, and pay us a fixed share.

What we gave up

SAR-native pricing. Paddle does not support SAR as a billing currency — we verified this against their official OpenAPI spec, which enumerates exactly 31 supported currencies. SAR is not on the list, and neither is AED. So our list price is in USD ($12 / month for Pro, $75 / month for Scale), and Saudi customers see an approximate SAR figure rendered next to each price for context. Your bank settles the actual amount in SAR at its FX rate — usually within 3% of the published number.

Why the trade-off lands

For our customer profile — developers and small teams who already pay GitHub, Vercel, Linear, Cloudflare, and OpenAI in USD — adding one more USD invoice is not a behavioural change. The teams who would have noticed SAR-native pricing the most are also the teams already doing FX conversions for every other tool in their stack. The cost of staffing a finance team to do MoR-equivalent tax work ourselves would have shown up in higher prices for everyone.

The mechanics

On the integration side: we create a Paddle Customer for the user on first checkout, generate a Transaction with the right Price ID and our SNDR org_id / plan_slug stuffed into custom_data, then redirect to Paddle’s hosted checkout. A signed webhook tells us when the transaction completes and we flip the org to the new plan. Cancellation, refund, dunning, and tax invoices all live on Paddle’s side; we read state from webhooks and never directly handle a card number.