WhatsApp metering — the ruling

Ruling: a hybrid. A small included allowance, metered overage at cost + 20%, and the WhatsApp platform line sold as a separate A$49/mo line — not free inside the Social add-on.

And the finding that outranks all of the arithmetic below: for most tenants we cannot be the Bill To Party at all without carrying their Meta liability. That makes the billing model a structural choice, not a pricing preference.

1. The question this card was given

[eve-customer-service-design](eve-customer-service-design) §8.2, written 2026-10-19, left this open and addressed it to Mira:

For Mira — this blocks the add-on price: WhatsApp needs either a message allowance per tier or pass-through at cost + margin. The choice must be made before the Social add-on is priced, because it is the difference between a flat product and a metered one.

§8.4 item 1 (owner Mira) and §9.4's Phase-2 gate ("metering model decided (Mira)") both point here. Sibling card t_b2496986 has since fixed the price envelope; this card fixes the metering model inside it.

2. What the rates actually are (primary source, live 2026-10-20)

Every figure below is from Meta's own published rate cards, downloaded live during this run and landed as evidence files. Not relayed, not estimated.

2.1 Australia is not a standalone market — it is a region

Australia (+61) sits inside Meta's "Rest of Asia Pacific" pricing region (16 markets: AF, AU, KH, CN, JP, LA, MN, NZ, PG, PH, TW, TJ, TH, TM, UZ, VN). It is one of only 8 regional rate-card markets; the other 39 are standalone named countries. AU therefore inherits a rate set that is not specific to Australia — it moves when the region moves.

Evidence: meta_whatsapp_aud_rate_card_2026-10-01.csv (47 markets, landed by sibling card t_b2496986, sha256 0fd348d6…) and meta_whatsapp_aud_roap_tiers_2026-10-01.csv (RoAP tier ladder, this card).

I independently re-downloaded both AUD cards live in this run and re-parsed them; the RoAP row matches the sibling's committed CSV exactly (marketing 0.1095, utility 0.0148). Two independent pulls of the same primary source agreeing is the evidence, not a second opinion on a relay.

2.2 🔴 Three facts that change the design

(a) Marketing has no volume tier. Ever. Meta's tier card is explicitly "for utility and authentication messages only". So the marketing rate is a flat A$0.1095/msg whether you send 50 or 50,000,000. There is no scale economics in marketing — the only lever is how many you send. That is why "we'll discount at volume" is not an answer here.

(b) The A$0.1095 marketing rate for RoAP went UP on 1 October 2026. Meta's own Oct-2026 change table lists Rest of Asia Pacific · Marketing · Increase, alongside Mexico, Morocco, Saudi Arabia and UAE. Meta's pricing calendar allows rate-card updates 4×/yr with only 1 month's notice (6 months for model changes). We are signing a rate promise we cannot control — this is the same class of risk as the Oracle allowance finding in [business-plan-v2-aud-allowance](business-plan-v2-aud-allowance) §4, and it is why a rate-review clause is mandatory, not optional.

(c) Service messages are no longer free — they became chargeable on 1 October 2026, with a free tier. The vault's §8.2 still says "non-template Service-category replies inside an open 24-hour customer-service window are free". That was true until 30 September 2026 and is now wrong. As of 1 Oct 2026: 1,000 free service messages per business phone number per month (no rollover, resets at 12am account time), then charged at the service rate (A$0.0148). Utility templates sent inside an open customer-service window are now charged too. A WABA with no payment method stops delivering service messages once the free tier is exhausted.

This is the correction that changes a number, not just a sentence. Before 1 Oct 2026, "a tenant's EVE customer-service conversations cost A$0.00" was simply true. It is now true only up to 1,000 service messages per phone number per month — ≈500 CS conversations/month at 2 messages each. Above that we pay A$0.0148/msg on the tenant's behalf.

3. The exposure — why a flat add-on cannot carry this

Meta's cost for a single marketing blast, AU recipients, at the 1 Oct 2026 rate:

One 1,000-recipient campaign costs more than the entire monthly add-on price. No allowance inside an A$25–79 add-on can absorb it. Any model that says "the Social add-on includes WhatsApp" is a promise we cannot keep.

The sibling's envelope (A$49 line ⇒ allowance must sit at ≤179 marketing messages/month to hold 60% margin; break-even is 447) is correct and I have re-derived it independently: 49 ÷ 0.1095 = 447 break-even, 49 × 0.4 ÷ 0.1095 = 179 for 60% margin.

