Take payments in the chat
A cart submitted in WhatsApp arrives on the conversation as a pending order — line items, quantities, totals, and nothing paid yet. This page covers the step that closes it: one Request payment action that routes itself by the customer's market, taking the money natively inside WhatsApp where Meta supports it, and through a Stripe payment link everywhere else.
Start from a pending order
Payment begins from an order, not from a blank message. The customer browses your catalog in the chat, submits a cart, and the Order panel on the conversation shows what they asked for and where it stands. See WhatsApp Catalog for how carts get there in the first place.
Every order carries a payment state that the panel makes plain:
- pending — the cart exists, nothing has been collected yet.
- paid — payment confirmed and settled.
- failed — the attempt didn't go through; you can request again.
- cancelled — the order was called off.
The state is the source of truth for the order, not the conversation transcript. A customer saying "done, I've paid" is not the same as paid, and the panel is where you check.
One action, routed by market
There is a single Request payment action on the order. What it does depends on where the customer is:
WhatsApp Payments — India (UPI) and Brazil. The customer pays without leaving WhatsApp. They approve the payment in the same thread they've been chatting in, with no link, no browser and no re-entered card details. This is the smoothest version of the flow and it converts accordingly.
Be clear about why it's only two countries: that's a Meta restriction. Native WhatsApp Payments is limited to those markets today. It isn't a feature you can switch on for a customer in Germany or the US by configuring something differently.
A Stripe Payment Link — everywhere else. For every other market, Request payment creates a Stripe Payment Link and sends it into the thread. The customer taps it, pays on Stripe's hosted checkout, and returns to the conversation. It's one extra hop compared with the native flow, but it works globally and uses payment methods customers already recognise.
The Stripe route is also available as a fallback inside India and Brazil. If you'd rather keep every order settling through one processor and one reconciliation report, you can take that route everywhere.
Connect Stripe
The link route needs two secrets, both added in Settings → Secrets:
- A Stripe secret key. Without it, Request payment reports that Stripe isn't connected and no link is created.
- A Stripe webhook signing secret. Without it, payment links still work and customers can still pay — but the confirmation is never verified, so paid orders never confirm and sit on pending indefinitely.
That second one is the failure people hit. Money arrives in Stripe, the order in Arino One still says pending, and someone concludes the integration is broken when it's a missing secret.
Settlement is asynchronous. Stripe notifies your instance at its /api/public/stripe-webhook endpoint, the notification is verified against your signing secret, and the order flips to paid. The customer's tap starts the payment; the webhook is what finishes the order. Expect a short gap between the two, and don't build a flow that assumes the order is paid the instant the link is opened.
After payment
A paid order isn't the end of the record:
- It stays on the contact's CDP history, so the next agent to open the conversation can see what this customer has bought before, and segments can be built on purchase behaviour. See contacts and segments.
- It can trigger a confirmation automation — a receipt, a delivery ETA, a review request a few days later. See build an automation.
Sending the confirmation from the same thread the customer ordered in is the point of doing commerce in chat at all. Don't route it to an email they'll never open.
Practical notes
- Check the state, not the chat. Fulfil against paid, never against a customer's word or a screenshot.
- Test the webhook before your first real order, not after. A test payment that reaches paid proves both secrets are right.
- Failed isn't final. Request payment again on a failed order; cards decline for ordinary reasons.
- The accounts are yours. Stripe pays out to your Stripe account; WhatsApp Payments settles on your own arrangement. Arino One is not in the money path.
Billing
The commerce features — catalog messages, orders, and the Request payment action — are included in the flat $50/month instance connection and management fee. Payment processing fees are charged by your own Stripe account or your own WhatsApp Payments arrangement at their rates, not by Arino, and Arino takes no percentage of what you sell. Messages carrying product cards or payment links are billed as normal messages on your own Infobip account. See billing and plans.
Frequently asked
Which markets support native WhatsApp payments?
India (UPI) and Brazil today. That's a Meta restriction, not an Arino One one — native in-chat payment is only rolled out in those markets, so everywhere else the customer has to pay somewhere other than inside WhatsApp itself.
What if my customer isn't in India or Brazil?
Request payment sends a Stripe Payment Link into the thread instead. The customer taps it, pays on Stripe's hosted page, and comes back to the conversation; the order flips to paid once Stripe confirms. The link route is also available as a fallback inside India and Brazil if you'd rather run everything through Stripe.
What do I need to connect Stripe?
Two secrets, in Settings → Secrets: your Stripe secret key and your Stripe webhook signing secret. Without the secret key, Request payment reports that Stripe isn't connected and no link is created. Without the webhook signing secret, links still work and customers can still pay — but the confirmation never reaches your instance, so paid orders stay stuck on pending. Add both.
How does the order become "paid"?
Asynchronously, on confirmation from the payment side rather than at the moment the customer taps. For Stripe, the settlement notification arrives at your instance's /api/public/stripe-webhook endpoint, is verified against your webhook signing secret, and flips the order to paid. That's why the signing secret is not optional.
Apply this to your own deployment
This guide describes decisions we make on live instances. Tell us your channels, systems and region and we will map it to an architecture outline, a provisioning plan and an indicative commercial model — usually within one business day.