On this page · 13 sections
- Decision 1: which channel carries which message
- Decision 2: budget per message, not per conversation
- Decision 3: instrument billing from the webhook, not the send log
- Decision 4: settle template governance before the first campaign
- Decision 5: pick the RCS launch path early, because one of them needs a contract
- Decision 6: design consent as a data structure, not a checkbox
- Decision 7: decide where the conversation logic lives
- Decision 8: plan for payments and calling as separate workstreams
- India-specific considerations
- What an eCorpIT engagement looks like
- FAQ
- How eCorpIT can help
- References
Summary. Meta replaced conversation-based pricing with per-message pricing on 1 July 2025, so the 24-hour conversation bucket most Indian D2C teams still budget against no longer exists. Service conversations have cost ₹0 since 1 November 2024, and Meta describes them as unlimited. A free entry point conversation, opened by a Click to WhatsApp Ad or a Facebook Page call-to-action answered inside 24 hours, runs for 72 hours. Charges attach on delivery, not on send, and pricing data arrives in every message webhook. On the other channel, Google's RCS for Business splits launches into Google-managed and carrier-managed, and for the carrier-managed ones "the carrier will reject your launch if they have no contract in place with you." Meta publishes rate cards in 6 currencies including INR, and bills against the customer's country calling code, 91 for India. Those 4 mechanics decide most of the architecture. Here are the 8 decisions to settle before anyone opens an editor.
Decision 1: which channel carries which message
WhatsApp and RCS are not substitutes, and the common mistake is treating RCS as a cheaper WhatsApp.
WhatsApp reaches a user's WhatsApp account regardless of handset. RCS reaches RCS-capable devices on carrier networks where your agent has been approved for launch, which in practice means Android. Google's platform provides a capability check API precisely because reachability is not assumed, and an SMS fallback path is therefore part of the design rather than an afterthought.
Meta's four template categories map cleanly onto business intent: marketing for "new product, service, or feature announcements, targeted promotions/offers, and cart abandonment reminders"; utility for "opt-in confirmation, order/delivery management"; authentication for "one-time pass codes"; and service to "resolve customer inquiries."
Route by category, not by preference. Authentication belongs where delivery is most certain. Marketing belongs where the richest card format and the lowest rate intersect. Our earlier WhatsApp Business API cost breakdown for Indian D2C covers the arithmetic in more depth.
Decision 2: budget per message, not per conversation
This is the change most Indian budgets have not absorbed. Meta's own documentation now carries a deprecation banner: "This document describes conversation-based pricing, which was replaced by per-message pricing on July 1, 2025."
Under the old model a single 24-hour conversation covered many messages. Under the new one, each delivered template is a billable event by category and market. A drip sequence that cost one conversation now costs one charge per template.
Two facts soften it. Service conversations became free on 1 November 2024, and Meta states "you can open an unlimited number of service conversations at no charge," which includes AI-enabled conversational experiences. And free entry point conversations remain: if a customer messages you through a Click to WhatsApp Ad or a Facebook Page call-to-action button and you respond within 24 hours, the resulting window "is opened as soon as your message is delivered and lasts 72 hours," during which templates carry no charge.
| Billing mechanic | What it means for the build | Where it bites |
|---|---|---|
| Per-message pricing since 1 Jul 2025 | Every delivered template is a separate charge | Long nurture sequences |
| Free service conversations since 1 Nov 2024 | Inbound-triggered support is not a cost line | Encourages inbound-first design |
| Free entry point, 72 hours | Ad-originated threads are free to work | Rewards Click to WhatsApp Ad spend |
| Customer service window, 24 hours | Non-template messages only inside it | Support tooling must track window state |
| Charged on delivery | Failed sends are not billed | Reconcile against webhooks, not send logs |
| Rates update up to quarterly | Unit economics move under you | Never hard-code a rate |
| Rate by customer calling code | India is code 91 in Meta's country table | Diaspora traffic bills at other rates |
That last row is the one finance teams miss. Meta states that "charges for conversations are based on the country of the user's phone number," using the calling code and network prefix. A brand in Gurugram messaging NRI customers is not paying India rates on those messages.
Decision 3: instrument billing from the webhook, not the send log
Meta states plainly that "pricing information is included in all message webhooks."
Build the cost ledger off that. A send log tells you what you attempted; the webhook tells you what was delivered and what it cost, in the category Meta actually applied. Those two numbers diverge, and reconciling them monthly against the Meta Business Suite invoice is the difference between a messaging programme with a known unit cost and one with a surprise.
We treat the webhook consumer as a first-class service in every messaging build, with idempotent handling and replay, not as a controller method bolted to the marketing app.
Decision 4: settle template governance before the first campaign
Meta puts the responsibility in writing: "Businesses are responsible for reviewing the category assigned to their approved templates. Whenever a template is used, a business accepts the charges associated with the category applied to the template at time of use."
A template submitted as utility and reclassified as marketing changes your unit economics silently. Governance means a named owner per template, a review step before submission, a record of the category at approval, and an alert when a category changes.
It also means resisting the urge to disguise marketing as utility. Category assignment is Meta's call, not yours.
Decision 5: pick the RCS launch path early, because one of them needs a contract
Google's RCS for Business documentation, updated 11 May 2026, describes a two-step launch: brand verification, where "an authorized brand representative confirms your agent information and your right to manage the agent on their behalf," then launch approval by "Google, carriers, or both."
The consequential split is here: "Google-managed launch: Google manages brand verification and launch approval for the carrier" versus "Carrier-managed launch: The carrier directly manages brand verification and launch approval for their network."
And the sentence that decides your timeline: "For carrier-managed launches, you must have a direct agreement with the carrier before they will approve your agent for launch. The carrier will reject your launch if they have no contract in place with you, and they may contact you to establish a relationship."
Carrier-managed carriers are flagged with an info icon on the Launch page of the RCS for Business Developer Console. Check which of your target networks are marked before committing to a launch date, because a commercial negotiation with a telecom operator is not a two-week task. This is the single most common reason an Indian RCS timeline slips.
| Decision point | WhatsApp Business Platform | RCS for Business |
|---|---|---|
| Who approves you | Meta, via template review | Google, carriers, or both |
| Hard commercial gate | Business verification | Direct carrier contract for carrier-managed launches |
| Reach model | The user's WhatsApp account | RCS-capable devices on approved carrier networks |
| Message unit | Template by category | Agent messages, with capability checks |
| Fallback needed | No | Yes, SMS |
| Bot framework path | BSP or Cloud API | Dialogflow integration documented |
Decision 6: design consent as a data structure, not a checkbox
Under the Digital Personal Data Protection Act 2023, consent is the lawful basis most Indian messaging programmes rely on, and it has to be demonstrable per purpose. A single boolean on a customer record does not survive contact with that requirement.
What we build instead: a consent record carrying purpose, channel, timestamp, the exact notice text version shown, the capture surface, and a withdrawal timestamp. Withdrawal has to propagate to the sending layer within the same transaction, not on a nightly job.
Marketing consent and transactional consent are separate purposes and should be stored separately. A customer who consents to delivery updates has not consented to promotions. We designed the same separation for the migrations described in our DPDP engineering playbook for Indian startups, and it is the piece most retrofits get wrong.
We design messaging systems aligned with DPDP requirements. We do not certify compliance, and neither should any vendor who tells you otherwise.
Decision 7: decide where the conversation logic lives
Three architectures show up, and the choice is mostly about how much conversational logic you own.
BSP-hosted flow builders are fastest to launch and hardest to extend. The logic lives in someone else's console, which is fine for broadcast and simple keyword routing, and painful when the flow has to consult inventory, a loyalty balance, or a payment state.
Direct Cloud API integration puts the flow in your stack. More build, full control, and the only option we recommend when the conversation has to read or write your systems of record.
A hybrid, where the BSP handles transport and number management while your services own the conversation, is what most Indian mid-market brands end up with. It keeps template submission and number hygiene with a specialist and keeps business logic where your engineers can test it.
If the flow needs to answer open-ended questions rather than follow a decision tree, that is a different build again, and closer to the work in our AI support agent service for D2C.
Decision 8: plan for payments and calling as separate workstreams
Meta's WhatsApp documentation carries a dedicated Payments India section covering UPI Intent with Cashfree, BillDesk and CCAvenue, payment links, enhanced payment links, payment gateway integration, and order details, order status and checkout button templates.
That is a payments integration wearing a messaging costume. It brings gateway onboarding, reconciliation, refunds and dispute handling, and it belongs on the roadmap as its own phase with its own testing, not as a checkbox inside a messaging sprint. The commerce-side considerations overlap with our fintech and payments app development work in India.
Voice is separate again. Meta states that "the WhatsApp Business Calling API has different pricing" with its own pricing document. Do not assume messaging rates extend to it.
India-specific considerations
Four things are specific to shipping this in India.
Billing currency and rate cards. Meta publishes rate cards in USD, INR, IDR, EUR, GBP and AUD, and says to "download the rate card below that corresponds to your WhatsApp Business Account's currency." Pull the current card at the start of every quarter, because Meta stated in June 2024 that it may update rates up to quarterly. Any number older than a quarter is a guess.
Diaspora and calling codes. India maps to calling code 91 in Meta's country table, alongside Argentina, Brazil, Egypt, Germany, Indonesia and others in the same market grouping. Customers on foreign numbers bill at their own country's rate.
Carrier relationships for RCS. India's RCS reach runs through the carrier networks, and any carrier-managed launch needs a signed agreement first. Budget legal and commercial time, not just engineering time.
Android skew. RCS reach is concentrated on Android, which in the Indian market is an advantage for mass-market categories and a limitation for premium ones. Run a capability check before assuming a segment is reachable and keep the SMS fallback funded. Our comparison of WhatsApp and RCS business messaging for Indian D2C goes into the channel split in more detail.
What an eCorpIT engagement looks like
We work in four phases, and we will tell you at the end of the first one if the business case does not hold.
Discovery covers channel selection by message category, a reachability assessment, the consent model, and a rate-card-based cost model built from the current quarter's card rather than a remembered number.
Foundation covers Meta business verification, BSP selection or direct Cloud API setup, RCS partner registration and the launch-path decision, the webhook consumer, and the consent store.
Build covers template design and submission, conversation flows, integration with your order, CRM or support systems, and the billing ledger reconciled against webhooks.
Operate covers template governance, quarterly rate reviews, deliverability monitoring, and the quality-rating watch that keeps a number from being throttled.
Engagements run as fixed-scope phases or a dedicated senior-led team, depending on how much of the flow logic you want in-house. We scope after discovery, not before.
FAQ
How eCorpIT can help
eCorpIT is a CMMI Level 5 certified, MSME certified technology organisation founded in 2021 and based in Gurugram, and our senior engineering teams build WhatsApp and RCS messaging systems for D2C, BFSI and services brands in India. We handle channel selection, BSP or direct Cloud API integration, the consent store and webhook-based billing ledger, template governance, and the RCS launch path including the carrier-contract question that most often delays a go-live. We design these systems aligned with DPDP requirements and hand over documented, testable services rather than console configuration. To scope a build, contact us.
References
Last updated: 22 July 2026.
