BSP

A BSP sells access to a platform it does not own

A Business Solution Provider is a company that Meta has approved to sell access to the WhatsApp Business Platform. The approval is not a badge on a website; it corresponds to a commercial agreement that lets the company provision WhatsApp Business Accounts, register phone numbers against them, submit message templates for review and bill a client for the messages that get delivered. Around that commercial core sits an operational obligation: when onboarding stalls, a template is rejected without a clear reason, or a number refuses to migrate, the BSP is the party expected to open the case with Meta and see it through.

The distinction between operating the door and owning the building is the whole point of the term. Meta controls the Cloud API contract, the Graph API surface, the messaging limits attached to a number, the quality rating that rises and falls with how recipients react, the template category rules and the underlying price per delivered message. The BSP controls the packaging: the console your team logs into, the onboarding flow, the support desk, the invoice in rupees and, often, the software that sits on top. A BSP that describes itself as owning the WhatsApp channel is either confused or overselling.

The relationship is therefore three-cornered rather than two. Your business owns the WhatsApp Business Account and the phone number. The BSP owns the commercial and support relationship with Meta. Meta owns the platform and can suspend a number, reclassify a template or change a rate without asking either of you. Any architecture decision about WhatsApp has to survive that third party changing its mind.

What sits inside the Meta stack underneath the BSP

Underneath every BSP is the same Meta object model, and knowing it saves weeks. A Business Portfolio is the container for your company, its assets and its verification status. Inside it sits a WhatsApp Business Account, which owns the phone numbers, the templates, the message history and the billing currency. Each phone number is registered against the Cloud API with a two-step verification PIN set by you, and it carries a display name that Meta reviews. Templates live at the account level, are grouped into marketing, utility and authentication categories, and are approved or rejected against Meta’s content rules rather than the BSP’s taste.

Two operational facts follow from that model. First, the phone number is the scarce asset, not the account. You can create a second WhatsApp Business Account quickly, but you cannot conjure a phone number that customers already recognise, which is why migration fights are almost always about the number. Second, templates are shared state between your team and Meta: an edit puts a live template back into review, and a rejected template silently breaks any automation that referenced it by name.

The BSP usually adds a layer of its own on top: a campaign builder, a shared inbox, chatbot flows, a contact database. That layer is not part of the WhatsApp Business Platform, and it is where most lock-in actually lives. A team that assumes the console is the platform will discover at renewal time that the number can move but the campaign history, the bot flows and the contact tags cannot.

Why a BSP is not an ISV and not a direct integration

The words get used interchangeably in Indian procurement conversations, and the confusion costs money. An ISV, which Meta now tends to call a Tech Provider, builds software that calls the WhatsApp Business Platform on behalf of clients. It may never hold the billing relationship; it may sit on top of somebody else’s BSP. A BSP is defined by the resale and support contract with Meta, not by the quality of its dashboard. Plenty of companies hold both designations, which is exactly why a buyer has to ask which contract they are actually signing.

A direct integration is the third shape. Meta allows larger businesses to contract with it and call the Cloud API without a reseller in the middle. You get the lowest feasible per-message cost and full control of the stack, and you take on everything the BSP was absorbing: business verification, number registration, template operations, quality monitoring, billing in a foreign currency, and first-line support when something breaks at eleven at night before a festive campaign. Direct integration is not a status symbol. It is an operations decision with a headcount attached.

The practical test is not size but change frequency. A team that sends a stable set of utility templates at steady volume and has platform engineers on call can justify going direct. A team whose marketing team rewrites templates weekly, runs segmented festival campaigns and needs someone to escalate a rejected template in an hour is buying the BSP’s escalation path, and should price it as such rather than treating the markup as pure margin.

The decision that actually matters at selection time

Most BSP comparison spreadsheets rank the wrong things. Dashboard polish and chatbot templates are easy to demo and cheap to replace. The questions that decide whether the relationship survives year two are duller: what happens to my number if I leave, who holds the Meta contract, what is the notice period, can I export templates and opt-in records in a machine-readable format, and what is the published process for a template rejection appeal.

A useful decision rule is to separate the assets you own from the assets you rent. You own the phone number, the WhatsApp Business Account, the consent records and the customer relationships. You rent the console, the automations, the support and the billing. If a vendor cannot cleanly answer what happens to the owned assets on exit, the rented ones do not matter. Ask for the exit clause in writing before the first template is approved, not after the first campaign succeeds.

