WhatsApp Business accounts are changing: WAACs, Messaging Accounts, and paid_messaging_account_id

By Andrés Matte

Meta is splitting WhatsApp Business accounts into WAACs and Messaging Accounts. Here is what changes, when paid_messaging_account_id matters, and how to prepare.

Meta is changing the WhatsApp Business account model.

The old model put phone numbers, templates, billing, webhooks, partner access, and analytics under a single WhatsApp Business Account, commonly called a WABA. The new model splits that into two account concepts:

  • a WhatsApp Business Account, or WAAC, for phone-number identity
  • a Messaging Account, for templates, billing, analytics, and webhook subscriptions

This is a major platform change, but the rollout is designed to be backward-compatible at first. If you build WhatsApp software, the important thing is not to panic. It is to understand when the change matters.

TL;DR

  • Existing WABA IDs become Messaging Account IDs during Phase 1.
  • Phone numbers move under WhatsApp Business Accounts, or WAACs.
  • Messaging Accounts hold templates, billing, analytics, and webhook subscriptions.
  • The same phone number can be associated with multiple Messaging Accounts.
  • paid_messaging_account_id becomes important when one app or partner has access to multiple Messaging Accounts for the same phone number.
  • Phase 1 is planned for H2 2026 and should be mostly automatic.
  • Phase 2 is planned for H1 2027 and introduces new Graph API behavior.
  • Phase 3 is planned for H1 2028 and is the mandatory transition.

As of June 6, 2026, this is still a published rollout plan with beta caveats. Treat dates as planning dates, not proof that every production surface has already changed.

Why Meta is changing the model

The old WABA model made a phone number too tightly coupled to one integration.

That created practical problems:

  • a business needed different numbers for different partners
  • switching providers could mean phone-number migration
  • billing and templates were not cleanly isolated by integration
  • users could see multiple WhatsApp contacts for the same brand

The new model separates identity from messaging operations. A business can keep one trusted phone number while different partners or internal apps each get their own Messaging Account for templates, billing, and analytics.

The new model

Think of the split this way:

Old model New model
WABA contains phone number, templates, billing, webhooks, partner access WAAC contains phone number and business identity
  Messaging Account contains templates, billing, analytics, and webhook subscriptions

WhatsApp Business Account, or WAAC

The WAAC is the identity layer. It contains the assets users see or interact with:

  • phone numbers
  • business profile information
  • product catalogs
  • future business usernames

A WAAC is owned by the client or direct developer. It can be shared with partners so multiple integrations can operate against the same business phone number.

Meta says each WAAC contains a single phone number. Multiple WAACs can be linked in a hierarchy when a business needs to manage a set of numbers.

Messaging Account

The Messaging Account is the messaging operations layer. It contains:

  • message templates
  • billing and payment methods
  • analytics
  • webhook subscriptions

Existing WABA IDs become Messaging Account IDs during the first phase of the rollout. That means many existing API calls can continue working initially, even though the conceptual model underneath them has changed.

This is especially important for partners. Each partner can have its own Messaging Account, so templates, billing, metrics, and payment methods are isolated.

What stays the same at first

Phase 1 is designed to avoid breaking existing integrations.

Meta says these surfaces should continue working initially:

  • existing phone number IDs
  • existing access tokens
  • Cloud API message send paths
  • template create/edit/delete flows
  • webhook subscriptions on the current WhatsApp Business Account topic
  • phone number registration flows
  • business verification
  • display names, quality ratings, and messaging limits

That does not mean the change is unimportant. It means the first phase is mostly about Meta changing the account structure under the hood.

What changes

The change starts to matter when a phone number is associated with more than one Messaging Account.

That can happen when:

  • a direct developer keeps their own integration and adds a partner
  • a client shares multiple Messaging Accounts with the same partner
  • a client uses multiple billing currencies and needs separate Messaging Accounts

In those cases, a send request may need to specify which Messaging Account should be charged and used for analytics.

That is where paid_messaging_account_id comes in.

What is paid_messaging_account_id?

paid_messaging_account_id is a request parameter for Messages API calls. It tells Meta which Messaging Account to use for billing and analytics when a phone number is connected to multiple Messaging Accounts.

