## Overview

The **Orders Registry** is a contact-centric **purchase history**. For each contact (and, optionally, for
each deal) you record orders with a **title, value, currency, status and date**, building a clear view of
everything that person has bought.

It's important to understand what it **is** and what it **is not**: the orders registry is a **log**, not a
payment gateway. It **does not charge, refund or reconcile money** — billing is handled by the **Payments**
module. Marking an order as "refunded" or "canceled" here is just a history note, not a financial operation.

Orders can arrive from several origins: entered **manually**, received via **webhook**, created through the
**API**, originated from the **Payments** module, or from **commerce** integrations.

## Prerequisites

- The **Orders Registry** is optional and **off by default**. Ask an administrator to enable it for the
  account.
- **CRM management** permission to create and edit orders.
- Contacts in place — every order belongs to a contact.

## Step by step

1. Confirm with an administrator that the **Orders Registry** is enabled.
2. Open a **contact** (or a **deal**) and find the **Orders** section.
3. Create an order with a **title**, **value**, **currency** and **status**.
4. Optionally, set the **order date** and **paid date**, and link the order to a **deal**.
5. Update the **status** as the order evolves (paid, partially paid, overdue, refunded, etc.).

## Settings & options

- **Order status**: pending, paid, partially paid, overdue, refunded, canceled and failed.
- **Source**: manual, webhook, API, Payments or commerce — identifies where the record came from.
- **Links**: every order belongs to a **contact** and can be linked to a CRM **deal**.
- **Currency and value**: each order has its own value and currency (default BRL).
- **External identifier**: orders from integrations carry an **external ID** that prevents duplicates.
- **Owner-based wallet**: when owner-based privacy is active, each rep sees only the orders of the
  contacts/deals they can access.

## Use cases

- Keep each customer's **purchase history** right on the contact profile.
- Track, on the deal, the orders already placed for that opportunity.
- Consolidate orders from multiple origins (manual, Payments, commerce) into a single log.
- Feed automation and reports based on what each contact has bought.

## Tips, limits & best practices

- Use the orders registry for **history**; to actually **charge**, use the Payments module.
- Standardize **titles** and **statuses** to make reading and filtering easier.
- When integrating via webhook/API, send a stable **external ID** so orders aren't duplicated.
- Link the order to the matching **deal** when it makes sense, to connect sale and opportunity.

## Troubleshooting

- **I don't see the Orders section**: the module may be disabled for the account — talk to an administrator.
- **Duplicate order**: check that the integration is sending the same **external ID** instead of creating a
  new one.
- **The order didn't charge the customer**: that's expected — the registry is a log; charging is done in
  Payments.
- **I can't create an order**: check your CRM management permission and that the contact exists.

## See also

- [CRM: pipelines, kanban and deals](/hc/ajuda/articles/contacts-crm-crm-pipelines-kanban-negocios-en)
- [Deals: notes, attachments, checklists, line items and automatic value](/hc/ajuda/articles/contacts-crm-crm-notas-anexos-checklists-line-items-valor-en)
- [Contacts and CRM overview](/hc/ajuda/articles/contacts-crm-overview-en)
- [Custom Objects](/hc/ajuda/articles/contacts-crm-custom-objects-en)