Payments
By Conversa Labs
By Conversa Labs
Connect a gateway (Asaas/Mercado Pago), create charges (PIX/boleto/card), subscriptions, discounts, paid scheduling and reports.
Payments overview
Overview The Payments module turns ConversaLabs into a billing counter inside the conversation itself. You connect a gateway (Asaas or Mercado Pago), create one-off, recurring or deal-based charges, and send the payment link right in the chat β with PIX (QR code + copy-and-paste), boleto and card (hosted checkout). Everything happens without leaving the platform: the customer receives the charge in the same window where they talk to you, pays, and the status updates automatically when the gateway confirms the payment. You don't have to log into your bank's panel to follow up β ConversaLabs reflects paid, overdue, refunded and canceled in real time. Prerequisites - The Payments module must be enabled for your account. It is optional and off by default β ask an administrator or the platform operator to turn it on. - An active account on a supported gateway: Asaas or Mercado Pago. - Administrator permission to connect the gateway and configure webhooks. - To charge from the CRM or the Calendar, those modules must also be enabled. Step by step 1. Make sure the Payments module is enabled for the account. 2. Connect a gateway (Asaas or Mercado Pago) with your credentials and environment β see Connect a gateway. 3. Create your first charge (one-off, from the catalog or from a deal) and send it in the chat. 4. Track the charge status: pending, awaiting payment, paid, overdue or refunded. 5. For recurring revenue, set up subscriptions and plans. 6. Follow results in the reports (revenue, average ticket, MRR and churn). Settings & options - Gateways: connect one or more gateways; each connection has its own environment (production or sandbox) and credentials. - Payment methods: PIX, boleto and card via hosted checkout. The availability of each method depends on the chosen gateway. - Charges: one-off, with line items, discounts and value adjustment. - Subscriptions and plans: recurring billing delegated to the gateway and mirrored on the platform. - Refunds: full or partial, depending on the gateway. - Reports: revenue by status, by gateway and by currency, average ticket, MRR and churn. Use cases - Close a sale on WhatsApp and send the PIX right away, with QR code and copy-and-paste. - Charge a service from a deal won in the CRM, without retyping amounts. - Create a monthly subscription for a recurring customer. - Apply a one-time discount to a charge before sending it. - Require prepayment for a Calendar booking (paid scheduling). Tips, limits & best practices - The module only works with hosted checkout β the platform never captures card data, which keeps you out of PCI scope. - Amounts are handled in major units (reais, not cents): R$ 49.90 is 49.90. - The webhook is the source of truth for status: trust it, not the checkout "success" screen. - Keep gateway credentials current; expired tokens stop new charges. Troubleshooting - I don't see Payments in the menu: the module isn't enabled for your account or profile β talk to an administrator. - I can't create a charge: check that a gateway is connected and valid. - Status won't update: review the webhook setup in Refunds, webhooks and reports. See also - Connect a gateway: Asaas and Mercado Pago - Create a charge and send it in the conversation - Subscriptions and recurring plans - Discounts and value adjustment - Paid scheduling - Refunds, webhooks and reports
Connect a gateway: Asaas and Mercado Pago
Overview Before you can charge anyone, you need to connect a payment gateway. ConversaLabs supports Asaas and Mercado Pago. Each connection stores the gateway credentials, sets the environment (production or test) and registers a webhook β the channel the gateway uses to tell the platform when a charge is paid, becomes overdue or is refunded. You can have more than one connection (for example, an Asaas production account and a Mercado Pago one for a different flow). Every charge is created on a specific connection. Prerequisites - Payments module enabled and administrator permission. - An account on the chosen gateway: - Asaas: an API Key from the Asaas panel. - Mercado Pago: an Access Token and Client Secret from your application credentials. - Decide the environment: production (real charges) or sandbox (testing). Step by step 1. Open the Payments settings and choose to add a new connection. 2. Pick the gateway: Asaas or Mercado Pago. 3. Enter the credentials: - Asaas: paste the API Key. - Mercado Pago: paste the Access Token (and the signing secret used to validate the webhook). 4. Choose the environment: production or sandbox. 5. Save. The platform validates the credentials against the gateway. 6. Set up the webhook: the platform generates the notification URL and the verification secret. In many cases registration is automatic; when it isn't, copy the URL shown and register it in the gateway panel. 7. Run a sandbox test (a PIX charge, for example) and confirm the status changes on its own when the payment is simulated. Settings & options - Environment: production or sandbox per connection. Don't mix credentials from different environments. - Webhook: the URL is unique per connection and the gateway authenticates every notification: - Asaas sends its own token in the request header, compared securely to the one the platform stored. - Mercado Pago signs each notification; the platform validates the signature before processing. - Methods supported per gateway: | Capability | Asaas | Mercado Pago | |---|---|---| | PIX | Yes | Yes | | Boleto | Yes | Yes | | Card (hosted checkout) | Yes | Yes | | Installments | Yes | Yes | | Subscriptions | Yes | Yes | | Reusable plans | β | Yes | | Partial refund | Yes | Yes | Use cases - An operator already using Asaas connects the key and starts charging on WhatsApp without switching systems. - A business selling across Latin America connects Mercado Pago. - A team that wants to test before charging for real uses the sandbox environment first. Tips, limits & best practices - Treat credentials as secrets: they are stored encrypted and never shown again on screen after you save them. - Use sandbox to validate the whole flow before going live. - Asaas auth uses an access_token header (not Authorization: Bearer). - Mercado Pago notifies only the payment identifier; the platform queries the gateway to read the full state β this is expected. Troubleshooting - Invalid credentials: check that you copied the right key/token and that the environment matches the gateway's (a test token only works in sandbox). - Status won't update: the webhook isn't arriving. Confirm the URL is registered on the gateway and the verification secret matches. - Notification rejected (401): the webhook signature/token doesn't match β re-register the webhook. See also - Payments overview - Create a charge and send it in the conversation - Refunds, webhooks and reports
Create a charge and send it in the conversation
Overview The charge is the heart of the module. You create a charge with an amount, a description and line items, pick the method (PIX, boleto or card via hosted checkout) and send it right in the conversation. The customer receives a payment card in the window itself β with the PIX QR code and copy-and-paste string, the boleto barcode line, or the checkout link β and the status updates when the gateway confirms. There are three ways to start a charge: one-off (type the amounts), from the catalog (pick ready-made products) or from a deal in the CRM (reuse the amount already recorded). Prerequisites - A connected, valid gateway (see Connect a gateway). - To charge from the catalog, the Catalog module enabled with products registered. - To charge from a deal, the CRM module enabled and a deal with an amount. - A contact with minimum data (name and, ideally, email and phone) for the gateway customer. Step by step 1. In a conversation, open the create charge action (or create one from the Payments area). 2. Choose the amount source: - One-off: enter amount, description and, optionally, line items. - Catalog: select products; the amount is summed automatically. - Deal: select a CRM deal; the amount is reused. 3. Select the payment method: PIX, boleto or card (hosted checkout). 4. (Optional) Apply a discount or adjust the value β see Discounts and value adjustment. 5. Set the due date, when applicable. 6. Create the charge. The platform generates the PIX (QR + copy-and-paste), the boleto (barcode line) or the checkout link, depending on the method. 7. Send it in the conversation: the payment card appears for the customer in the same window. 8. Watch the status move from pending to paid automatically once the gateway confirms. Settings & options - Methods: PIX (QR code + copy-and-paste), boleto (barcode line/PDF) and card via hosted checkout β the platform never asks for the card number. - Line items: describe each product/service with quantity and amount; the total is the sum of the lines. - Due date: deadline for PIX/boleto. - Mark as paid manually: record payments received off-platform (where the gateway supports it) to keep the history consistent. - Resend: you can resend the payment card in the conversation at any time. Use cases - Close a sale on WhatsApp and send the PIX right away. - Build a charge with several items from the catalog. - Charge a deal won in the CRM without retyping the amount. - Let the customer choose between PIX and card. Tips, limits & best practices - Amounts are in major units (R$ 49.90 = 49.90); the total is the sum of price Γ quantity across the lines β never divide by 100. - The card always goes through the gateway's hosted checkout: zero card data on the platform. - Confirm the customer's name and contact before creating β the gateway uses that data to identify the payer. - Don't trust the "success" screen: the real status arrives via the webhook. Troubleshooting - Error creating the charge: check that the gateway is connected and the contact has the minimum data. - Customer didn't get the PIX: resend the payment card in the conversation. - Paid but still pending: review the webhook setup (see Refunds, webhooks and reports). - Method unavailable (e.g., card): it may be a limitation of the chosen gateway β check the capability matrix in Connect a gateway. See also - Payments overview - Connect a gateway: Asaas and Mercado Pago - Discounts and value adjustment - Subscriptions and recurring plans - Refunds, webhooks and reports
Subscriptions and recurring plans
Overview For revenue that repeats (memberships, service plans, retainers), use subscriptions. You set the amount and the cycle (weekly, monthly, yearly, etc.), and the gateway generates the recurring charges automatically. ConversaLabs mirrors each generated charge and the subscription state (active, paused, canceled), and feeds the MRR and churn indicators in the reports. On Mercado Pago you can also use reusable plans (a subscription template that serves many customers). On Asaas, recurrence is configured directly on the subscription. Prerequisites - A connected gateway that supports subscriptions (both Asaas and Mercado Pago do). - For reusable plans, use Mercado Pago (Asaas does not expose plans as a separate entity). - A contact/customer with valid data on the gateway. Step by step 1. In the Payments area, choose to create a subscription. 2. Pick the gateway (the connection) and the customer (contact). 3. Set the amount and the billing cycle (for example, monthly). 4. Set the next charge date and the method (PIX, boleto or card, depending on the gateway). 5. (Optional, Mercado Pago) Link it to an existing plan. 6. Save. The gateway starts generating charges on the defined cycle. 7. Track each generated charge and the subscription state on the platform; the customer receives the charge as usual. Settings & options - Cycle: weekly, biweekly, monthly, quarterly, semiannual or yearly (the exact offering depends on the gateway). - Subscription state: active, paused, canceled β reflected from the gateway's notifications. - Plans (Mercado Pago): create a plan once and reuse it across many subscriptions. - Cancellation: cancel the subscription on the platform; the gateway stops future charges. - Generated charges: each cycle becomes a mirrored charge with its own status. Use cases - Monthly fee for a subscription service. - Recurring support or consulting plan (retainer). - Content club/subscription with automatic renewal. Tips, limits & best practices - Recurrence is delegated to the gateway β it generates and bills each cycle; the platform reflects the result. - Use plans (Mercado Pago) when many customers subscribe to the same offer β it's easier to maintain. - The reports' MRR normalizes each active subscription to an equivalent monthly amount; churn counts the ones canceled in the period. - Communicate the cycle and amount clearly to the customer before activating the subscription. Troubleshooting - The next charge wasn't generated: confirm the subscription state (it may be paused or canceled) and the webhook setup. - Plans don't appear: reusable plans are a Mercado Pago feature; on Asaas configure recurrence on the subscription itself. - I canceled and it still charged: check that the cancellation was confirmed by the gateway; the effect applies to future cycles. See also - Payments overview - Connect a gateway: Asaas and Mercado Pago - Create a charge and send it in the conversation - Discounts and value adjustment - Refunds, webhooks and reports
Discounts and value adjustment
Overview You can lower the amount of a charge or subscription by applying discounts. The discount can be per line item (on a specific item) or on the total of the transaction. The amount sent to the gateway is always the net value β that is, the subtotal minus the discount. The payment providers are not changed; they only receive the final, already-calculated amount. Optionally, your account can require a reason when applying a discount, to keep a history and control of who granted each reduction. Prerequisites - Payments module enabled and a connected gateway. - Permission to create/edit charges and subscriptions. - If your connection requires a discount reason, have the justification ready. Step by step 1. When creating (or editing) a charge or subscription, locate the discount field. 2. Choose where to apply it: - Per item: enter the discount on the matching line item. - On the total: enter the discount over the sum of the lines. 3. Set the discount amount. 4. If prompted, enter the discount reason. 5. Check the final amount (subtotal β discount) before saving. 6. Save and, for a charge, send it in the conversation as usual. Settings & options - Per-item discount vs. total discount: combine both when needed β the total reflects the sum of the reductions. - Require discount reason: an option per connection; when on, the discount is only accepted with a justification. - Net value: the gateway always receives the amount with the discount already applied; there is no later calculation on the provider side. - Reports: the total discounts granted appears in the Payments reports. Use cases - Grant a one-time discount to close a sale. - Apply a reduction to a specific item on a charge with several products. - Offer a promotional amount on a subscription. - Keep traceability of who granted each discount by requiring a reason. Tips, limits & best practices - The discount reduces the net value sent to the gateway β check the total before sending. - Standardize discount reasons to make analysis in the reports easier. - To track the impact, use the discounts granted metric and the average ticket in the reports. - Remember: amounts are in major units (R$ 10.00 = 10.00). Troubleshooting - I can't save without a reason: your connection requires a justification β fill in the discount reason. - The total didn't add up: check whether there are per-item and total discounts at the same time; the final amount is the subtotal minus the sum of the discounts. - Discount doesn't show on the gateway: the provider only receives the net value; the discount breakdown stays on the platform. See also - Create a charge and send it in the conversation - Subscriptions and recurring plans - Refunds, webhooks and reports - Payments overview
Paid scheduling
Overview Paid scheduling connects the Calendar to the Payments module: the customer only confirms a booking after paying. When someone books an event type marked as paid, the platform creates a charge automatically (a PIX, for example), holds the slot while the payment is pending, and confirms the booking on its own when the gateway reports it as paid. It's ideal for consultations, sessions and services where you want to secure the customer's commitment with a prepayment β reducing missed appointments and no-shows. Prerequisites - Calendar and Payments modules enabled. - A connected, valid gateway. - An event type (in the Calendar) configured to charge β with an amount and a payment mode. Step by step 1. In the Calendar, open the event type that should require payment. 2. Set the event type's payment mode (for example, a one-off payment to release the booking). 3. Enter the amount for the booking and the method (PIX, boleto or card, depending on the gateway). 4. Save the event type. 5. When a customer books that event type, the platform creates the charge and leaves the booking awaiting payment. 6. The customer pays; the gateway notifies and the booking becomes confirmed automatically. 7. Track both the charge (in Payments) and the booking (in the Calendar). Settings & options - Payment mode per event type: set in the Calendar (for example, mandatory prepayment). - Booking awaiting payment: the slot is reserved/held until confirmation; unpaid bookings may expire according to the configured rule. - Automatic confirmation: the booking turns confirmed when the gateway's payment event arrives β no manual action. - Charge method: PIX, boleto or card, depending on the connected gateway. Use cases - A clinic that requires upfront payment for appointments. - A professional charging a deposit to reserve a slot. - High-demand services where prepayment secures the commitment. Tips, limits & best practices - Use PIX to release the booking faster (near-immediate confirmation). - Make it clear in the event type description that the slot is only confirmed after payment. - Set a reasonable deadline for the pending booking, so slots aren't held for too long. - Confirmation depends on the gateway's webhook; keep it configured correctly. Troubleshooting - The booking doesn't confirm after payment: check the gateway's webhook (see Refunds, webhooks and reports). - No charge option on the event type: confirm the Calendar and Payments modules are enabled and a gateway is connected. - The slot was released without payment: review the event type's payment mode (it should require prepayment). See also - Payments overview - Create a charge and send it in the conversation - Subscriptions and recurring plans - Refunds, webhooks and reports
Refunds, webhooks and reports
Overview This article covers what happens after the charge is sent: how to return money (refund), how the webhook keeps statuses in sync without you doing anything, and which reports show the financial health of the operation. The webhook is the channel the gateway uses to tell the platform about every change (paid, overdue, refunded, canceled). That's why it is the source of truth: the platform updates the charge status from the webhook, not from the checkout "success" screen. Prerequisites - Payments module enabled and a connected gateway with the webhook configured. - Permission to issue refunds. - For the reports, charges/subscriptions recorded in the period. Step by step Refund a charge 1. Open the charge you want to refund (already paid). 2. Choose refund. 3. Select full (returns the entire amount) or partial (enter the amount to return). 4. Confirm. The platform requests the refund from the gateway. 5. Watch the status change to refunded (or partially refunded) when the gateway confirms. Check the webhook 1. In the gateway connection settings, review the webhook URL and the verification secret. 2. Make sure the URL is registered in the gateway panel. 3. Run a test and see the status update automatically. Read the reports 1. Open the Payments reports. 2. Filter by period. 3. Analyze the indicators (revenue, average ticket, MRR, churn) and the breakdowns by status, gateway and currency. Settings & options - Full vs. partial refund: both supported by the current gateways. - Webhook: authenticated by each gateway (token in the header on Asaas; signature on Mercado Pago); repeated notifications are handled safely (no duplicated effects). - Report indicators: | Indicator | What it shows | |---|---| | Revenue | Total received in the period | | Average ticket | Average amount per paid charge | | Discounts granted | Sum of the discounts applied | | By status | Distribution across paid, pending, overdue, etc. | | By gateway | How much came in via Asaas / Mercado Pago | | By currency | Breakdowns when there is more than one currency | | MRR | Monthly recurring revenue from active subscriptions | | Churn | Subscriptions canceled in the period | Use cases - Return an amount to a customer who gave up (full refund). - Reverse part of a charge (partial refund). - Track recurring revenue growth via MRR. - Spot subscriber loss via churn. Tips, limits & best practices - Always trust the webhook for status; the checkout screen may render before confirmation. - The refund is processed by the gateway β the time for the money to reach the customer follows the provider/payment-method rules. - Track MRR and churn together for the real picture of recurrence. - Keep the webhook URL reachable and the verification secret correct; without it, statuses won't update. Troubleshooting - Status never changes to paid: the webhook isn't arriving or was rejected (wrong signature/token) β reconfigure the webhook on the connection. - Refund won't complete: confirm the charge was paid and that the gateway supports the requested refund type. - Empty report: check the period filter and whether there are charges in the range. - MRR looks wrong: confirm the subscription cycles; MRR normalizes each one to the monthly equivalent. See also - Payments overview - Connect a gateway: Asaas and Mercado Pago - Create a charge and send it in the conversation - Subscriptions and recurring plans - Discounts and value adjustment