Meta's own ceiling is lower than ours. New portfolios start at TIER_250 — 250 unique users per 24h outside a customer-service window (A$27.38/day of marketing). Scaling to 2,000 / 10,000 / 100,000 / unlimited requires verification and delivery history. For the pilot, Meta's messaging limit is a tighter blast cap than our commercial allowance — which is a comforting fact: our cap is not the binding constraint during the pilot.

4. 🔴 The structural finding — we become the Bill To Party, and we carry the liability

This is the part that actually decides the model, and it is bigger than the rate arithmetic.

Meta's billing architecture for embedded-signup clients has two shapes:

Meta's own words, from Managing credit lines:

"Billing Liability Disclosure. Clients that you onboard through Embedded Signup must be granted access to your line of credit with Meta to pay for WhatsApp Business Platform access. This means that businesses pay you, and you receive an aggregated invoice to pay Meta. You are the 'Bill To Party' for all businesses sharing your credit line. You are liable for and will pay Meta for all WhatsApp Business Platform spend made by these businesses."

The Meta Terms for the WhatsApp Business Platform also prohibit "distribute, sell, resell, or rent the WhatsApp Business Platform to third parties" — so we may not resell WhatsApp itself. We may only provide a service to a tenant who holds the account, acting as a Solution Partner / Tech Provider on their behalf. That is a licence-clean shape for us, but it constrains what we may charge and how.

4.1 The two workable shapes

Shape A — Tenant-owned WABA, tenant pays Meta directly (Tech Provider model).

• Tenant holds the WABA and the Meta billing relationship. We never touch their money for Meta.
• We cannot meter their spend for them, because we are not the payer. Our "allowance" would be enforced in our product (how many messages our agent will send), not in Meta's billing.
• Exposure to us: zero. Our revenue is the flat line price; the tenant's Meta bill is theirs.
• Tenant friction: they need their own Meta Business account, payment method, and a WABA. That is onboarding labour — the same shape as the Zalo OA-admin runbook already in the design of record.

Shape B — Our credit line, we bill the tenant, we pay Meta (Solution Partner model).

• We share our credit line with the tenant's WABA (POST /<EXTENDED_CREDIT_LINE_ID>/whatsapp_credit_sharing_and_attach), the tenant's WABA is attached to it, and Meta invoices us an aggregate.
• We carry every tenant's Meta spend until they pay us. A tenant who does not pay leaves us holding it.
• We can meter precisely, and we can enforce an allowance in the billing system itself: the ExtendedCreditAllocationConfig edge supports partition_type: FIXED with an amount — a fixed credit partition per tenant, i.e. a hard ceiling on what that tenant can draw from our line. AUTH partition type is authorisation-only (amount 0 = inactive or just an authorisation).
• Our margin becomes the spread between what we bill the tenant and what Meta charges us, plus we carry the credit risk and the FX/GST exposure.

4.2 🔴 A limit on Shape B I have to flag as unresolved

Meta's Terms say that when an invoiced customer "approaches, reaches, or exceeds the maximum spending limit for their credit line", Meta "may suspend all or part of your access". A FIXED partition caps what a tenant can draw — but I have not found a primary-source statement that a tenant's exhausted partition stops their messaging rather than just their credit. This is exactly the kind of silent-failure the vault keeps warning about, and I will not guess it. Action: Sol to verify the partition-exhaustion behaviour against Meta support or a live tenant account before we sell Shape B. Until then, Shape B is not sellable on a hard cap alone.

4.3 The ruling on structure

Default to Shape A (tenant owns the WABA, tenant pays Meta directly). Rationale, in order of weight:

1. We are a service provider, not a lender. Shape B makes us the Bill To Party for every tenant's WhatsApp spend — credit risk we do not want, at pilot scale, on a channel whose rates Meta can raise 4×/yr on 1 month's notice. We already decided in [business-plan-v2-aud-allowance](business-plan-v2-aud-allowance) that our margin is labour, not infra; taking a tenant's Meta credit risk is infra risk wearing a costume.
2. It is the licence-clean shape. We never resell the platform; the tenant holds the account and the billing relationship.
3. Our metering still works — in our product. The allowance is enforced by what our agent is willing to send, and the overage is a billed service (we send more, on request, and charge our own rate), not a re-sale of Meta's messages. That is the distinction that keeps us inside the terms.
4. It matches the rest of the product: the tenant already owns its domain, its M365 licence and its Medusa instance.

