## 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

### Bill a company

1. Choose the **responsible contact**. In a conversation, this contact remains the customer-service context.
2. Under **Payer**, choose **Company** and select a company linked to that contact. This is an explicit choice: a CRM relationship or catalog product does not determine the payer by itself.
3. Review the company record: legal name and tax document, plus the email, phone and address required by the gateway and payment method. Fiscal payer data comes from the chosen company; personal contact data does not replace that record.
4. If the list is loading or fails, wait or use **Retry**. A loading failure is not treated as the absence of companies. Do not bill an incomplete company as a contact to bypass the error.

Creation in a conversation still requires the responsible contact. An imported or recorded subscription without a contact is not a complete conversation workflow. With Asaas, do not assume that editing the company on the platform automatically synchronizes every field of an existing gateway customer: also check legal name, email and address at the gateway.

### Charge plans and payment books

A charge plan groups the installments of one sale. The contracted total and the amount received are different: paying one installment does not settle the whole plan. Each installment keeps its own due date, payment and history.


- **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. With Asaas, omitting the date defaults to the current day in the account's time zone. The valid date confirmed by the gateway is stored on the charge; check it before sending it to the payer.
- **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. A blank field sends no explicit override. Check connection defaults and the provider dashboard; confirm the provider result before promising a fee waiver.
- **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**: when the payer is **Person/Contact**, 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.

### Native WhatsApp order (WhatsApp Pay)

When the gateway connection has native WhatsApp payment turned on, the charge reaches the customer through the
official API as a WhatsApp **order** they pay without leaving the app. That order follows the charge:

- when the payment is confirmed, the platform updates the order on the customer's WhatsApp, which then shows the
  **paid** label;
- when the charge is canceled before payment, the order becomes **canceled** and stops offering payment.

The update is only sent while the 24-hour customer service window is open, because WhatsApp does not accept this
kind of message outside it. Outside the window, the charge card in the conversation still shows the right status.

The customer gets **one** payment notice, never two: when the order is updated to paid, that update replaces the
payment confirmation message. The confirmation message goes out instead when the order cannot be updated (a charge
with no WhatsApp order, a conversation over WhatsApp Web or a closed window) and also when WhatsApp refuses the order
update. If the outcome of the send is uncertain (WhatsApp did not confirm whether the update arrived), the platform
does not send the confirmation message, so the customer never gets the notice twice.

Outside the 24-hour window, when the template set up for sending charges is an **order details** template, the
platform fills the template's order with the same items, amounts and payment methods.

## 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*.
- **Change the payment method of a pending charge**: use **Edit** in the charges list and pick the
  new method under **Payment method**. On Asaas, the Pix, boleto or card link is updated and the old
  code is no longer sent. On Mercado Pago, cancel and create it again.
- **The charge was created but did not reach the conversation**: the platform tells you when only the
  send failed. Do not create another charge; resend the existing one from the list.

## See also

- [Payments overview](/hc/ajuda/articles/payments-overview-en)
- [Connect a gateway: Asaas and Mercado Pago](/hc/ajuda/articles/payments-conectar-gateway-en)
- [Discounts and value adjustment](/hc/ajuda/articles/payments-descontos-en)
- [Subscriptions and recurring plans](/hc/ajuda/articles/payments-assinaturas-planos-en)
- [Refunds, webhooks and reports](/hc/ajuda/articles/payments-reembolsos-webhooks-relatorios-en)

- [Charge plans and payment books](/hc/ajuda/articles/payments-planos-de-cobranca-en)