Listen to this article:

0:00

The system behind SampleHQ – and how founders in “unsupported” countries can build the same thing.

Most articles about SaaS billing assume you live in the U.S., U.K., or West EU and can just “plug in Stripe.”
But what if you live in a region where Stripe and PayPal don’t exist?

North Macedonia? Serbia? Albania? Bosnia? Georgia? Turkey? Montenegro? Half of Africa? Middle East?
You’re locked out.

Unless you build your own system.

This is the story of how I built a fully automated payment + SaaS provisioning pipeline using Paddle and WordPress Multisite, where:

A customer pays
A webhook fires
A brand-new WordPress subsite is provisioned
A user is created
They auto-login
Their SaaS instance is ready in seconds

And I did all of this from a country Stripe ignores.

This article isn’t just a technical breakdown – it’s a roadmap for anyone outside Stripe land who wants to build SaaS properly, get paid internationally, avoid VAT nightmares, and reach global customers legally and automatically.

Let’s get into it.

The Problem: Payments + SaaS Provisioning Without Stripe

If you run a SaaS where each customer needs their own “space” (like a WordPress site, workspace, app instance, etc.), the flow looks like this:

Customer pays
You manually create their instance
You send credentials
They finally log in

This falls apart at scale.

And if Stripe doesn’t exist in your country?
You’re basically locked out of normal SaaS architecture.

I refused to accept that.

The Breakthrough: Paddle + WordPress Multisite

Paddle became the perfect solution because:

They act as merchant of record
They handle VAT, sales tax, compliance
They allow global payouts (even to unsupported countries)
They don’t require a U.S./EU company
They work beautifully with subscription SaaS
Their new API (Paddle v2) is modern and clean

That unlocked the possibility to automate everything:

➡️ Payment → Webhook → User Created → Site Created → Auto-Login → Ready to use

All in seconds.

For anyone outside Stripe countries, this is the method.

How the System Works (High-Level)

1. Customer completes checkout (Paddle.js v2)

Frontend checkout is embedded directly into my WordPress pages.

Customers pick a plan → Paddle handles pricing → Checkout opens → Done.

2. Paddle fires a webhook

The webhook arrives at the main WordPress network site.

3. A user account is automatically generated

Using payment metadata, name, email, subscription ID, etc.

4. A WordPress subsite is provisioned

The system:

Creates a new subsite
Assigns the user as owner
Applies plan-specific settings
Activates plugins automatically
Seeds initial content if needed

5. The user is auto-logged in via magic link

No password.
No friction.
No onboarding friction.

6. Subscription lifecycle is tracked globally

Upgrades, downgrades, renewals, past-due statuses, cancellation, everything.

This is how SampleHQ provisions entire SaaS instances in seconds.

The Architecture (In Plain English)

Payment Layer

Paddle.js v2 checkout
AJAX endpoints for creating sessions
Plan/price retrieval

Webhook Processor

HMAC signature verification
Full idempotency
Event storage
Asynchronous processing

Multisite Engine

Programmatically creates subsites
Handles domain/subdomain
Activates defaults per plan

User Manager

User creation
Role assignment
Automatic login via token

Subscription Manager

Updates plan state globally
Handles renewals / failures
Manages trial periods

Why This Matters for Founders Outside Stripe Countries

This is the part nobody on YouTube tells you.

You can build a SaaS and accept global payments – legally – even if you’re outside Stripe/PayPal territory.

Paddle solves everything that founders from underserved regions struggle with:

✔ No U.S. company needed
✔ No U.S. bank needed
✔ They collect and file VAT for you
✔ Global payments: cards, Apple Pay, Google Pay
✔ They pay you via bank transfer anywhere in the world
✔ They accept Balkan/Eastern Europe companies
✔ You can sell subscriptions legally
✔ Full SaaS billing logic built-in

This is the exact stack I use to run SampleHQ from North Macedonia – and it works flawlessly.

If Stripe doesn’t support your country, this is your path.

Technical Deep Dive (For the Developers)

Below is the condensed breakdown, tuned for devs who want to implement the same model.

Webhook Reliability (The Hard Part)

Webhooks:

Come out of order
Duplicate
Delay
Drop

Solution:

Idempotency via Paddle transaction_id
Store every raw webhook event
Process only once
5-minute cron job to catch missing provisioning
Retry logic
Full audit logs

Magic Link Authentication

WordPress doesn’t support passwordless login natively, so I added:

Token creation (sha256 signed)
15 minute expiry
Single-use
Auto-redirect to new site
No passwords needed ever

This is one of the biggest user-experience boosts.

Database Structure

Global tables:

shq_subscriptions
shq_transactions
shq_webhook_logs

Indexes:

(user_id, status, created_at)
(subscription_id)
(site_id)
(transaction_id)

This makes everything fast, even on large networks.

Provisioning Flow (Bulletproof Logic)

Has user been created?
Has site been created?
Has user been added to site?
Has site been configured?
Has magic link been sent?
Has login token been consumed?

Every step logs to database + file logs.

If something fails, the system retries automatically.

Scaling the System

Right now, the system easily handles:

Hundreds of subsites
Thousands of webhook events
Fast provisioning
Full subscription lifecycle

Scaling roadmap:

Redis object cache
Queue system for webhooks
Custom domain assignment
Regional data centers

If You Want to Build Something Similar

Here’s the tl;dr blueprint:

1. Use Paddle (not Stripe) if your country is unsupported

They solve payments, billing, tax, compliance, and legality.

2. Use WordPress Multisite as your SaaS engine

It’s massively underused but perfect for multi-tenant SaaS.

3. Automate provisioning end-to-end

Never manually create a customer instance again.

4. Implement magic link authentication

Removes friction instantly.

5. Make everything idempotent

Payment events must be bulletproof.

6. Log everything

It’s your best debugging partner.

Real Talk: Why This Matters

Founders in the Balkans, Eastern Europe, Asia, LATAM, and Africa are often blocked from building SaaS because Stripe and PayPal are unavailable.

I built this system because I refused to let geography limit me.

If you’re in a region the tech world ignores, you don’t need permission.
You need the right architecture.

And with Paddle + WordPress Multisite, you can build a global SaaS product that:

gets paid
auto-provisions
scales
stays compliant
works everywhere

How I Built a Payment-to-Site Creation Pipeline That Creates WordPress Sites in Seconds (Without Stripe or PayPal)