Shape B is the fallback, and it becomes necessary the moment a tenant wants us to hold the Meta relationship (many will). If we adopt it, it comes with the FIXED partition per tenant, a named credit owner, and a collections process — and the partition-exhaustion behaviour must be verified first.

5. The ruling itself

5.1 Model: allowance + metered overage at cost + 20% (hybrid)

Not a pure allowance, not a pure pass-through. The reasoning:

• A pure pass-through (bill every message at cost + 20%) makes the A$49 line price meaningless — the tenant pays Meta's money either way, so we have sold them a rate rather than a product, and there is no relationship to hold. It also means we have no allowance to protect the tenant from a runaway blast, which is precisely the risk §8.2 identified.
• A pure allowance (fixed included messages, no overage) has to be sized at ≤179 marketing messages/month to hold 60% margin at A$49. 179 marketing messages a month is not a product — it is less than one campaign. Any tenant with a real marketing need either busts the allowance or never uses the product.
• The hybrid gives the tenant a working product (the line price buys the platform, the templates, the scheduling, the approval queue) and makes volume monetised rather than penalised — which is the only version of this a marketing agency will actually resell.

5.2 The numbers (AUD, ex-GST)

Why 150 and not 179. 179 is the 60%-margin ceiling; 150 leaves headroom against a rate rise and lands on a number a tenant can understand ("about 5 campaigns of 30, or 10 sends a day"). At 150, the allowance costs us A$16.43 against A$49 revenue — 66.5% margin on the line, before any overage.

5.3 What the tenant actually pays, and what we keep

A tenant running one 1,000-recipient campaign:

The tenant's alternative is to buy the same blast from Meta directly for A$109.50. We charge A$51.19 more than Meta does, and what they buy for that difference is the drafting, the approval queue, the catalogue grounding and the scheduling — the labour, which is exactly where our margin is supposed to live. If a tenant declines to pay the premium, the honest answer is that they should use Meta directly, and we should not have built them the add-on.

On an overage-only month (no allowance used), 20% markup on cost is 16.7% margin — thin by design. The labour margin is in the line, not in the messages.

5.4 The controls that make this safe

Note on control 2: the max-price feature is how we guarantee the spread. Without it, a rate rise between quoting and sending lands on us. With it, we cap what we will ever pay per delivery at the rate we bill.

— mira, 2026-10-20 22:45 — 🔴 CORRECTION to control 2 (independent re-verification pass, board-mirror card t_c2f6df57). The bid_amount figure in the original table was wrong by a factor of 100.

The original said "A$0.1314 → bid_amount 131 per 1,000 deliveries". Meta's own worked example sets the unit: "To set a max price of $0.05 USD per delivery: Set bid_amount to 5000" — i.e. bid_amount = per-delivery price × 1000 × 100 (the account currency's smallest unit; cents for AUD). Applying the same formula: 0.1314 × 1000 × 100 = bid_amount 13140, not 131.

Why the original number was wrong: it applied × 1000 but not × 100 (cents). bid_amount 131 buys A$0.00131 per delivery — a cap 100× below the A$0.1314 we bill, so it would have capped our deliveries at a fraction of cost rather than protecting the spread. A control that is wrong by 100× in the permissive direction is worse than no control: it reads as protection in the design of record and is not.

Verified against: Meta — Set a max price for marketing messages (BETA), updated 19 Oct 2026, "Calculating max price amounts" section. Also confirmed bid_strategy must be LOWEST_COST_WITH_BID_CAP whenever bid_amount is set, and that a bid cap is not a budget (it does not stop volume — only price), which is why control 1 (HIL gate) and control 3 (FIXED partition) are still needed.

The metering script carried the same error (wa_metering_model_2026-10-20.py §9 printed round(MKT*MARKUP*1000) = 131). Fixed in the same pass; the script now prints 13140 and shows the unit derivation.

— mira, 2026-10-20 22:45 — 🔴 SECOND CORRECTION (independent re-verification pass, t_c2f6df57): the A$0.1314 overage rate is an AU-only rate, and the ruling never says so.

§5.2 prices overage at A$0.1314 and §5.5 clause 2 tells the tenant that is the rate. That number is cost + 20% of the Rest of Asia Pacific rate — correct for AU recipients only. Meta charges by the recipient's country calling code, and a tenant's audience is not necessarily Australian. From the rate card I re-parsed live (47 markets, effective 1 Oct 2026):