There is also a data question that Indian buyers now have to ask explicitly. WhatsApp message content, contact identifiers and opt-in evidence are personal data under the DPDP Act. A BSP sits in the processing chain, so it needs to appear in your records as a sub-processor, with a stated purpose, a retention rule and a deletion path. A vendor that cannot produce a data processing agreement, or that stores Indian contact data in a region your own policy excludes, fails the test regardless of price.

Onboarding, verification and the number migration path

Onboarding runs through an embedded signup flow that most BSPs host. You log in with a Facebook account that has admin rights on the Business Portfolio, confirm the legal entity, complete business verification with documents that match the name on your GST registration, create or select a WhatsApp Business Account, and register a phone number that is not currently active on the consumer app or on another WhatsApp Business Account. A number that is still registered elsewhere has to be deleted from the old account first, and two-step verification has to be turned off before it moves.

Migration between BSPs is the step teams underestimate. It is not a commercial handover; it is a Meta-controlled sequence in which the number is released from one WhatsApp Business Account and registered to another, usually with the display name carried across and the quality history attached to the number rather than to the vendor. The work that hurts is everything around it: template names have to be recreated and re-approved, opt-in evidence has to be re-imported into the new console, automations have to be rebuilt, and any in-flight campaign has to be paused. Budget a working week for a number with real traffic, and do it in a low season.

The sequencing rule that prevents most outages is to migrate a secondary number first. Send a slice of utility traffic through the new BSP for a fortnight, compare delivery latency and template approval turnaround, then move the primary number in a maintenance window with the old console still readable. Teams that migrate the only number they have, on a Friday, during a sale, generate the incident reports that make the whole category look unreliable.

Templates, categories and the quality rating you cannot buy

Templates are the unit of permission on WhatsApp. A business cannot send a free-form marketing message to someone who has not written in during the last twenty-four hours; it sends an approved template instead. Meta sorts templates into marketing, utility and authentication, and the category drives both the price and the tolerance for rejection. A payment reminder dressed as a promotional offer gets reclassified as marketing, which is a price change disguised as a taxonomy decision.

Quality rating is the other mechanism. Meta derives a rating per number from how recipients respond, weighting blocks and reports heavily. A green rating keeps messaging limits expanding; a red rating throttles the number and can eventually restrict template sending. This is the part a BSP genuinely cannot fix for you, because the signal comes from recipients. What a BSP can do is surface the rating early, flag templates that historically attract blocks, and slow a campaign before it damages the number.

Messaging limits scale with quality and with business verification, moving through tiers rather than arriving all at once. The practical consequence for an Indian retailer is that a Diwali campaign cannot be scheduled the week it is conceived. The number needs a history of good quality and a limit high enough to carry the send, and limits are raised by sustained good behaviour, not by a support ticket.

Template governance is a small discipline that saves a large argument. Keep one owner for the library, a naming convention that encodes purpose and language, and a rule that a template used by an automation cannot be edited without a replacement already approved. Localisation multiplies the problem: a Hindi and an English version of the same template are two approvals, two categories and two quality signals. Teams that treat templates as copy rather than as infrastructure discover the dependency during a festival week, when a rejection has no time left to absorb.

The India layer: DPDP, DLT and GST on the same invoice

Three Indian rules sit on top of the Meta contract and none of them are the BSP’s responsibility to satisfy on your behalf. Under the DPDP Act, a marketing template sent to a person is processing of personal data, so it needs a lawful basis, a notice the person actually saw, and an opt-in that is specific to WhatsApp marketing rather than inherited from an email list. The consent has to be as easy to withdraw as to give, which in practice means a working STOP keyword and a suppression record that reaches the ledger before the next campaign is built.

DLT is the second. Commercial SMS in India requires registration of the entity, the header and the template on a DLT portal, and the TRAI framework obliges you to keep consent records for the numbers you message. WhatsApp has its own template approval, so DLT does not govern WhatsApp content, but almost every Indian team runs SMS as a fallback for OTP and for people who never installed WhatsApp. A BSP that also sells SMS should be asked which DLT entity the messages will ride on, because a fallback that fails registration is not a fallback.

