WhatsApp Tech Provider vs BSP: Which Route for a SaaS?

What are the steps to become a Tech Provider?

Meta's steps are short, but the review stages are decided by Meta, not by you. Plan for iterations.

1. Create the app with the WhatsApp use case and connect a business portfolio.
2. Verify your business with Meta. This is a prerequisite for App Review.
3. Prepare App Review. Meta requires basic app settings (icon, privacy policy, category), a first video showing a message created and sent from your app and received in the WhatsApp client, and a second video showing your app creating a message template.
4. Request advanced access to the two permissions above and submit the documentation.
5. Build and test Embedded Signup, then onboard clients through it.

Meta's page for Tech Providers describes this sequence. It does not publish a time estimate, and neither should you promise one to your customers.

Who bills the WABA?

It depends on the role. Solution Partners can extend a credit line and invoice clients; Tech Providers cannot, so their clients add a payment method and Meta bills them directly.

This one fact shapes the commercial model:

• As a Tech Provider you invoice for your software. Message charges appear on the client's relationship with Meta, at Meta's published rates by message category and recipient market (see WhatsApp Business API pricing in 2026). Your customer sees two bills, and you cannot add a margin to Meta's per-message charge.
• Under a Solution Partner the partner can pass message charges through on one invoice. How it prices that, at cost, with a platform fee or with a markup, is a contract question. Ask for it in writing.

Embedded Signup under the account model Meta is rolling out also creates a Messaging account (for templates, billing and webhook subscriptions) separate from the WhatsApp account that holds phone numbers and identity. Meta labels that change as beta and subject to change, so check the current documentation before you design billing around it.

What is a multi-partner solution?

A multi-partner solution lets two partners jointly manage the WhatsApp assets of clients onboarded through the same flow. In Meta's documentation, either partner can create the solution and the other accepts it, and an accepted solution cannot be declined. The solution ID goes into the Embedded Signup configuration, so clients who complete the flow are onboarded to the solution.

What changes in practice:

• Shared access. Both partners receive access to the client's assets.
• Shared credit line. Clients share the credit line of the Solution Partner in the solution, and charges go to the Messaging account that sent each message. A Solution Partner should share its credit line with newly onboarded clients.
• A cap on Tech Provider onboarding. Tech Providers in a solution can onboard up to 200 new clients in a rolling one-week period. Only clients new to the platform count.
• Webhook events. Completion triggers an account update webhook with a PARTNER_ADDED or PARTNER_APP_INSTALLED event.

For a software company this is the middle path: you keep your product and your Embedded Signup flow, and a partner supplies the credit line and billing.

Tech Provider vs BSP: decision table

Choose by what you must own and what you can staff.

If your plan is to resell rather than to embed, see our guide on how to become a WhatsApp Business API reseller and the white-label WhatsApp page.

A worked example: a Riyadh clinic-booking SaaS

"Mawid Cloud" (synthetic) sells appointment software to 300 clinics and wants WhatsApp reminders and two-way chat inside its product.

• Option A, Tech Provider. It verifies its business, records the two App Review videos, requests advanced access, builds Embedded Signup into the clinic settings page and handles tokens, webhooks and template creation. Each clinic adds its payment method and pays Meta for messages; Mawid Cloud invoices its subscription. Engineering is a multi-month commitment, and review outcomes are Meta's call.
• Option B, build on a partner. It integrates a partner's API for onboarding and sending, keeps its own appointment UI and has the partner handle Meta relations and billing.
• Option C, multi-partner solution. It becomes a Tech Provider and creates a solution with a Solution Partner, so clinics share the partner's credit line.

It picks B for the first 100 clinics to learn the product's usage, then revisits A once WhatsApp is a core line. The point is that the choice is reversible only if templates and webhooks are designed to be portable, which is why migrating a WhatsApp number between providers is worth reading before you sign.

What are the risks and common mistakes?

• Treating the label as the decision. Compare billing, support and portability, not whether a vendor says "BSP".
• Underestimating App Review. Rejections for unclear videos or missing documentation cost weeks. Approval is Meta's decision.
• Requesting too many permissions. Meta's implementation page warns that extra selections in the Embedded Signup configuration can cause customers to abandon the flow.
• Ignoring versions. Meta announced that Embedded Signup v2 and v3 would be deprecated on 15 October 2026, so build on v4. Our 2026 changes timeline tracks this.
• Forgetting the 30-second code. Prepare the token exchange before you test.
• No exit plan. Customers own their assets; your architecture should let them move.

How OmniChannels.ai helps

BroadNet, the company behind OmniChannels.ai, is an official Meta Business Solution Provider. Clients are onboarded through Meta Embedded Signup, WhatsApp is charged at Meta's rate with zero markup, and our team handles Meta business verification and display-name approval with you; approval decisions stay with Meta. Software companies can use the REST API and webhooks, and partners can run the programme white-labelled with sub-accounts. Check readiness with the WhatsApp API readiness checklist, read about the partner programme, or contact our team to compare routes for your product.