Recipient market	Meta marketing cost	Our A$0.1314 bill	Effect
Netherlands	A$0.2077	A$0.1314	we lose A$0.0763/msg
Germany	A$0.1775	A$0.1314	we lose A$0.0461/msg
Chile	A$0.1156	A$0.1314	ok (+A$0.0158)
Rest of Asia Pacific (AU)	A$0.1095	A$0.1314	ok (+A$0.0219)
Colombia	A$0.0163	A$0.1314	we overcharge A$0.1151/msg (706%)
India	A$0.0153	A$0.1314	we overcharge A$0.1161/msg (759%)
Turkey	A$0.0142	A$0.1314	we overcharge A$0.1172/msg (825%)

Two failure modes, both real: (a) a blast to Netherlands recipients costs us A$76.30 per 1,000 messages more than we bill — the exact loss control 2 was supposed to prevent, and control 2 only helps if we set the cap to the recipient's market rate; (b) a tenant with an Indian or Turkish audience is overcharged up to 8× on the overage line, which is a pricing-dispute and reputational risk, not a margin.

The fix is a market-aware rate, not one rate. Our meter already has the field it needs: Meta's status-message webhook gives pricing.category per delivery, and the pricing_analytics edge breaks charges down by COUNTRY × PRICING_CATEGORY × PRICING_TYPE (Meta — Analytics, pricing_analytics). The market is knowable per delivery — we simply were not pricing on it.

What this changes in the ruling (it does not change the ruling): the A$49 line, the 150-message allowance and the hybrid model all stand. What changes is that A$0.1314 is the AU overage rate, not "the" overage rate, and the billing rule must be: overage_rate(recipient_country) = Meta marketing rate(country) × 1.20. For AU tenants that is A$0.1314, unchanged. Control 2's bid_amount must then be set per destination country — Meta's own mechanism for this is bid_country_multiplier_overrides (an ISO-3166 alpha-2 → multiplier map inside optimization_spec), which is how one template carries the right cap into each market. Open item added in §7.

Honest limit: the per-country multiplier map and the pricing_analytics dimensions are verified from Meta's docs; not exercised against a live account. And a tenant's audience mix is not knowable at quote time — so the tenant contract must state that overage is priced on the recipient's market, not on a single rate.

5.5 What the tenant must accept (contract terms)

1. WhatsApp messages are billed per delivered message by Meta; Meta charges on delivery, not on send.
2. The included allowance is 150 marketing messages/month; overage is billed at A$0.1314/delivered marketing message for Australian recipients (cost A$0.1095 + 20%) and A$0.0178/utility or service message above Meta's free tier. For non-Australian recipients the overage rate is Meta's rate for the recipient's market + 20% — see the §5.4 correction note. The allowance and the A$49 line do not change.
3. Meta's rates can change 4×/yr on 1 month's notice. We pass that through with the rate-review clause; the allowance and overage rates re-baseline on notice.
4. The tenant's messaging quality rating is their responsibility — blocks, reports and low quality ratings restrict their sending and can suspend the number, and that is a tenant risk, not ours.
5. GST treatment of Meta's fees is unresolved (see §6). A 10% unrecovered GST on the largest variable cost in the product is a 10% swing on it. Accountant sign-off required before we quote.
6. The tenant's audience may not be Australian. Overage is priced on the recipient's market, so a tenant with an overseas audience is billed on Meta's rate for that market + 20%. Meta's rate card is published in advance and we will show the tenant the rate applied.

6. Honest limits — what I did NOT establish

