WhatsApp Tech Provider vs BSP: which partner type do you need?

Meta’s partner vocabulary for the WhatsApp Business Platform has changed more than once, and vendors use the labels loosely, which is why “do I need a BSP?” is one of the most common questions we get from resellers adding WhatsApp. This guide settles the WhatsApp Tech Provider vs BSP question in practical terms: what each label means, how onboarding and payment differ, what templates and messaging limits look like either way (they are Meta’s rules, so mostly the same), what “Meta Tech Partner” means when you see it on our site, and when a BSP is still the right answer.

WhatsApp Tech Provider vs BSP: the labels, and why they moved

Three terms matter, and two of them have been renamed.

BSP, now Solution Partner. A Business Solution Provider was the original label for companies Meta vetted to onboard businesses onto the WhatsApp Business API, bill them, and support them. Meta now calls this role Solution Partner; the industry still says BSP, and this guide uses both. A Solution Partner is listed in Meta’s partner directory, can offer line-of-credit billing (Meta invoices the partner, the partner invoices you), and typically runs its own platform.

Tech Provider. A Tech Provider is a software company that builds on the Cloud API so that its own customers can connect their WhatsApp Business Accounts to it. The customer registers the WABA under the customer’s own Meta Business, adds a payment method, and grants the platform access, usually through Meta’s Embedded Signup flow. The Tech Provider’s software sends and manages the messages; Meta bills the customer directly.

Tech Partner. A badge in Meta’s business partner programme for companies whose technology is verified to work with Meta’s platforms. It is the label on our omnichannel page: Smppcube is a Meta Tech Partner for the WhatsApp Business Platform. It says the platform is registered and reviewed for the Cloud API integration; it does not make the platform a BSP, and we never describe it as one.

The single most important background fact, from the WhatsApp without the SaaS middleman guide: Meta deprecated the on-premise API in 2025. Every setup, BSP or Tech Provider, now uses the Cloud API hosted by Meta. The difference between the two is not the technology. It is who owns the account, who gets Meta’s invoice, and who you call when a template is rejected.

Onboarding: who owns the WABA

The WhatsApp Business Account is the asset. It holds your phone numbers, your display names, your approved templates, your messaging limits and your quality rating. Whoever owns the Meta Business that the WABA sits under owns all of that.

In a classic BSP arrangement the WABA is often created under the BSP’s Meta Business, or under a Meta Business the BSP administers, with your number attached. It works, it is fast, and it means your quality rating and your templates live in somebody else’s account. Moving to another provider later means migrating the number, re-submitting templates and, for a while, starting the messaging limits again. Many BSPs will register the WABA under your Meta Business if you ask; the good ones do it by default.

In a Tech Provider setup the WABA is created under your own verified Meta Business from the first day. The platform’s app is granted access through Embedded Signup, a Meta-hosted flow that takes a few minutes once your Meta Business is verified. Verification of the Meta Business itself (documents, a matching website, sometimes a phone call) is the slow part and is the same in both models; Meta’s timeline, not the platform’s.

Either way, plan for three Meta-side approvals before the first message: business verification, display name approval for the number, and template approval for each template you will send. The deployment note on our pricing page says it plainly for our installs: WhatsApp Business verification runs on the operators’ timelines, not ours, so we start it in parallel on day one.

Payment: one invoice or two

This is where the models differ most, and where the money goes.

Meta bills WhatsApp per delivered template message, priced by category and by the recipient’s country, since 1 July 2025. In a Tech Provider setup those charges land on the payment method attached to your WABA (a card in Meta Business Manager, or a Meta credit line if you qualify) and you see Meta’s own invoice. The platform charges its own fee separately, which for a self-hosted platform is the licence you already paid, and nothing per message.

In a BSP setup you usually never see Meta’s rate. The BSP is invoiced by Meta on a line of credit and re-invoices you a blended per-message price that includes its margin. The margin can be a few tenths of a cent per message or a multiple of Meta’s rate; you find out by asking for Meta’s published rate for your destination and comparing. Some BSPs instead charge a transparent flat monthly fee and pass Meta’s charges through unchanged, which is the honest version of the model and worth paying for if you want the support that comes with it.