The third is billing. Meta prices messages in a rate card that varies by market and category, and a BSP converts that into an INR invoice. LoopNow publishes WhatsApp marketing at ₹1.15 per delivered message and utility or authentication at ₹0.22 per delivered message inside plan allowances, with overage at the published rate and all prices exclusive of 18% GST. Whatever the numbers, ask for the GSTIN, the SAC code and the place of supply on the invoice, because input credit on a foreign-currency ad spend is not automatic.

Fallback design deserves an explicit decision. If WhatsApp is your primary channel, decide what happens when a template is rejected, a number is restricted or a user has no WhatsApp account. SMS needs a registered DLT template and a sender ID; a voice call needs a different consent basis in most programmes; email needs an address you actually hold. A fallback that is not tested monthly is a diagram rather than a plan, and the month it matters is the month nobody tested it.

How BSP pricing is actually assembled

A WhatsApp bill has three layers and vendors usually quote only one. The first is Meta’s per-message charge, which depends on the template category and the destination country. The second is the BSP platform fee, which may be a subscription, a per-message markup, a per-seat charge or a bundle of all three. The third is the cost of everything the BSP bundles in: the console, the chatbot builder, the shared inbox, the analytics. Comparing two quotes without splitting these layers is how a cheaper headline becomes a dearer year.

The cost structure also explains a behaviour that puzzles buyers. Marketing messages are the expensive category and utility messages are much cheaper, which creates an incentive to push content into the utility bucket. Meta reviews that and reclassifies, and a reclassification retroactively changes the price of messages already sent. The safe design is to keep the category honest at submission and to model the campaign at the marketing rate, so a reclassification is an accounting event rather than a budget shock.

Two smaller lines deserve attention. A BSP that resells in USD exposes you to card and forex charges, and a BSP that bills in INR but invoices from outside India may not give you a clean input credit. Then there is the service conversation: replies inside the customer service window are priced differently from template sends, so a support-heavy inbox and a broadcast-heavy campaign can have very different unit economics on the same account.

Running the relationship after go-live

The BSP relationship needs an owner and a monthly review, or it quietly degrades. The review should look at four numbers: template approval turnaround, delivery latency at the ninety-fifth percentile, quality rating movement, and the share of conversations that end in a block or a report. None of these are in a standard dashboard, which is why the review is a conversation with the account manager rather than a screenshot.

Escalation paths matter more than SLAs on paper. Ask who the named escalation contact is, what hours they cover, and whether they can open a case with Meta directly or only relay through a portal. During a festive peak, the difference between a support ticket that gets a first response in four hours and one that gets a human on a call in twenty minutes is worth more than a percentage point of markup.

Finally, keep the exit ready while the relationship is good. Export the template library, the opt-in evidence and the suppression list monthly into storage you control. Document the selector names, the number IDs and the display name approval state. A team that can produce those three artefacts on a Tuesday afternoon can change BSP in a week; a team that cannot will stay for years after the service has stopped being good.

Contract hygiene is part of running the relationship. Keep the signed order form, the data processing agreement, the current sub-processor list and the pricing annex in one place, and check the invoice against the annex quarterly. BSP pricing changes when Meta changes its rate card, and a line that was correct at signing can drift without anyone noticing. A twenty-minute reconciliation each quarter is cheaper than discovering the drift during a budget review.

A worked example: an Indian D2C brand changing BSP

A Bengaluru apparel brand sends about 240,000 WhatsApp utility messages and 90,000 marketing messages a month, mostly order updates and restock alerts, on a single verified number with a green quality rating. It wants to move because template rejections take three days and the console cannot export opt-in records. The migration plan starts four weeks before the cutover with business verification on the new portfolio, using the same legal name as the GST registration so the documents match on first review.

In week two the team rebuilds forty-one templates under identical names, keeping the category of each one unchanged, and submits them in a batch so rejections arrive together. In week three it registers a spare number for the new account, routes ten per cent of order updates there, and compares the ninety-fifth percentile delivery latency against the incumbent. It also tests a STOP keyword end to end and confirms that the withdrawal reaches the ledger before the next campaign build.

The cutover happens on a Tuesday morning in a low-sales week. Live campaigns are paused, two-step verification is disabled on the old account, the number is released, and it is registered to the new WhatsApp Business Account. Opt-in evidence is imported the same day and reconciled against the export line by line. The old console stays readable for thirty days. Total downtime is forty minutes of outbound templates; the measurable cost is one week of engineering and a slightly slower month.