• 🔴 I did not test any of this against a live Meta account. Every rate is from Meta's published rate cards and terms, downloaded and parsed live on 2026-10-20. The rates are evidence. The behaviour of a FIXED partition when exhausted is not — see §4.2.
• I did not obtain our own credit line. Shape B depends on Meta granting us a credit line as a Solution Partner and on the terms of that line. Unknown.
• GST treatment of Meta's fees is unresolved. Whether we can claim an input credit on Meta's messaging fees (and at what rate) changes the effective marketing cost by ~10%. Not established. Accountant required.
• The 1 Oct 2026 service-message change means I cannot rely on the older figures in [eve-customer-service-design](eve-customer-service-design) §8.2. They were true on 19 Oct 2026 for the rate card but the free-service-message boundary moved on 1 Oct 2026. The sibling doc [marketing-social-addon-pricing-2026-10-20](marketing-social-addon-pricing-2026-10-20) already carries the 1,000-free figure correctly; §8.2 of the design of record does not, and is corrected by the note appended to it.
• Meta's AI-Provider pricing policy is a live constraint, not a footnote. From 15 Jan 2026, WhatsApp's terms prohibit AI Providers from offering general-purpose AI assistants on the platform except where Meta is legally required to permit it — currently Italy, Brazil, and (from 15 Oct 2026) Türkiye; the EU-27 list was charged until 12 May 2026 and has not been charged since. Australia is not on that list. Our EVE is a business customer-service agent serving a tenant's own customers, not a general-purpose assistant, so it falls outside the prohibition — but this is a legal reading, not a legal opinion, and Young should not let us sell AI-agent messaging on WhatsApp to AU tenants without counsel's view. Flagged, not resolved. (Meta: New pricing policy for AI Providers, updated 15 Oct 2026; WhatsApp Business Solution Terms, 15 Jan 2026.)
• The 150-message allowance is a judgment, not a derived optimum. It is inside the sibling's margin envelope and lands on a comprehensible number. The pilot's first 30 days of usage should re-baseline it.
• I have not priced the Zalo/GBP/TikTok per-message equivalents, which carry their own costs and are not in this card's scope.
• Meta's marketing_lite (MM API) rate is a separate pricing category from Cloud API marketing. When we move marketing sends to the Marketing Messages API — which Meta requires for new Messaging accounts from 13 Apr 2027, and Cloud API marketing sunsets 13 Oct 2027 — the rate we have verified (A$0.1095) may not be the rate charged. The MM API path supports a max price we can set, which protects the spread either way, but the marketing_lite rate card itself still needs its own verification before the MM API migration. Not established.

7. Open items this ruling creates

8. What changed in the design of record

• [eve-customer-service-design](eve-customer-service-design) §8.2 — the sentence "non-template Service-category replies inside an open 24-hour customer-service window are free" is out of date as of 1 Oct 2026. A note is appended; Tam/Echo's text is left intact (section ownership).
• §8.4 item 1 (WhatsApp metering model — owner Mira) — CLOSED by this ruling.
• §9.4 Phase 2 gate ("metering model decided (Mira)") — CLOSED.
• §6.6 item 2 / §7 item 3 — already closed by sibling card t_b2496986; this card does not reopen them.

Sources

• Meta — Pricing on the WhatsApp Business Platform, updated 30 Sep 2026 (rates effective 1 Oct 2026): https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing
• Meta — AUD list rates (47 markets), effective 1 Oct 2026 — landed as meta_whatsapp_aud_rate_card_2026-10-01.csv
• Meta — AUD volume tiers, effective 1 Oct 2026 — landed as meta_whatsapp_aud_roap_tiers_2026-10-01.csv
• Meta — Pricing regions on the rate card (country calling codes) — AU → Rest of Asia Pacific
• Meta — Messaging limits (TIER_250 → unlimited) — https://developers.facebook.com/documentation/business-messaging/whatsapp/messaging-limits
• Meta — Managing credit lines (Bill To Party / liability disclosure; FIXED partition) — https://developers.facebook.com/documentation/business-messaging/whatsapp/solution-providers/share-and-revoke-credit-lines
• Meta — Meta Terms for the WhatsApp Business Platform (no reselling; invoiced-customer spending limit) — https://www.facebook.com/legal/Meta-Terms-for-WhatsApp-Business-Platform
• Meta — WhatsApp Business Solution Terms, 15 Jan 2026 (AI Providers clause)
• Meta — New pricing policy for AI Providers, updated 15 Oct 2026 — https://developers.facebook.com/documentation/business-messaging/whatsapp/pricing/ai-providers
• Meta — Set a max price for marketing messages (BETA), updated 19 Oct 2026 — https://developers.facebook.com/documentation/business-messaging/whatsapp/marketing-messages/pricing
• Meta — Marketing Messages API for WhatsApp — Overview, updated 13 Oct 2026 (Cloud API marketing sunset 13 Oct 2027)
• Meta — Embedded Signup FAQ (who owns the WABA; who is liable)
• Sibling ruling — [marketing-social-addon-pricing-2026-10-20](marketing-social-addon-pricing-2026-10-20) (t_b2496986)
• Design of record — [eve-customer-service-design](eve-customer-service-design)

Author: Mira (mira@solos.local). Live probes: Meta's pricing docs, both AUD rate cards and the credit-line docs were fetched and parsed during this run; the rate figures were independently reproduced against the sibling card's committed CSV. The model script is wa_metering_model.py alongside this doc.