Appearance

ADR-0030 · Tenant communication identity & credit monetization ​

Status: 🟡 Proposed — raised by the owner 2026-08-22 (merchant/enterprise custom branding + prepaid communication credits as a monetization layer) · Extends:ADR-0029 · Depends on:ADR-0021 (limits and entitlement axes), ADR-0025 (the ledger.unit condition), ADR-0002 (Model A collection), ADR-0024 / ADR-0028 (where an org admin's controls may live)

Context ​

ADR-0029 established WhatsApp via Meta Cloud API direct, with QRSETU as the single sender of record in R1 and per-tenant senders deferred to "P3+". The owner has now asked the question that decision deferred: can a merchant or enterprise send under their own branding while QRSETU runs the infrastructure, and can QRSETU sell prepaid communication credits against the traffic?

Full assessment, with the tier table and every measured fact: the tenant model.

Both are possible. The shape is not the obvious one. Four verified constraints determine it:

  1. What isolates. Branding is per phone number (display name plus the whole business profile including logo, settable via POST /{phone_number_id}/whatsapp_business_profile). Templates are WABA-scoped with no phone-number parameter or filter, messaging limits became per business portfolio on 2025-10-07, and enforcement is account-level (waba_ban_state, ladder including "a 5, 7, or 30 day block on sending any messages").
  2. A WABA per client is contractual. Meta's Terms for Service Providers: "You are solely responsible for (a) creating a WABA account for each Client", plus an obligation to "assist your Client to transfer the WABA account" within 30 days of request. A shared account cannot honour that transfer clause for any one tenant.
  3. Meta invoices the account owner — with exactly one documented exception: a Solution Partner's credit line attached to a client-owned account, after which "You are the 'Bill To Party' … liable for and will pay Meta for all WhatsApp Business Platform spend made by these businesses." Real API (whatsapp_credit_sharing_and_attach), INR supported. Tech Providers have no credit lines; their customers attach their own card and Meta bills them directly.
  4. ⚠ Credit-line attachment is one-way: "Credit lines cannot be changed after being attached to a WABA. If the WABA needs a different credit line, a new WABA must be created." So the billing model must be chosen before the first customer is onboarded.

Repo facts, measured 2026-08-22:

  • feature_grants already carries limit_value, limit_period and on_exceed at eight scopes — usage limits need no new mechanism.
  • No Ledger and no Balance table exists (51 tables), though both are among the eleven process primitives — and four designs are waiting on them (commission_ledger, points_ledger, loyalty, communication credits).
  • Model A (a merchant paying Digious) has no collection path: the Business plan fee is taken out of band and the row inserted by hand.
  • brand_name already reaches workspaces and setu_cards at provisioning, so merchant-branded message content needs nothing new.

Options considered ​

A — QRSETU-owned sending with merchant-branded content (T1 + T2) · [recommended for R1] ​

Every message goes out on QRSETU's account; the merchant's name and details ride in template variables.

  • For: available today, zero Meta programme work, zero new schema, one account to keep healthy. QRSETU is invoiced, so metering and plan-based limits work immediately. Almost certainly the actual requirement for solo merchants, who care that the message is about their shop and their order.
  • Against: the recipient sees QRSETU as the sender, which does not serve an enterprise that wants its own verified identity in the chat header.

B — Tech Provider: customer-owned accounts via Embedded Signup, customer pays Meta (T3) ​

  • For: genuine per-customer identity and full isolation — their templates, their portfolio capacity, their ban surface, so no tenant can damage another. Self-serve Meta path (business verification + Advanced Access App Review). QRSETU charges for the software.
  • Against: QRSETU cannot sell messaging credits on this traffic — Meta invoices the customer. Each customer must complete their own business verification and attach a card to Meta, which is real friction. Onboarding is throttled (10 new customers per rolling 7 days, 200 after verification + App Review + Access Verification).

C — Solution Partner: customer-owned accounts, QRSETU's credit line attached (T4) · [the enterprise answer, when there is an enterprise] ​

  • For: the only shape that delivers the customer's own branding AND a single bill from QRSETU, which is precisely what was asked for. Prepaid credits work here. Also unlocks Partner-Led Business Verification (Select/Premier tiers), taking a customer to the 2,000/day tier quickly instead of leaving them at 250.
  • Against: Solution Partner status is an approval programme with no published qualification criteria and no self-serve path; QRSETU becomes legally liable for customers' Meta spend (credit exposure, float, dunning); and the attachment is irreversible per constraint 4. Multi-Partner Solutions is the cheaper substitute — pair with an existing Solution Partner for billing while remaining a Tech Provider for software, at the price of a revenue split and a dependency.

D — Many customers' brands on QRSETU's own single account · rejected ​

The apparent shortcut: a dedicated number per customer inside our account, carrying their name and logo.

  • ⚠ This ADR records two corrections against itself, because the reasoning moved twice. The first draft rejected it as impersonation — wrong mechanism: the policy bars presenting another business "without permission", so authorisation matters. The second draft therefore permitted it — also wrong, by reading that exception as wide when it is narrow.
  • Rejected on four independent grounds: (1) the Display Name Guidelines require the relationship to be "evident and clear in both parties' business websites", unsatisfiable at scale for stall vendors, tutors and electricians; (2) constraint 2 — a WABA per client is contractual, and the 30-day transfer obligation cannot be honoured from a shared account; (3) no isolation — shared template namespace, portfolio-wide capacity, and one tenant's violation able to silence every merchant; (4) Meta enforces this at review (a portfolio registered as "Tolaram Grp" was refused the display name "Colgate"; the remedy was a separate account).
  • ⚠ What makes it dangerous rather than merely wrong: the mechanism permits it. Display names are genuinely per-number and settable, so this design builds, deploys and works until enforcement arrives. It fails on policy and contract, never on API — which is exactly the class of defect no gate in this repo can see.

Decision (proposed) ​

  1. Adopt A for R1. QRSETU's account sends everything; merchant identity travels in template variables and in per-message workspace_id attribution. Make merchant-branded content the default for transactional messages, not an option.
  2. D is prohibited. Recorded with its four grounds so it is not re-proposed as an optimisation, and with the two corrections above so the reasons are not misremembered either.
  3. C is the enterprise offering, and it is demand-gated, not capability-gated. Pursue Solution Partner status (or a Multi-Partner pairing) when a named enterprise justifies it — not speculatively. B is the fallback when a customer is content to hold their own Meta billing.
  4. Usage limits ship as configuration now, and are promoted to an availability control. Plan differentiation uses feature_grants.limit_value + on_exceed. ⚠ Because Meta's messaging limit is portfolio-wide and every R1 merchant sends from QRSETU's portfolio, a per-workspace send cap is the only thing preventing one merchant's marketing from exhausting every merchant's transactional capacity. It must exist before the first campaign runs — the one non-deferrable item here.
  5. Prepaid credits, when built, are the shared Ledger/Balance primitive with a unit code — never a bespoke communication_credits table. They are blocked on Model A collection: there is no way to charge a merchant today.
  6. No credit balance or top-up UI is drawn before its collection path exists, following the approved PlanBilling design's own discipline of removing artifacts the product does not have.
  7. Write the eventual billing model down now, even though it is not built. Constraint 4 makes it a decision with a deadline: onboarding customers onto their own accounts under B and converting to C later means recreating every account — new number registration, new display-name review, forfeited quality history and messaging tier.

Consequences ​

  • The two goals are compatible, at one specific address. Customer branding plus a QRSETU bill exists only as option C. Anyone assuming it comes free with B, or is available on a shared account under D, will design something Meta refuses.
  • ⚠ Reselling messaging has no wholesale arbitrage in it. Volume discounts accrue per business portfolio, reset monthly, and cover utility and authentication only, never marketing — so with each customer on their own portfolio, volume never pools and every customer sits in the lowest tier permanently. Margin on credits must come from the service, priced deliberately, not from buying cheaply. Recorded because it is invisible in partner marketing material.
  • Solo merchants pay no complexity cost — no account, no template queue, no balance. That was the explicit requirement.
  • The Ledger primitive is now a shared dependency of four designs. Whoever builds it first should build the unit dimension, per ADR-0025's condition.
  • Limits are never inheritable. Every customer starts at 250 unique recipients/24h regardless of QRSETU's own verification; tier progression requires using half the current limit in 7 days, so a stall vendor never advances past 2,000. Do not promise tiers to customers.
  • The Admin Hub's branding module stays P3+, and its billing module remains a runbook — Meta has no billing API under any option, so there is no invoice or top-up endpoint to surface at any tier.
  • Enterprise sequencing is argued from measured value: the strategy assessment puts the enterprise motion at 0-3 deals in twelve months against 20-40 for team/upline seats, and the org-admin portal it would live in does not exist.