Adding a payment method for WhatsApp (and the one that does not work)
The most common stuck point in WhatsApp onboarding, and it is one box on one page.
Meta keeps reporting a payment problem, you can see your card sitting there, and nothing you do clears it. This is the most common stuck point in WhatsApp onboarding, and the cause is almost always the same: the card is attached to the wrong thing.
There is nothing subtle about the fix once you know it, which is exactly why it is worth writing down.
The rule
The card must be added as a business payment method on your business portfolio — the top box on Meta's Payment methods page, labelled "Add business payment method".
A business-level payment method is shared with the accounts underneath it, including your WhatsApp Business Account. That sharing is the entire point, and it is what nothing else does.
The box that does not work
Further down the same page is an Ad accounts tab. A card added there funds advertising and is never shared with your WhatsApp Business Account.
So the sequence people experience is: add a card, see a card, still get told there is a payment problem, conclude something is broken. Nothing is broken. Meta is correctly reporting that the WhatsApp side has no payment method, because it has not.
| Where the card is | Pays for ads | Pays for WhatsApp |
|---|---|---|
| Business portfolio (top box) | Yes | Yes |
| Ad accounts tab only | Yes | No |
How to fix it, step by step
- Open Meta Billing & payments → Payment methods.
- Look at the top box, which carries your business name.
- Click Add next to "Add business payment method" and add your card there.
- Open the WhatsApp Business accounts tab and confirm your account now shows the business payment method.
- Confirm it is attached to the same business that owns the number you connected — a portfolio mismatch produces the identical symptom.
- Go back to your onboarding checklist and re-check.
Step five matters more than it looks. A business with two portfolios — common where an agency was once involved — can have a perfectly valid card on the portfolio that does not own the number.
How to tell it is genuinely fixed
Two signals, and it is worth knowing both because they appear at different times.
The first is the account health check, which is what an onboarding checklist reads. It reports whether your account can send and, if not, why — payment problems surface there in plain language.
The second is what happens when you actually send. Meta returns specific error codes — 131042 and 131045 — that mean the payment method is not set up. If you see either, the card is still not where it needs to be, whatever the billing page appears to show. The wider list is in WhatsApp error codes for merchants.
Why you cannot skip this step
Because most of what a store wants to do costs money. Service conversations — a customer messages you, you reply inside the 24-hour window — have been free and unlimited since 1 November 2024 under Meta's pricing documentation. Templates are not.
So without a working payment method you can answer people who message you, and you cannot send an order confirmation, a shipping notice or anything else that reaches a chat outside the window under Meta's sending messages documentation. That is most of the value of being on the API at all.
Do it early
The best time to add the card is immediately after connecting, before you have built anything. Two reasons: a payment block found on day one is a five-minute fix, and the same block found on the morning of a campaign is a ruined morning.
It also fails in the least helpful way possible — not with a warning while you are building, but with messages that do not send once you are relying on them.
Marking it done does not make it done
Worth knowing if your onboarding checklist lets you tick items off by hand. A live payment block cannot be dismissed that way, deliberately — re-checking with Meta will re-open the step.
That is a feature rather than an annoyance. A checklist that let you mark a real block as complete would be a checklist that lies to you at the worst moment.
Frequently asked
Which card should I use?
A business card belonging to the business that owns the portfolio. Personal cards work, and they make expense reconciliation somebody's problem later.
Does adding a card charge me straight away?
You are billed for the messaging you actually do. Service conversations remain free and unlimited under Meta's pricing documentation; what you pay for is templates.
I added it in the top box and it still says there is a problem.
Check the portfolio owns the number. That is the remaining case, and it is usually a business set up twice.
Does this affect my messaging limit?
No. The tier ladder is separate and runs 250 → 2,000 → 10,000 → 100,000 → unlimited per Meta's messaging limits documentation; business verification is what moves you along it.
What goes wrong when you skip it
The failure mode is specific and worth picturing, because it is what makes this a day-one job rather than a later one.
Everything works while you test. You message your own number, the bot replies, you conclude the setup is finished. Then the first real order arrives, the flow tries to send an order confirmation to a customer who has not messaged you, and that send is refused. No customer complains, because they never knew a message was coming.
You find out days later, from your own numbers or from a customer asking where their order is — which is the most expensive way to learn about a configuration problem.
Why testing does not catch it
| What you tested | Needs a payment method? |
|---|---|
| You message the bot, it replies | No — free service conversation |
| A keyword flow answers you | No |
| The knowledge base answers you | No |
| An order confirmation to a real customer | Yes — it is a template |
| A shipping notification | Yes |
| Any broadcast | Yes |
Read the pattern: everything you naturally test is free, and everything that makes the channel commercially useful is not. That gap is precisely where this problem hides — and the conversations in the top three rows stay free and unlimited under Meta's pricing documentation however long you leave the card unfixed.
A two-minute verification
- Send yourself a template from your own account, to your own phone, from a chat that has been quiet for more than a day.
- If it arrives, the payment method is reaching the account.
- If it fails, read the error. A payment code is definitive; anything else is a different problem.
Doing this once, deliberately, is worth more than any amount of looking at the billing page. It tests the thing you actually care about — whether a message to a cold chat, governed by Meta's sending messages documentation, gets out — rather than whether a card is displayed somewhere.
It is also the first thing to repeat if messages ever stop arriving, alongside the checks in connection problems and what they mean.
A checklist to close the step
- Card added in the top box, on the business portfolio.
- The portfolio is the one that owns the number you connected.
- The WhatsApp Business accounts tab shows the business payment method.
- A test template to a cold chat arrives.
- Your onboarding check, re-run, comes back clear.
Five ticks and the step is genuinely finished. Four of them can be true while the fifth is not, which is why the test send is on the list — it is the only one that exercises the thing you actually care about, and the same reasoning applies to the whole first-month sequence in your first 30 days.
The short version
Top box, business portfolio, "Add business payment method". Not the Ad accounts tab. Confirm the portfolio owns your number, then prove it with one template to a chat that has been quiet for a day.
Frequently asked, part two
Do I need a payment method to test?
No, and that is exactly the trap. Everything inbound works without one, so a test that only exercises inbound proves nothing about your billing.
Can I set a spending limit?
Meta's billing controls are Meta's to configure. What you control here is how much you send, which is the more reliable lever — a frequency budget you decided in advance beats a cap you hit by surprise.
Who should own the card?
The business, on the portfolio, with billing access given to whoever reconciles it. A card belonging to somebody who might leave is a future outage.
Will removing the card stop my automations?
Anything template-based, yes, and quietly. Inbound conversations carry on working, which is why an expired card looks like a partial outage rather than a billing problem.
Does a failed payment method ban my account?
No. It stops templates going out. Your account is not at risk from a billing problem in the way it is from sending people things they did not ask for.