The question to ask any provider is not “what is your per-message price” but “whose name is on Meta’s invoice”. The answer tells you who owns the account and where the markup lives.

For a reseller, the payment model also decides how you bill your own clients. With WhatsApp charges landing on your WABA, you re-bill clients from your own rate cards on your own platform, with your margin per client and per template category visible in the same ledger as SMS; the rate card guide applies to WhatsApp rows exactly as it does to SMS rows, with category replacing route.

Templates, categories and quality: the same rules either way

Neither model changes Meta’s rules, so it is worth being clear about what does not differ.

Templates must be approved before use, in one of three billed categories (marketing, utility, authentication) plus free-form service replies inside an open customer window. The category is fixed at approval time and decides the price, so a marketing message filed as utility is both a compliance and a billing problem. Submission and status tracking happen through the Cloud API in both models; a BSP may do it for you, a platform lets you do it in your own console.

Messaging limits cap how many unique customers a number can start conversations with in 24 hours, in tiers that start low and grow as the number sends volume with a healthy quality rating. New numbers begin near the bottom of the ladder in both models; there is no shortcut a partner can sell.

Quality rating is Meta’s measure of how recipients react to your messages (blocks, reports). It can throttle a number’s limit or pause a template. It belongs to the number and the WABA, which is another reason to want the WABA under your own Meta Business.

Volume discounts on utility and authentication messages step down with monthly volume and reset monthly. They apply to the WABA that sends the volume. Under a BSP whose WABA aggregates many customers, the discount may accrue to the BSP; under your own WABA, to you.

What a Tech Provider platform actually does

If Meta hosts the connection and bills you directly, what is the platform for? Everything a BSP would otherwise do and keep: template submission and status, contact and consent management, campaign scheduling and approval, session handling for service replies, chatbot flows, delivery and read reporting, per-client rate cards and invoicing for your resold traffic, and the routing that decides whether a message goes out on WhatsApp, falls back to SMS when the customer has no WhatsApp, or takes RCS where the handset supports it. On a self-hosted platform all of that runs on your server, with your contact lists in your database.

That is the shape Smppcube’s omnichannel layer is built to: WhatsApp beside SMS, RCS and Voice, one routing engine, one ledger, one client portal. The Tech Partner registration is what lets your WABA connect to it; the platform’s job is everything from that connection onward.

When a BSP is still the right choice

Honesty matters here, because the BSP model is not a scam and the Tech Provider model is not free of work.

Choose a BSP when you want to outsource the relationship with Meta: no technical team to run a platform, a procurement rule that needs one vendor invoice, a need for line-of-credit billing rather than a card on the account, or simply a human desk to call when a template is rejected at nine on a Friday. Those are real services. Pay a flat fee for them and make sure the WABA is registered under your Meta Business so you can leave without losing your history.

Choose the Tech Provider model when you resell messaging and the WhatsApp margin is yours to keep, when your contact data has to stay on your infrastructure, when you already run SMS and want WhatsApp on the same ledger, or when a per-message markup at your volume would cost more than a platform. If you send a few thousand WhatsApp messages a month from a single business, the difference in cost is small and the convenience of a BSP may win; at a reseller’s volume the markup is the largest line on the bill after Meta’s own.

A checklist before you sign with anyone

1. Whose Meta Business will the WABA sit under? Insist on yours.
2. Whose name is on Meta’s invoice, and can you see Meta’s published rate for your destinations?
3. Is the provider’s fee flat, per message, or both? Get the number in writing.
4. Where do your contact lists and templates live, and can you export them?
5. What happens to the phone number, templates and messaging limits if you leave?
6. Is the platform registered with Meta for the Cloud API (a Tech Provider or Tech Partner), or reselling somebody else’s registration?

A provider who answers all six without hesitation is the one to work with, whichever label they carry. A provider who answers the first with “ours, it’s easier” is telling you where the lock-in will be.