What changes for WhatsApp business messaging on 1 October 2026

Answering a WhatsApp customer in your own words has been free since November 2024. On 1 October 2026 it becomes a per-message charge at the utility rate for that market, past a monthly allowance of 1,000 delivered service messages per business phone number and outside a free entry point window, with no volume discount at any scale. An account with no payment method on file gets no bill: Meta says the replies stop being delivered.

The three changes, as Meta dates them

Meta’s pricing update page for non-template messages, updated 25 August 2026 and read by us on 19 September 2026, lists three effective dates:

Effective	What Meta says changes
1 August 2026	“Meta will charge on a per-token basis for Meta Business Agent messages”
1 October 2026	“Meta will charge on a per-message basis for all service messages”
1 October 2026	“Meta will charge on a per-message basis for utility messages sent in response to users”

The first runs on a different meter, per token. The two dated 1 October end the blanket exemptions that made answering a customer free, and two narrower free cases survive them, the monthly allowance and the free entry point window.

What was free, and the two sentences that expire

Both exemptions are still printed on Meta’s pricing page as benefits, read there on 19 September 2026:

As of November 1, 2024 - Meta does not charge for non-template messages

As of July 1, 2025 - Meta does not charge for utility templates in response to users

The first covers what you type yourself inside an open window, the second the pre-approved template sent as a reply while it is open. Meta’s summary: “Any non-template message is charged as of October 1, 2026.”

The rate Meta publishes, and the row that does not exist

Meta prints no rate on the pricing page. Rates arrive as downloadable cards, and the published unit is a market rather than always a country. Meta’s country calling code table puts two countries in one row that flattens to “North America Canada United States”, both under calling code 1. So there is no United States row on the card, and that is about the shape of the card rather than about coverage: a message to a United States number is priced, on the row Meta labels North America, at the same amount as a message to a Canadian one.

On the USD card we downloaded on 18 September 2026, the North America row carries a service rate of $0.0034, the same as its utility and authentication rate, which is what Meta says to expect: service rates arrive “with rates the same as those of utility and authentication, by market”. The card moves quarterly and is read one market at a time in the rate card by market.

The allowance is Meta’s, and the unit is a delivered message

Meta adds it on the same date, “Meta will introduce a free monthly tier of 1,000 service messages per business phone number”, and the service rates section is more careful about the noun:

Each business phone number has one shared free tier of 1,000 delivered service messages per month.

Delivered is the word doing the work, and the non-template page’s rate summary agrees in two words: “Charge for: Delivered message.” Shared is the second: it is per number rather than per account, “The free tier resets monthly for each business phone number”, group sends draw on the same pool, “Both 1:1 and group service deliveries draw from this same free tier”, and a group send is not one unit: “A 1:1 delivery consumes one unit; a group send consumes one unit per delivered recipient”. That is Meta’s allowance on Meta’s platform, quoted as a platform mechanic, not an offer of ours.

What no page we read names is the hour or the timezone of the reset. Meta is specific about that elsewhere, dating past rate card changes “at 12am by WhatsApp Business account timezone”, and attaches nothing equivalent to the tier.

Meta scopes the change to messages carrying a pricing category of service or group_service, and documents the types a status webhook carries:

Delivery	Pricing type Meta documents
One-to-one, inside the allowance	free_customer_service, not charged
Group, inside the allowance	free_group_customer_service, not charged
Either, once it is used	regular, with billable true

Record those objects and the switch is visible on the day it happens.

A thousand delivered replies per number per month is roughly 33 a day, which is our arithmetic rather than Meta’s and is declared in this article’s frontmatter. What decides whether you pay is how many messages each enquiry takes, which nobody can model from outside. Nothing pools between numbers, and “Unused service messages in the free tier do not roll over.”

Past the allowance the price is flat, which is the part most likely to break a spreadsheet. Meta runs a volume discount on templates and excludes service messages from it: the update page’s rate summary gives them “Cost per message: Fixed, per published rates” and, in the next field, “Volume tiers: None.” So the hundred thousandth billable reply costs what the first billable one costs.

