Billing Infrastructure for Multi-Tenant SaaS
1 master key, N independent ISCA chains. Each seller on your platform gets their own SHA-256 fiscal ledger — without you touching their accounting.
$api = ScellApiClient::withApiKey('sk_live_...');
$invoice = $api->invoices()->builder()
->outgoing()
->facturX()
->issueDate('2026-05-16')
->dueDate('2026-06-15')
->buyer('98765432109876', 'Acme SARL',
new Address('2 av Client', '75002', 'Paris'))
->addLine('Consultation', 10, 150.00, 20.0)
->create();
echo $invoice->invoice_number; // FAC-202605-00123✓ FAC-202605-00123 — PDF/A-3b + XML CII EN16931
Typical client context
Thomas Renard
CPO Marketplace B2B
20–200 ETP · Node.js / React
“Thomas leads product at a B2B catering marketplace with 200 active suppliers. Each supplier must issue Factur-X invoices to their restaurant clients since 2026. Thomas wants to include e-invoicing in the Pro plan without building a fiscal ledger in-house.”
Common blockers
- 1Building an ISCA fiscal ledger for each seller in-house costs 3–6 months of development
- 2A flaw in a sub-tenant's fiscal chain can reflect on the platform's DGFiP liability
- 3Onboarding new sellers onto Peppol (SuperPDP) is a complex KYB process to manage
- 4Each seller's ISCA chains must be strictly isolated — one seller must never see another's data
- 5Billing e-invoicing as a premium feature requires dedicated infrastructure that few SaaS have
- 6B2B buyers have required Factur-X since 2026 — sellers without a solution lose contracts
The Scell.io response
Scell.io exposes the full B2B2B architecture: 1 master `sk_*` key → N isolated sub-tenants. For each seller: `POST /api/v1/sub-tenants` + `sub_tenant_id` in each invoice payload. The `<scell-onboarding>` widget handles the 5 Peppol onboarding steps (SuperPDP KYB, PKCE OAuth2, status polling) — your platform only calls one webhook when the seller goes `active`. Each ISCA chain is computed independently per `(tenant, sub_tenant)` pair — bug isolation guaranteed by `SECURITY DEFINER` PostgreSQL triggers, not application code.
B2B2B architecture
1 master `sk_*` key, N sub-tenants via `sub_tenant_id` in payload, no per-seller key
Widget `<scell-onboarding>`
3 HTML lines, 5 SuperPDP KYB steps handled, `active` webhook when ready
ISCA isolation per pair
each SHA-256 chain is independent, PostgreSQL triggers, no application code
Managed SuperPDP KYB onboarding
polling every 15 min, automatic welcome email to seller, 0 dev to write
Daily closing per sub-tenant
S3-signed market-format CSV, Bitcoin OTS anchor, `GET /fiscal/integrity`
Usage-based pricing
€0.04/invoice + €1.20/signer, no limit on number of sub-tenants
Context & stakes
The 2026 e-invoicing reform creates a structural problem for multi-tenant SaaS and marketplaces: each of your sellers or customers must have their own certified fiscal space, their own ISCA hash chain, their own access to the Peppol network via SuperPDP. Building this infrastructure in-house takes 3–6 months of development, a permanent DGFiP compliance risk and significant maintenance cost. Scell.io's sub-tenant architecture solves this structurally. A master `sk_*` key covers the entire platform. Each seller is created as a sub-tenant via an API call or the `<scell-onboarding>` widget embeddable in 3 lines of code. Each sub-tenant has an isolated ISCA chain — a bug or corruption on one seller's chain never affects others. KYB onboarding to SuperPDP is managed by Scell.io via polling every 15 minutes.
Real-world use cases
- B2B services marketplace with 50–500 suppliers issuing independent Factur-X invoices
- ERP SaaS including e-invoicing in its Pro plan — each customer has their own ISCA chain
- Freelance platform whose contractors invoice clients with Peppol-compliant Factur-X
- Neobank offering certified e-invoicing as a differentiating service for their business account
- Real estate SaaS where each agency issues its own mandate and fee invoices under an ISCA chain
- B2B e-commerce platform where each seller has their own isolated fiscal audit trail
Frequently asked questions
How many sub-tenants can be created with a Scell.io master key?
There is no technical limit on the number of sub-tenants. Pricing is based on invoice and signature volumes issued, not on the number of sub-tenants. A marketplace with 500 sellers can have 500 active sub-tenants under a single `sk_*` key — the cost is €0.04 per invoice issued by each seller, regardless of the number of sellers.
How does data isolation between sub-tenants work?
Isolation is guaranteed at multiple levels: (1) every invoice, credit note and ledger is scoped by `(tenant_id, sub_tenant_id)`; (2) `BuyerPolicy` verifies ownership on every access; (3) ISCA SHA-256 chains are computed independently per pair via `SECURITY DEFINER` PostgreSQL triggers. A bug or corruption on one sub-tenant's chain never affects others — this is a database guarantee, not an application code guarantee.
Does the `<scell-onboarding>` widget handle SuperPDP KYB onboarding?
Yes. The widget orchestrates 5 steps: identity (email, SIRET, name, phone) → Sirene verification → Scell account creation → SuperPDP PKCE OAuth2 authorization (popup) → final status. If SuperPDP fails, the sub-tenant is created with `pending_superpdp` status and can issue B2C invoices immediately. The switch to electronic Peppol is automatic when KYB passes `verified`.
How is the `sub_tenant_id` passed in API calls?
Simply add `"sub_tenant_id": "uuid"` to the JSON payload of each call. Without `sub_tenant_id`, the action is on behalf of the master tenant. With it, the action is on behalf of the specified sub-tenant — `IssuerResolver` verifies the sub-tenant belongs to the current tenant (anti-IDOR: returns 404 otherwise).
Is Scell.io's multi-tenant invoicing compliant with DGFiP audits?
The ISCA architecture implements SHA-256 hash chains isolated per `(tenant, sub_tenant)` pair, PostgreSQL `SECURITY DEFINER` triggers guaranteeing recording outside application code, Bitcoin OpenTimestamps anchoring and a public integrity endpoint `GET /api/v1/fiscal/integrity`. This is a self-certification — not an NF525 certification by a third-party body.
Can the onboarding widget be customized to match our platform's branding?
The `<scell-onboarding>` widget uses a `pk_*` (publishable key) and integrates in 3 HTML lines. Appearance customization (colors, logo) is in the phase 3 roadmap. Meanwhile, the widget is neutral. The tenant can configure their logo and primary color via `PUT /api/v1/auth/tenant/profile`.
Give each seller their own ISCA ledger in one day
POST /api/v1/sub-tenants + sub_tenant_id in the payload. KYB SuperPDP onboarding widget in 3 HTML lines. Independent ISCA chains per pair.