Skip to content

Multi-Partner Solution(MPS)

Also called: Multi-Partner Solutions · Partner solution · solutionID

A Meta arrangement in which a Tech Provider and a Solution Partner jointly serve clients: one builds the product, the other supplies the credit line.

Reviewed

What is a Multi-Partner Solution?

A Multi-Partner Solution (MPS) is a formal arrangement on the WhatsApp Business Platform in which two partner businesses jointly provide WhatsApp services to the same clients. The common case pairs a Tech Provider, a software company that builds the product its clients use (for example a CRM, a helpdesk or an e-commerce platform), with a Solution Partner, which has a credit line it can extend to those clients and can invoice them for API usage. Meta's own example: a Tech Provider creates a multi-partner solution with a Solution Partner who shares its credit line with clients onboarded through the joint solution.

The solution is created and accepted in Meta's tools and gets an ID. When the Tech Provider launches Embedded Signup with that ID in the extras.setup object, the client's onboarding grants access to both partners' apps and attaches the Solution Partner's credit line, so the client does not have to enter a card. Each partner then works with the permissions the solution defines, and the Solution Partner handles billing for Meta's per-message charges.

An MPS is different from ordinary single-partner Embedded Signup, in which one partner onboards a client alone and either extends its own credit line (a Solution Partner) or leaves the client to add a payment method (a Tech Provider). It is also different from a business simply sharing its WhatsApp assets with two unrelated partners; in an MPS the partnership and the billing route are agreed in advance and applied automatically at signup.

Key takeaways

  • A Multi-Partner Solution (MPS) lets a Tech Provider and a Solution Partner jointly manage the WhatsApp assets of clients onboarded through it.
  • The Tech Provider usually owns the product and the onboarding; the Solution Partner shares its credit line so clients need not add a payment method.
  • Clients join an MPS by completing Embedded Signup with the solution's ID passed in the extras.setup object.
  • Clients created through partner-initiated account creation cannot join an MPS during creation, but can be added to one afterwards.
  • Under the new account model, a client can take on a new solution while keeping its WhatsApp account shared with the previous one.

See InfiQ pricing

Interactive stop

Trace one signup through a Multi-Partner Solution

7 / 7
Client businessclicks Connect WhatsApp
Tech Provider applaunches ES + solutionID
Embedded SignupMeta pop-up
Client WABAin client's portfolio
Solution Partnercredit line + invoice
Meta billingper delivered message
  • Client business to Tech Provider app: Signs up
  • Tech Provider app to Embedded Signup: FB.login + solutionID
  • Embedded Signup to Client WABA: Creates or connects
  • Client WABA to Tech Provider app: Access: product
  • Client WABA to Solution Partner: Access: billing
  • Solution Partner to Meta billing: Credit line pays
  • Solution Partner to Client business: Invoices client

Hop 7 of 7

Solution PartnerClient businessInvoices client

Arrives at Client business — clicks Connect WhatsApp.

Watch a client onboard through the Tech Provider's signup with a solution ID, and see how access goes to both partners while billing runs through the Solution Partner's credit line.

Hop 7 of 7: Solution Partner to Client business — Invoices client.

Why does a Multi-Partner Solution matter?

For a software company, becoming a Solution Partner is a long process, but asking every client to add a card for Meta's charges loses signups and fails for businesses that need a rupee invoice. An MPS lets the software company keep control of its product and onboarding while a Solution Partner takes on credit, invoicing and some support. For the client it means one signup flow, a familiar product and a proper invoice, and for both partners a clear, Meta-recognised split of responsibilities.

How does a Multi-Partner Solution work?

  1. Agree roles and commercials

    The Tech Provider and the Solution Partner agree who supports what, how Meta's charges and any platform fees are invoiced, and what happens when a client leaves. Meta's tools record the solution, not your commercial contract.

  2. Create the solution and invite the partner

    One partner creates the Multi-Partner Solution in Meta's partner tools, choosing the partner and the permissions each app needs, and sends a request. The other partner reviews and accepts it, and the solution becomes active with a solution ID.

  3. Launch Embedded Signup with the solution ID

    The Tech Provider passes extras: { setup: { solutionID: "{SOLUTION_ID}" } } to FB.login. Clients completing the flow are onboarded into the solution, with both apps granted access.

  4. Each partner finishes its side

    The Tech Provider exchanges the code, subscribes to webhooks and registers the number; the Solution Partner's credit line covers the client's Meta charges and the Solution Partner invoices the client.

  5. Manage changes and offboarding

    Clients can later move to another solution. Since the new account model, a client can keep its WhatsApp account shared with the previous solution while taking on a new one, and offboard from the old one when it chooses.