In simple setups, you may not need it immediately. If your app has access to only one Messaging Account for a WhatsApp Account, Meta can usually infer the correct one.

In multi-Messaging Account setups, you should plan to send it.

Meta also notes that the parameter may be renamed to messaging_account_id in a future update, so avoid hard-coding too much product language around the old name.

Rollout timeline

Phase Timing What happens Developer action
Phase 1 H2 2026 Automatic migration. Existing WABA IDs become Messaging Account IDs. WAACs are created, but WAAC IDs are not generally available yet. paid_messaging_account_id is optional. No code change for simple setups. Start mapping multi-account cases.
Phase 2 H1 2027 New Graph API version introduces WAAC IDs, new endpoints, new webhook topic, separate permissions, and stricter paid_messaging_account_id behavior for multi-account setups. Adopt the new API version if your app may hold multiple Messaging Accounts on the same phone number.
Phase 3 H1 2028 Mandatory transition. All API versions require the Messaging Account ID parameter for multi-account scenarios. APIs targeting phone number IDs must move to WAAC IDs where required. Finish migration before this phase.

The key sentence for planning: do the engineering work in 2027, not in 2028.

How this affects SaaS platforms

If you are building a WhatsApp SaaS product, this change affects three areas.

1. Customer onboarding

Customers may be able to share an existing phone number with you instead of migrating to a new one. That reduces switching friction, but it also means your product must understand shared-number scenarios.

2. Billing attribution

When multiple partners use the same phone number, each partner can have its own Messaging Account. Your integration needs to know which account is responsible for paid messages, delivery analytics, and payment-method health.

3. Template isolation

Templates belong to the Messaging Account where they were created. If a customer uses multiple partners, the same template may need to exist in more than one Messaging Account.

That matters for onboarding, migration, and support. A user may say “this template exists on our WhatsApp account,” but your app may not have it in the Messaging Account it can access.

What to store

If you operate a platform, start preparing your data model for:

  • phone number ID
  • future WAAC ID
  • Messaging Account ID
  • owning business portfolio ID
  • partner/shared-account relationship
  • billing/payment-method status per Messaging Account
  • template ownership per Messaging Account

Do not assume one phone number maps to one billing container forever.

Common mistakes

Assuming “WABA ID” will always mean the same thing

During Phase 1, the old WABA ID effectively continues as the Messaging Account ID. Later, WAAC IDs become a separate concept. Product copy, database names, and support tools should become more precise.

Ignoring multi-partner edge cases

Simple direct integrations may keep working for a while. Platforms and partners cannot ignore this because their customers are exactly the businesses most likely to create multi-account setups.

Treating billing health as phone-number-level only

Billing moves with the Messaging Account. If a Messaging Account has no payment method, paid sends through that account can fail even if the phone number itself looks healthy.

Forgetting that throughput is still shared

Meta says throughput remains at the phone-number level. If multiple partners share a phone number, they also share its throughput capacity.

What Kapso should abstract

Kapso’s job is to hide as much of this account-model complexity as possible while still exposing the details developers need when debugging.

For users, the ideal product behavior is:

  • connect or share a WhatsApp number with minimal migration pain
  • keep templates and billing understandable
  • show when a problem belongs to Meta account structure, payment method, template ownership, or phone-number health
  • avoid requiring developers to understand WAAC/Messaging Account internals for basic sends

For developers, Kapso should still expose enough metadata to debug edge cases:

  • which connected number was used
  • which account owns the template
  • which account is billed
  • whether a send failed because account resolution was ambiguous

Bottom line

The WhatsApp account model is moving from “one WABA owns everything” to “identity and messaging operations are separate.”

If you run a simple direct integration, the first phase may require little or no immediate work. If you build a platform, solution partner product, or multi-customer WhatsApp onboarding flow, this is worth planning now.

The urgent work is not to rewrite everything today. It is to stop assuming:

  • one phone number equals one WABA
  • one WABA equals one billing context
  • templates are globally available for a number
  • partner access always implies unambiguous billing

Those assumptions are what will break as the rollout becomes mandatory.