Two things the allowance does not cover

A template, of any category. A template is charged on its own category, fixed at the moment you use it: “Whenever a template is used, a business accepts the charges associated with the category applied to the template at time of use.” Marketing, utility and authentication are not the service category the allowance is written for. The trap is the utility template used as a reply inside an open window, the shape of Meta’s own worked example of a confirmed order: from 1 October 2026 the pricing page gives it a pricing type of regular, charged, with no free-tier row of its own. It costs the utility rate rather than a unit: our finding on the pages cited below, declared in the frontmatter.

A message from Meta’s own agent. The rule between the two meters is exclusive: “A non-template message is charged either as a Meta Business Agent message or as a service message, never both.” The same page adds “Only one charge applies per message.”

The allowance is not permission either: a service message can only be sent inside an open 24-hour window, which the 24-hour window sets out. And one question sits between the two free cases. The window itself is untouched, “All messages, including template messages, are free for 72 hours, if sent within an open free entry point window.”, and whether a service message delivered free inside one also spends a unit of the month’s thousand is stated on neither pricing page. The two mechanisms sit in different sections and no sentence we found connects them, so we will not assert one.

The silent failure, and what Meta documents about it

Both pages say an account without a payment method loses delivery, and not in the same way. The update page:

For any Solution Provider or directly-integrated businesses that does not have a payment method on file by September 30, 2026, Meta will stop delivering service messages as of when they become charged on October 1, 2026.

The pricing page, on the free tier:

If you do not have a payment method for your WhatsApp Business account, Meta will deliver service messages within the shared free tier but not deliver them after the free tier has been used.

One is a stop on 1 October, the other a stop after the month’s first thousand deliveries. We will not guess which governs, and the safe reading is the earlier one. Either way the failure is a reply that never arrives rather than an invoice, and the waiting customer cannot tell. Meta’s instruction is “To avoid disruptions to your service messages, please add a payment method”, by 30 September 2026.

We then read Meta’s WhatsApp error codes page, on 19 September 2026, and found no entry mentioning service messages, the free tier or the October change. The closest is a general payment-method error, with a second row for contrast, because the other reason a reply fails has a code that says exactly what happened:

Code	What Meta’s details column says
131042	“There was an error related to your payment method.”
131047	“More than 24 hours have passed since the recipient last replied to the sender number.”

The payment-method code is broader, with common causes Meta lists as billing setup problems. 131042 may well be what arrives, and Meta does not say so: neither pricing page mentions it, and the error codes page does not mention the October change. The link is our inference.

The channel exists. Meta’s status messages webhook reference lists among its triggers “Your message is unable to be sent to a WhatsApp user.” and a failure payload carries an errors array with code and error_data.details. What we did not find on the pages cited below is the mapping between that channel and this reason, or a notification carrying it: account_alerts “notifies you of changes to a business phone number’s messaging limit, business profile, and Official Business Account status”, and payment_configuration_update “notifies you of changes to payment configurations for Payments API India and Payments API Brazil”, which is consumer payments rather than paying Meta.

That is the operational gap, and the signal is ours to assemble rather than Meta’s to recommend: poll each number’s health status, where a node set to BLOCKED “does not meet one or more messaging or calling requirements”, and compare directions, because a day with inbound customer messages and no delivered replies is the shape of this failure.

What to do with an assumption that replies are free

If your costs or your prices were set against free service messages, this is not a rate rise, it is a line item that did not exist. One caution on sourcing: do not read prices off the WhatsApp Business Messaging Policy, which still says “Standard pricing applies for all conversation categories” while the pricing page records that “Conversation-based pricing is deprecated. It was replaced with per-message pricing on July 1, 2025.”

So: a billable reply you wrote yourself costs what a utility template to the same market costs, the first 1,000 deliveries per number each month are free with no roll-over, and the price is the same at any volume. Check the payment method before the rate, because the account without one stops sending rather than starts spending.