A Multi-Partner Solution in code

FB.login((response) => {
  const code = response.authResponse?.code;
  if (code) sendCodeToServer(code); // exchange within ~30 seconds
}, {
  config_id: "{CONFIG_ID}",
  response_type: "code",
  override_default_response_type: true,
  extras: {
    setup: {
      solutionID: "{SOLUTION_ID}", // the active Multi-Partner Solution
    },
  },
});

The only front-end difference from single-partner onboarding is the solutionID.

Example: An Ahmedabad SaaS partners for credit

An Ahmedabad company sells an order-management app to 600 small distributors and became a Tech Provider so they could message buyers on WhatsApp. Many distributors abandoned signup at the payment-method step, and others needed a GST invoice. The company set up a Multi-Partner Solution with a Solution Partner. Its signup button now launches Embedded Signup with the solution ID; distributors finish without entering a card, the Solution Partner's credit line covers Meta's charges and invoices them monthly, and the SaaS company keeps building and supporting the product. Completed signups rose noticeably in the first month.

— An Ahmedabad SaaS partners for credit

A Multi-Partner Solution: key facts and limits

Typical pairing
Tech Provider (product) + Solution Partner (credit line)
How clients join
Embedded Signup with extras.setup.solutionID
Who pays Meta
Solution Partner's credit line; it invoices the client
Partner-initiated accounts
Cannot join at creation; can be added afterwards
Switching solutions
Possible; old solution can stay shared until offboarded
Tokens
Each partner uses business tokens scoped to the client

Common mistakes with a Multi-Partner Solution

  • Launching signup without the solution ID

    A missing or wrong solutionID silently onboards the client to the Tech Provider alone, without the credit line, and the client hits a payment wall later. Read the ID from config, not a hard-coded string, and test with a sandbox client.

  • Using a solution that is not active

    A solution still waiting for the other partner's acceptance cannot onboard clients properly. Confirm the solution is active in Meta's partner tools before switching your signup button to it.

  • No agreement on support and offboarding

    Clients do not care which partner owns a fault. Write down who handles template rejections, number issues and billing disputes, and what happens to access and credit when a client leaves.

  • Ignoring credit risk

    Meta notes that with the new account model clients can add or change partners without migrating their number, which removes a natural switching barrier. Solution Partners should set credit limits and monitor usage accordingly.

Best practices for a Multi-Partner Solution

  • Show clients who invoices them for Meta's charges during signup, not after the first bill.
  • Log the solution ID with each onboarding so support can tell MPS clients from direct ones.
  • Re-test the whole flow whenever either partner changes its app permissions.

MPS FAQs

Why would a Tech Provider use a Multi-Partner Solution?+
To offer clients a credit line and direct invoicing without becoming a Solution Partner itself. The Solution Partner in the solution extends its credit line, so clients skip adding a payment method.
How does a client join a Multi-Partner Solution?+
By completing the Tech Provider's Embedded Signup flow launched with the solution's ID. The flow grants both partners' apps the agreed access and attaches the Solution Partner's credit line.
Can an existing client be moved into a Multi-Partner Solution?+
Yes, it can be added afterwards. Clients created through partner-initiated account creation cannot be put in an MPS during creation, but Meta allows adding them to one later.
Who supports the client in a Multi-Partner Solution?+
Whoever the partners agree. Meta records the solution and the access, not the support split, so put responsibilities in the partner contract and tell clients where to go.

Talk to InfiQ

From definition to your first message

InfiQ is an official Meta Business Partner. Start a 7-day free trial — no card needed — and see this running on your own number.

Start free trialBrowse all 550 terms