Take payments in chat
Charge a deposit or the full price inside the conversation, with your own Stripe account, and let the bot wait for the money before it carries on.
Use this guide when a booking should be held with a deposit, or when you would rather be paid before you spend an hour on someone. You connect your own Stripe account, add a payment step where you want it, and the bot sends a Checkout link and waits. The money goes to you directly — Meerlume never holds it and takes no cut. Payments are on the Growth plan and above.
Open Stripe settingsWhat you need first
A Stripe account that can already take payments in your country. Meerlume connects to it with a key you create and paste in — there is no Meerlume application to approve inside Stripe, and no revenue share.
Your money, your account
Payments land in your Stripe balance on your own payout schedule, and refunds are issued from your Stripe dashboard. Meerlume records what happened so the conversation can react to it, and nothing more.
Connect Stripe
Open Integrations → Stripe
From the dashboard sidebar, open Integrations and choose Stripe.
Create a restricted key in Stripe
In your Stripe dashboard go to Developers → API keys → Restricted keys and create one. Give it write access to Checkout Sessions and Webhook Endpoints, and read access to Charges. A restricted key can do those things and nothing else, which is why we ask for one instead of your secret key. Charges is what lets a refund you issue in Stripe reach the customer in the chat.
Paste it in
Paste the key that starts rk_ and press Connect. Meerlume reads the account name to show you which account you just connected, and sets up the webhook endpoint it needs on your account for you.
Try it in test mode first
A key that starts rk_test_ connects your Stripe test mode. Everything works end to end and no real card is charged — Stripe's own test cards do the paying. Payment steps carry a Test mode badge on the canvas while that is the key in use.
A test-mode bot can go live
Publishing is deliberately not blocked in test mode, because trialling a payment flow on a real channel is the point. That does mean a bot can go live taking no real money. Check the badge on the payment step before you tell customers about it.
Add a payment step
On the canvas, hover the step the payment should follow, press the + and choose Take a payment. You can also just ask the builder — “take a 20 euro deposit after they pick a time” — and it will place one.
- The amount is set on the card. Click it and type it the way you would say it: 25, or 25.50. It is charged in your Stripe account's own currency. To charge a step in a different one, ask the builder — “charge this in GBP”.
- The message is what the customer reads, and it must contain {{link}} — that is where the Checkout link goes.
- Waits for payment is on by default. The conversation stops there until the money arrives.
- Two branches: where to go when it is paid, and where to go when it is not.
Put it after the booking, not before
Ask for the appointment first and the deposit second. A customer who has already chosen a time has decided; one asked to pay before they know whether you are free has not.
What the customer sees
Your message arrives with a link. Tapping it opens Stripe Checkout — Stripe's own page, with your business name on it — where they pay by card or whatever else you have enabled in Stripe. Then they land back on a short confirmation page and return to the chat.
The bot confirms the payment in the conversation and carries on down the paid branch. If they close the tab, walk away and come back an hour later, it still works: the conversation is waiting where they left it, and paying at any point picks it up again.
Slower payment methods are fine
Multibanco, bank transfer and similar methods settle over days rather than seconds. The conversation keeps waiting, and the bot carries on when the money actually clears — not when the customer says they have sent it.
When nobody pays
A Checkout link does not last forever. When it expires without being paid, the conversation takes the failure branch you chose — which is usually a message offering to try again, or handing them to you.
- A customer who writes again after the link died is given a fresh one rather than an error. Tapping the dead link itself shows Stripe's own expired page — it is messaging the bot that starts a new one.
- A customer who has already paid and comes back is never charged twice — the step recognises the settled payment and moves on.
- You are told when money arrives through the same notifications as everything else, so a deposit does not depend on anyone watching Stripe.
Turning the wait off
Switch Waits for payment off and the bot sends the link and keeps going straight away. That suits an invoice at the end of a conversation, where nothing later depends on the money. For a deposit that holds a slot, leave it on.
Refunds and the payment log
Integrations → Stripe lists every payment your bots have taken: the amount, the customer, which bot and which conversation, and where it got to. Refund from your Stripe dashboard as usual — Meerlume notices and marks the payment refunded here too.
Disconnecting removes the key and the webhook endpoint Meerlume created on your account. Payments already taken stay in the log and stay in Stripe; payment steps in a published bot stop working until you connect again.
Plans and limits
Payments are included on Growth and Pro. Meerlume charges no fee on what you take — Stripe's own processing fees apply as they would anywhere else. If you move to a plan without payments, your Stripe connection is kept and payment steps stop charging until you upgrade again.
Related guides
Continue with the next part of the setup once this step is stable.
Set up the calendar
Configure timezone, hours, services, and resources so your bot can offer real bookings instead of just collecting requests.
Edit and refine your flow
Use AI-assisted edits for broad changes, then switch to manual flow editing when you need precise control.
Preview drafts and publish
Test the conversation before it goes live, understand the draft/live split, and publish only when the workflow is ready.