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 Conversa Labs 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 β Conversa Labs 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. Conversa Labs 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. - Last reconciliation diagnostics: the scheduled check compares charges and subscriptions with the gateway to cover missed notifications. If a record fails, its connection card under Settings β Payments β Connections remains red with the total count and up to the first three external identifiers and reasons. Other records continue processing; raw responses, customer data, and credentials never appear in this diagnostic. - 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. - The last reconciliation had failures: note the identifier and reason shown on the card, verify the connection and environment, and confirm that the record still exists at the gateway. A failure remains visible and never silently changes the local record. The next scheduled check replaces the diagnostic; the alert disappears only after a run with no failures. 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. For PIX payments, the label and code appear separately for easier reading; even a long code stays inside the card. Use the copy action to copy the complete code. 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. - Asaas advanced options: percentage late fee, interest and early-payment discount can be set on the charge; printed postal delivery appears for boleto only. This is a payment condition and does not replace the commercial discount applied to the charge amount. Leave late fee and interest blank to preserve the account defaults; enter 0 to disable them explicitly for that charge. - Asaas return: enter a public HTTPS URL to take the payer back to your site. Automatic redirect is sent only when a valid URL is present. - Mercado Pago checkout: for hosted card payments, choose the installment limit and, when needed, separate public HTTPS return URLs for approved, rejected and pending payments. Automatic return requires the approved URL. - Connection gate: the screen shows only capabilities advertised by the selected gateway. The API rejects incompatible options too; hiding a control is not the only protection. - 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. - Automatic payer data: tax ID and address come from the contact's native data (the document is prefilled so you can check it; the billing address takes priority over the principal one). Fill it once on the contact and never retype it β see Contact fiscal data and address. View details and history In the charge list, click the customer to open the detail β including Pix or manually entered charges that have no hosted payment page. The primary action follows what the charge can actually do: copy the Pix code, open the boleto/checkout, or, when Asaas allows it and the charge is open, mark it as paid manually with a justification. The history shows the newest events first, identifies the operator or system/gateway and displays the recorded reason. Long histories are paginated; changing pages does not mutate the charge. Use this timeline to review creation, updates, payment, overdue state, cancellation and refunds instead of relying only on the current status. 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 - If the network fails after submit, retry from the same open form: it preserves the operation key and recovers the existing charge instead of charging the customer twice. - 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. - Use public HTTPS return URLs only. Never place tokens, passwords or other secrets in them. 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. Conversa Labs mirrors each generated charge and the subscription state (active, paused, canceled), and feeds the MRR and churn indicators in the reports. You can also use reusable local plans: they store connection, amount, currency, and cycle for many subscribers. When each subscription is created, the platform sends the recurrence to the gateway; a local plan does not mean a plan entity already exists in the gateway dashboard. Prerequisites - A connected gateway that supports subscriptions (both Asaas and Mercado Pago do). - To use a reusable plan, keep its linked connection active. The plan currency must match that connection's settlement currency. - 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, Asaas) Set a maximum number of charges or an end date. The every-two-months cycle also appears when the connection supports it. 6. (Optional) Select a local plan. Connection, amount, currency, and cycle are filled and locked so the subscription remains consistent with the chosen template. 7. Save. The gateway starts generating charges on the defined cycle. 8. Track each generated charge and the subscription state on the platform; the customer receives the charge as usual. Settings & options - Cycle: weekly, biweekly, monthly, every two months (Asaas), quarterly, semiannual or yearly. The screen shows only cycles supported by the connection. - Asaas limits: maximum number of charges stops after a number of cycles; end date stops at the chosen boundary and cannot be before the first charge. You can also adjust the end date later under Edit subscription; the maximum number of charges is set at creation. - A subscription is not an installment plan: the gateway bills the amount once per cycle. To split one purchase into installments, create a one-off card charge. - Subscription state: active, paused, canceled β reflected from the gateway's notifications. - Local plans: create a template once and reuse it across compatible subscriptions. The gateway still receives and runs each individual subscription. - 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 - If the network fails during creation, retry without closing the form: the same operation resumes, and an uncertain gateway response never blindly creates another subscription. - Recurrence is delegated to the gateway β it generates and bills each cycle; the platform reflects the result. - Use local plans when many customers subscribe to the same offer β it keeps connection, price, currency, and cycle consistent. - 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: confirm that the plan is not archived, its connection is active and supports subscriptions, and its currency matches the settlement currency. - 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
Manage payment plans and offers
Overview The Payments module provides two reusable catalogs: - Plans store a connection, amount, currency and cycle for new subscriptions. - Offers store price, payment method, type and optional links to a connection and product. The Offers screen is administrative. It never accepts an offer or creates a charge without a contact or purchase context. Prerequisites - Payments must be enabled for the account. - Have at least one active Asaas or Mercado Pago connection to create plans. - To link an offer, create the product in Catalog first. - Permanent deletion requires payment-administration permission. Step by step 1. Open Payments in the sidebar. 2. Go to Plans or Offers. 3. Use search, filters and sorting to find records. The page and filters remain in the URL. 4. Click New plan or New offer, complete the fields and save. 5. Archive a record to remove it from use. Open Archived to restore it or, with the required permission, permanently delete it. 6. For multiple rows, select records on the page and use the bulk-action bar. If a row fails, review the displayed IDs and fix only those rows. 7. When creating a subscription, select the optional plan. The screen fills and locks connection, amount, currency, and cycle so the subscription matches the template. 8. Use Export CSV to download the current filtered result or, when records are selected, only the selected records, including selections kept while moving between pages. Settings & options Plans A plan is a local template; it does not claim to already exist as a gateway entity. Actual recurrence is created at the gateway only when a subscription starts. Currency must match the connection settlement currency, and displayed cycles follow its capabilities; for example, every-two-month billing appears only when the gateway supports it. Offers Choose order bump, upsell or downsell. The connection may use the account default and the product is optional. Archiving an offer deactivates it; restoring it keeps it inactive until it is reviewed and enabled again. Use cases - Reuse one membership price across several subscriptions. - Offer setup, priority support or an add-on during checkout. - Keep seasonal offers inactive without losing their configuration. - Separate offers by product, connection, type or status. Tips, limits & best practices - Confirm the connection settlement currency before publishing prices. - Archive before permanent deletion. Permanent deletion cannot be undone. - Restoring an offer does not activate it automatically; review price, product and connection first. - A bulk action is processed record by record. A partial result is expected when a row violates a lifecycle rule. Troubleshooting - Every-two-month billing is missing: the selected connection does not advertise that capability. - A payment method is missing: the selected connection does not support it. - I cannot delete a record: archive it first and confirm your role allows permanent deletion. - The list is empty after filtering: use Clear filters; the state can also be removed from the URL. - A restored offer is inactive: this is the safe behavior. Edit and enable it after review. See also - Create charges and send them in a conversation - Subscriptions and plans
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
Payment terms and installment simulation
Overview A charge involves more decisions than just the amount. Payment terms gathers everything that changes what the customer pays and what your business receives: - Late fee β charged once, when a charge passes its due date unpaid. - Monthly interest β accrues while the charge stays overdue. - Early-payment discount β a reduction if the customer pays before a given date. - Installments and who pays the interest β the business absorbs the cost, or the customer pays it. And the simulation answers, before you charge anyone, the two questions that matter: how much does the customer pay per month? and how much do you receive? Prerequisites - An active gateway connection under Payments β Settings. - Terms depend on the gateway. Asaas accepts late fee, interest and early-payment discount; Mercado Pago exposes none of them, so those fields do not appear on a Mercado Pago connection. - Installments exist only on one-off charges paid by credit card. Subscriptions bill one amount per cycle β neither gateway splits a recurrence into installments. Step by step Set the account default 1. Go to Payments β Settings β Connections and edit the connection. 2. Under Installment interest, choose who pays: - The business absorbs it β the customer pays the charge amount split into installments, and the gateway fee comes out of your net. This is the default. - The customer pays it β interest is added to each installment so you receive the full amount. 3. Choosing The customer pays it, set the monthly rate. Left blank, we use the gateway's own fee schedule β and the hint under the field shows what that comes to per month for the selected plan, before you decide to override it. 4. Save. Every new charge starts with that choice β and each charge can override it. Apply terms to a charge 1. Open New charge and pick the payment method. 2. In the Gateway options block, fill in the late fee, interest and early-payment discount. 3. On the fee and the discount, choose between Percentage and Fixed amount. The field label follows: Late fee (%) or Late fee (Fixed amount). 4. For a credit card, choose the number of installments. The Simulation block appears below. Read the simulation The block shows two columns: - The customer pays β for example 12x of R$ 83.08 (last one R$ 83.12) plus the total. The last installment carries the remainder; that is how the gateway divides the amount. - You receive β the net after the gateway fee, with the fee broken out underneath. When the gateway confirms the simulation, a Confirmed by the gateway badge appears. Settings & options | Term | Asaas | Mercado Pago | |---|---|---| | Late fee (% or fixed) | Yes | No | | Monthly interest | Yes | No | | Early-payment discount | Yes | No | | All three on a subscription | Yes | No | | Choosing who pays the installment interest | Yes | No β the business always absorbs it | | Maximum installments | 21 | 36 | | Showing the net before payment | Yes | No | Leaving a field blank is not the same as entering zero: blank inherits the default configured in the gateway's own panel; zero overrides that default to no fee at all. Use cases - Recurring service with frequent late payments: a 2% fee + 1% monthly interest on the subscription. Every charge the recurrence generates inherits the policy. - High-ticket product: 12x with the customer pays the interest, so you receive the full amount. - Incentive to pay early: a 5% discount up to 3 days before the due date. - A fee in money: R$ 10.00 flat instead of a percentage, across charges of very different sizes. Tips, limits & best practices - A fixed fee or discount can never exceed the charge itself. - A percentage never goes above 100. - If you choose The customer pays it with no monthly rate and no gateway fee schedule available, the charge is refused with a message asking for the rate β rather than silently billing your business instead. - Editing a pending charge sends the terms to the gateway too. Clearing every field removes the policy from the charge. - The simulation is an estimate until the confirmation badge appears. When the gateway does not report the net (Mercado Pago), the screen says so β we never show an estimated number there. Troubleshooting "The simulation could not be calculated right now." A momentary gateway hiccup. Use Try again; the charge can still be created. "This gateway does not report the net amount before payment." Expected on Mercado Pago. What the customer pays is still correct; the net is only known after settlement. "We could not read this account's fee schedule from the gateway right now." Reading the schedule failed β a rejected credential, an outage, or an unexpected response from the gateway. Use Read the fees again right there: nothing is stored when a read fails, so the button really does query the gateway. Saving the connection again also forces a fresh read. The fee and interest options do not appear. The connection is Mercado Pago, which does not offer those fields. The installments field does not appear. Installments exist only on credit-card, one-off charges. See also - Discounts and amount adjustments - Create a charge and send it in the conversation - Subscriptions and plans - Connect a gateway
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
Import gateway history safely
Overview History import brings gateway charges, customer mappings, and subscriptions into Conversa Labs. Charges create financial events, Orders, and reports; subscriptions appear in Payments > Subscriptions; and an imported customer only creates a technical mapping to a contact that already exists in the account. The process is governed: a preview does not write charges, mappings, or subscriptions; it persists only the audited run and the snapshot used to review the selection. A real import includes only records you select. The platform never creates contacts or organizations silently: a charge without an exact match remains blocked until you choose an existing contact or propose a new one, which is created only after final confirmation. When a charge and subscription carry the same gateway subscription identifier, they are linked to each other even if you import them in either order. Historical charges do not send customer messages, advertising conversions, commissions, or outbound webhooks. Prerequisites - You must be an account administrator. - The Asaas or Mercado Pago connection must be active and its credentials verified. - For Mercado Pago charges, choose a start date within the previous 12 months. The complete search for that resource follows this rolling window. - For Mercado Pago customers, enter the customer email. Its documented API does not provide an account-wide customer sweep. - Review the import watermark before allowing automatic adoption of unknown charges from webhooks. Step by step 1. Go to Settings > Payments > Connections and choose Import history on the required connection. You can also open the action from the empty state in Charges. 2. Under Resource to import, choose Charges, Customer mappings, or Subscriptions. Ingestion safeguards and automatic adoption apply only to charges. 3. For charges, set the watermark and keep automatic adoption disabled unless your operation has a clear rule for it. βOnly from the watermarkβ requires a valid watermark. 4. Enter the period and record limit. For a Mercado Pago customer, also enter the email. Choose Generate preview. 5. Review the detailed list. Each charge shows the customer data supplied by the gateway, the contact found, and the exact signal used for the association. Search by identifier, reference, or customer; combine filters; change sorting; and move through pages without losing selections made on other pages. 6. For a charge marked Customer pending, choose an existing contact or propose a new one with a name and at least one identifier (email, phone, or document). The proposal creates nothing during preview. Automatic matches use only exact gateway customer, email, normalized phone, or document signals; similar names are never enough. 7. Use Select importable records on this page, Select every importable record in these filters (when the preview spans more than one page), or select each row. Global selection spans every page in the current slice but reaches only importable records with a resolved customer: skipped, already-synced, or pending rows are never selected. Changing a filter intentionally clears selection; changing pages preserves it. The connection, run, filters, and sorting are stored in the URL, so back, forward, and a reopened link restore the same view only when the connection belongs to the current account. 8. Choose Import selected, review the exact count and customer resolutions in the confirmation, and confirm. An empty selection never means βimport everythingβ. Proposed contacts are created inside the confirmed import; if validation fails, the corresponding charge does not enter without a contact. 9. Follow the result and connection history. Failed records show their identifier and reason; success never includes a row that failed. Settings & options Watermark and automatic adoption The watermark limits historical ingestion. Automatic adoption of charges arriving through webhooks is disabled by default. If you enable adoption from the watermark, the platform fails safely when the watermark is missing or invalid. Preview list The preview is a safe snapshot of the same execution that would import the data, without writing charges, mappings, or subscriptions. The list uses server pagination and totals; its counter is not derived only from the visible page. On small screens, filters and sorting open in their own panel and every row becomes a readable card. Chips show active filters. Clear filters is available when a combination returns no results. If the requested limit is reached, the preview reports that it was truncated: generate another window instead of assuming all history was read. Ignored records In a preview, use the block icon next to a record to ignore it permanently and provide a reason. The decision is separated by charge, customer, or subscription even if the gateway reuses an identifier. Under Permanently ignored records, choose Allow again to undo the decision. Contact and organization links The platform first looks for exact matches by gateway customer, email, normalized phone, document, and CNPJ. For a charge without a contact, you must choose an account contact or propose a new contact before selecting it. Creation is delayed until confirmation, and a manual link is never silently replaced. An unmatched subscription stays visible for later reconciliation; an unmatched directory customer is skipped because there is no safe local owner for a mapping. Charges and subscriptions are connected only by the exact identifier supplied by the gateway, never by amount, date, or name. Use cases - Recover charges, Orders, and subscriptions after connecting a gateway that already had sales. - Import Asaas customer mappings before subscriptions to increase exact association by gateway identifier. - Rebuild internal reports without notifying customers about old transactions. - Permanently exclude a charge belonging to another operation or one that is not a sale. - Import a small period first, validate the preview, then continue in smaller windows. Tips, limits & best practices - Start with a short window and small record limit; expand only after reviewing the preview. - Each preview/import and each explicit selection accepts at most 5,000 records. - A confirmed import must use exactly the same resource type, window, limit, and email as its completed preview. Generate a new preview after changing any parameter; this applies to charges, customers, and subscriptions. - Selection is required. The platform never treats an empty selection as βimport everythingβ. - Selection survives pagination and Select all spans every page in the current filters, but it is cleared when search or filters change so an invisible row is never imported by mistake. - Charges without a resolved contact cannot be selected. Resolve each one manually; the API also blocks attempts to bypass the preview. - The durable ignore list is loaded completely through internal pages; more than 100 exclusions never disappear silently. - Customers do not use date filters and can only map an existing contact. Mercado Pago customer search is always email-targeted. - Totals are shown per currency; do not add different currencies as one amount. - Reversal removes only local records created by that execution. It never changes the gateway. - To reverse, open an eligible execution in history, type undo, and confirm. If a later charge, customer mapping, subscription, Order, or event movement changed the data, the full reversal is refused to preserve the audit trail. Reversal removes only records and links created by the run; contacts and organizations are preserved, including a manually proposed and confirmed contact. - Older runs made before the reversal ledger may not be eligible. Keep their history and use the normal financial operation for corrections. Troubleshooting Mercado Pago requires a start date Enter a date within Mercado Pago's supported history window. An older date could create an incomplete view and is refused by the platform. I cannot import without selecting records This is expected. Generate a preview, select the intended records, and run the selected import. A charge cannot be selected because its customer is pending Open customer resolution on that row. Choose an existing contact or propose a new one with a name and an email, phone, or document. Save the decision, select the charge, and confirm the import. A proposed contact does not exist until that confirmation. Mercado Pago requires the customer email This is expected. Mercado Pago's documented customer search requires email and does not allow a general address-book import. Enter the email for the existing customer you want to map, or import subscriptions, which try to associate the payer data supplied by the gateway. A charge is shown as ignored Open Permanently ignored charges on the same screen, review the reason, and choose Allow again if it may be considered again. Reversal was refused A later movement occurred, or the record was not created by the chosen execution. No data was removed. Review the history row and charge events, then use the appropriate normal financial operation. See also - Connect a payment gateway - Manage charges - 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
Configure the payment messages
Overview Payments send the customer two messages: the charge and the payment confirmation. Here you customize each one's body per language, with no AI involved. Anything left untouched keeps the shipped Conversa Labs message. Beyond the body, you also edit the charge's auxiliary labels (captions, button texts, the amount and due-date lines and the copy-the-code instructions) and configure, per message type and per language, the approved WhatsApp template used when the 24h window is closed. Prerequisites - Payments enabled on the account and administrator permission. - To configure sending outside the window: a WhatsApp Cloud inbox with templates approved by Meta. Step by step 1. Open Settings β Payments β Messages. 2. Pick the language in the selector at the top. It opens on the account language and lists every language the installation enables (up to 40), showing how many already carry your copy ("N of M languages with content"). 3. Write the charge and confirmation bodies in Markdown. Empty = the language's shipped message (Default badge). 4. Use variables ({x}) to insert contact, account and charge data. The picker offers only the variables that actually resolve in that message. 5. Open the Auxiliary labels block to adjust the charge's 12 labels. 6. The Outside the 24h window (WhatsApp Cloud) block shows up open, right under each message type. Pick the approved template for that type in that language, map the {{1}}, {{2}}β¦ parameters and fill in the link button, if there is one. If no template exists yet, use Create from my text to generate one from the body you wrote. 7. Check the preview per channel, use Send test to validate it on a real conversation, and click Save messages β including after creating a template, because creating the template does not store the configuration. Restore default removes the customization on the server, not only on screen. Settings & options Languages and fallback Language is a selector with every language the installation enables. At send time, Conversa Labs looks for the copy in this order: the contact's language β the same base language (pt_BR β pt) β the account language β the shipped default message. Auxiliary labels There are 12 labels: captions, button texts, the amount and due-date lines and the copy-the-code instructions. They sit in a collapsible block and follow the same language and restore rules as the body. Outside the 24h window (WhatsApp Cloud) The block appears open and inline right under each message type β it is not a section you have to expand. The template is per message type and per language β charge and confirmation each have their own, instead of a single template for the whole module. It gives you: - Pick the approved template from the catalog. - Sync from Meta and Create from my text are always visible. When the action is unavailable, the button appears disabled with the reason written next to it: the inbox is not WhatsApp Cloud, the account does not have the WhatsApp Inbox Suite, or your profile does not manage inboxes. - Sync from Meta refreshes the list of approved templates. - Create from my text generates the template from that type's text in that language, submitting it to Meta as a UTILITY template, converting each {{ variable }} into {{1}}, {{2}}β¦ and pre-mapping them. With no text to generate from, the button is disabled and the screen asks you to write the text first. - After submission the template is not approved yet: it appears in the selector marked awaiting approval and only starts delivering once Meta approves it and you sync. Submitting again with the same name replaces the pending draft instead of failing. - Creating the template does not save the configuration β click Save messages to store the mapping. - The {{n}} parameter mapping and the link-button field. - Delivery: picks which WhatsApp inbox's approved-template catalog is browsed. The send still leaves through the conversation's own inbox. Templates whose header requires media or a variable are not listed here β this send has no way to fill that header β and the screen states how many were left out. They remain usable from the inbox's own Templates tab, linked directly from this screen. Notes: WhatsApp Web (WazMeow) has no 24h window (the block does not even appear); 360dialog can select a template but cannot create one; Meta matches name + language + approved, so a template in the wrong language is flagged on screen and would be rejected on send. Preview and test send The preview is rendered server-side, per channel, and shows only the channels the account actually has. It also displays the resolved out-of-window template, with the values each parameter will carry. Send test delivers the message to a chosen conversation honouring the 24h window: with the window closed and no template configured, the test is skipped with the reason stated on screen. Payment variables Beyond contact, account, conversation, inbox, agent, CRM and organization β which now really render β these messages offer the charge's own data: | Variable | Replaced with | |---|---| | {{ payment.amount }} | Charge amount | | {{ payment.currency }} | Currency | | {{ payment.description }} | Charge description | | {{ payment.status }} | Current status | | {{ payment.due_date }} | Due date | | {{ payment.billing_type }} | Billing type (PIX, boleto, cardβ¦) | | {{ payment.pay_url }} | Payment link | | {{ payment.pix_payload }} | PIX copy-and-paste code | | {{ payment.boleto_url }} | Boleto link | | {{ payment.boleto_line }} | Boleto barcode line | | {{ payment.gateway }} | Gateway used | Tips, limits & best practices - Markdown per channel: attachments drop on LINE/TikTok/X; raw HTML disappears in email/widget; *bold* on WhatsApp shows as a pair of asterisks. - Configure the out-of-window template in the same language as the body β they are pairs, not a single global setting. - Always offer a way to pay in the copy: {{ payment.pay_url }}, {{ payment.pix_payload }} or {{ payment.boleto_line }}, depending on the billing type. - After "Create from my text", the template sits awaiting approval at Meta β use Sync from Meta to see when it is approved and starts delivering. Troubleshooting - It went out as the default: the type was empty (Default badge) in that language, or the contact's language has no copy and the fallback reached the shipped default. - Nothing sent outside the window: confirm the approved template for that type in that language. - The template shows as flagged: it is in a different language from the message β swap it for an approved one in the right language. - "Create from my text" is disabled: the reason is written next to the button β the inbox is not WhatsApp Cloud (on 360dialog you pick an already-approved template), the account does not have the WhatsApp Inbox Suite, your profile does not manage inboxes, or there is no text in that type and language to generate the template from. - I created the template but it doesn't show up / isn't used: right after submission it sits awaiting approval β it only delivers once Meta approves it and you use Sync from Meta. Also confirm you clicked Save messages: creating the template does not store the configuration. - I can't find a template in the list: templates with a media header or a header variable are not listed here; use them from the inbox's own Templates tab. - The test send was skipped: the conversation was outside the 24h window and the message had no template configured β the screen states the reason. See also - Connect payment gateways (Asaas / Mercado Pago) - WhatsApp Inbox Suite: Templates, Flows and Calls
Manage and reconcile charges
Overview The Charges area is where you track and manage everything that has been billed. It has a searchable, paginated list (search, created period, status, gateway/connection, sorting and a toggle to show archived charges), per-row actions on each charge (view, edit, fix customer and links, send to conversation, refund, mark as paid, cancel, archive, restore, delete) and a floating bulk-action bar that appears when you select several charges at once. The goal is reconciliation: keeping every charge's status consistent with reality β reflecting what the gateway confirmed as well as the payments you received outside the platform. Prerequisites - The Payments module enabled and at least one connected gateway (see Connect a gateway). - Charges already created (see Create a charge and send it in the conversation). - To delete permanently and to use the financial bulk actions, you need admin permission. Step by step 1. Filter and open a charge 1. Open Payments β Charges. 2. Search by description, gateway id/external reference, customer name/email or connection name. Combine it with status, connection, and the created period in the account timezone. 3. Sort by created date, due date, amount, status or description; turn on archived to see the bin. Every active control appears as a removable chip, and the URL preserves the page, filters and sorting so you can return to or share the same view. 4. Click a charge to open its details. The primary action follows the available artifact: hosted page, boleto or PIX copy-and-paste; a manual charge remains auditable even when it has no link. 5. Use Export CSV to download the full filtered scope, not only the visible page. When charges are selected, the file contains only that selection. On small screens, dense controls move into the Filters panel and each charge becomes a readable card instead of a horizontal table. 2. View the status timeline (audit) 1. In the charge details, open the timeline tab. 2. Every event (created, paid, refunded, canceled, updated) is recorded immutably, with the responsible agent, the timestamp and the justification entered β it is the charge's auditable financial history. 3. Fix customer and links without editing financial facts 1. From the row or details, use Fix the sale customer and links when the contact is missing or wrong, including on a paid charge whose financial fields can no longer be edited. 2. Choose an existing contact or propose a new one with a name and at least an email, phone, or document. Also review the order, recovery event, organization, deal, and conversation reached by the same sale. 3. Generate the preview and check conflicts, history, and any owner/affiliate impact. Credit or commission changes require explicit confirmation. Apply is transactional and audited. 4. This action never changes amount, status, settlement, due date, or gateway ID. Use the corresponding financial operation or correct the source for those facts. 4. Mark as paid manually (and undo) 1. For a payment received off-gateway (cash, direct PIX to the account), use Mark as paid. 2. Enter the justification (required) β it is stored on the audit event. 3. The charge becomes paid. Available only for charges that are still open (pending, awaiting payment or overdue) and on gateways that support manual settlement. 4. To reverse it, use Undo manual settlement β it only works on a charge you settled manually; it goes back to pending/overdue. 5. Cancel (open) vs refund (paid) 1. Use Cancel charge while the charge is still open (unpaid): the customer can no longer pay it. 2. Use Refund once the charge is paid: choose full (returns everything) or partial (enter the amount). You can refund partially more than once, up to the full amount. 3. In both cases you can record a reason, which is kept in the audit trail. 6. Resend in the conversation 1. Use Send to conversation and pick the target conversation. 2. The payment card reappears for the customer inside the conversation window. 7. Archive β restore β delete permanently 1. Archive removes the charge from the default list without deleting it (it goes to the archived bin). 2. Restore brings an archived charge back to the active list. 3. Delete permanently removes it for good β only allowed for charges that are archived and not settled; paid/refunded charges are kept for audit and can never be deleted. 8. Bulk actions 1. Select several charges; the floating bar appears with the count. 2. In the active list (admin): mark as paid, cancel and refund (full only), plus archive. 3. In the archived list: restore and delete permanently (admin). 4. Every bulk action is best-effort: the result says how many were processed and lists the ids that failed. Only failures remain selected for review or retry; no requested item silently disappears from the result. Settings & options - Per-row vs bulk action: the same operation exists individually on each charge and in bulk over the selection. - Permissions: delete permanently and the financial bulk actions (mark as paid, refund, cancel) and the bulk delete are restricted to admins. - Bulk refund = full only: a partial refund exists only as a per-row action. - Delete requires archiving first: a permanent delete is always a deliberate two-step (archive, then delete). - Export: honors search, date window, filters and the current selection; text cells are protected from being interpreted as formulas by spreadsheet software. - Edit vs fix links: editing remains subject to charge status and gateway rules. Fixing links is a separate association-only operation, including for settled charges. Use cases - Reconcile a PIX paid off-platform: mark the charge as paid with the justification, keeping the history consistent. - Clean up test charges: bulk-archive them, then permanently delete the archived ones. - Refund in bulk: select the paid charges and refund them in bulk (full). Tips, limits & best practices - Cancel only applies to open charges; for a paid charge, the path is a refund. - A refund depends on the gateway β the type (full/partial) and the time to return the money follow the provider's and payment method's rules. - The webhook remains the source of truth: manual settlement is for what was paid off-gateway; the gateway's own payments arrive and update the status on their own. - Undo manual settlement only works on what you settled manually β it is not the way to reverse a real gateway payment (use a refund for that). - When the amount is correct but the customer, order, or recovery event is wrong, use Fix customer and links; do not cancel or refund merely to repair an association. Troubleshooting - "I can't delete it": the charge must be archived first; and paid/refunded charges are never deleted (kept for audit). Archive it instead of trying to delete. - "Undo unavailable": a manual settlement can only be undone the same way β only a charge you marked as paid manually (on a compatible gateway) can be reverted. - "Mark as paid unavailable": the charge is not open, or the gateway does not support manual settlement. - "Edit is unavailable on a paid charge": settled financial facts are immutable. To change only the customer, organization, deal, or conversation, use Fix the sale customer and links. - A bulk action skipped some charges: that is expected β ineligible ones (incompatible status or a gateway without the capability), missing ids and items outside the permitted view appear as not processed and remain selected for review. - The list did not load: use Try again; if it keeps failing, check connectivity to the server. See also - Payments overview - Create a charge and send it in the conversation - Refunds, webhooks and reports - Connect a gateway: Asaas and Mercado Pago
Offers: order bump, upsell and downsell
Overview An offer is a reusable price you register once and reuse across many sales. There are three kinds: - Order bump: shown at checkout as a quick add-on and, when accepted, enters as an extra line item on the charge being created. - Upsell: a one-click post-purchase offer, usually a higher-value item, that creates a new charge for the contact. - Downsell: also one-click post-purchase, used as a cheaper alternative when the customer declines the upsell β it likewise creates a new charge. In every case the offer holds a name, amount, currency and method; you only attach it to a sale or a contact at the right moment. Prerequisites - A connected and valid gateway (see Connect a gateway). - Optional: a Catalog product linked to the offer (catalog_product_id), to reuse the product record. - Set the connection (gateway) and the method (billing_type) on the offer, used when it becomes a charge β especially for upsell and downsell. - To accept an offer (upsell/downsell), the contact needs minimal data (name and, ideally, email/phone) for the payer at the gateway. How it works - Order bump at checkout: the offer is converted into a charge line item (name, amount and currency are snapshotted at that moment). It adds to the total by appending a new line β it never changes the amount of an existing charge. The line only keeps a reference to the offer in its metadata. - Upsell / downsell after purchase: when you accept the offer for a contact, the platform creates a new charge reusing the connection, the amount and the payer data already known β with nothing to retype. That charge follows the normal flow (gateway β webhook β payment card in the conversation), exactly like any other charge. - The offer is never modified when accepted: it is a template; each acceptance creates a new, independent charge. - Post-purchase acceptance only works for an active, non-archived offer. An order bump belongs to checkout and is rejected by this action. Repeating the same network attempt recovers the same charge. Settings & options Offer fields: | Field | Purpose | |---|---| | Name | Identifies the offer and becomes the charge/line description. Required. | | Kind (kind) | order_bump, upsell or downsell. | | Amount | Offer price (major units, e.g. 49.90). Must be greater than zero. | | Currency | 3-letter code (e.g. BRL). | | Method (billing_type) | PIX, boleto or card used when the offer becomes a charge. | | Connection | The gateway (payment connection) used to charge. | | Catalog product | Optional link to a Catalog product. | | Description | Supporting text for the offer. | | Active / inactive | Inactive offers are not presented. | Step by step 1. In the Payments area, open Offers and create a new offer. 2. Enter a name, pick the kind (order bump, upsell or downsell), the amount and the currency. 3. Set the method and the connection (gateway) used when generating the charge. 4. (Optional) Link a catalog product and write a description. 5. Save. The offer is available while it is active. 6. To apply an order bump, use the offer at checkout: once the customer accepts it, it becomes an extra line on the charge. 7. To accept an upsell/downsell, trigger the offer acceptance for the contact (optionally tied to a conversation): the platform generates a new charge and sends it in the conversation. 8. To retire an offer, archive it β it disappears from the available offers, but the price is preserved (we never delete a price an active funnel may reference). Use cases - Raise the ticket with an order bump at checkout ("add the extended warranty for $19.90"). - Offer an upsell right after purchase ("get the Pro version in one click"). - Recover the sale with a downsell when the customer declines the pricier upsell. - Reuse the same offer across many conversations and checkouts, without re-creating the price. Tips, limits & best practices - The order bump does not change an already-created charge β it only adds a line to the total at checkout time. - Accepting an upsell/downsell always creates a new and independent charge; the original offer stays intact. - Offers are archived, not deleted β so no funnel or history that depends on that price breaks. - Set the connection and method on the upsell/downsell offer: without them, the acceptance cannot generate the charge correctly. - Amounts are in major units ($49.90 = 49.90); the checkout total is the sum of the lines β never divide by 100. Troubleshooting - The offer does not appear: check that it is active and not archived (inactive or archived offers are not presented). - Acceptance failed: confirm the contact has the minimal data and that the offer's connection (gateway) is valid β acceptance creates a real charge and needs that data. - The order bump amount looks wrong: remember it adds a line to the total; it does not replace or reduce the other lines. - I can't delete an offer: offers are archived (reversible), not removed β use archive. See also - Create a charge and send it in the conversation - Connect a gateway: Asaas and Mercado Pago - Native catalog of products and services