# The student paid and has no access

> An ordered checklist for a buyer who cannot get in: the sale arrived, it has an error, the delivery matches, the enrollment exists, the email matches.

"I paid and I cannot get in" is the most common support request. This checklist finds the cause in six steps. It is not for a student who sees the course and cannot open a lesson; that case starts at step 6.

## The idea in one minute

Think of the purchase as a parcel.

- The **sale** is the parcel. The gateway tells Cademí it was shipped.
- The **delivery** is what goes inside the box: the products the student receives.
- The **enrollment** is the parcel received. It gives the student what the delivery says.
- The **student record** is the address. The student is identified by email: a second email is a second address.

When the student says nothing arrived, check each stage in this order. Stop at the first one that fails. A later stage never explains a problem you have already found.

**The most important rule:** always search by the **email used in the purchase**, as it is on the gateway. Do not use the email the student wrote from. If you have it, also note the sale ID on the gateway.

## The checklist

The whole checklist, in order. Each step is detailed below.

```mermaid
flowchart TD
    accTitle: Checklist for the student who paid and has no access
    accDescr: First, look for the sale in Sales by the purchase email. With no sale, check the postback on the gateway or wait for the payment approval. With the sale With error, fix it and reprocess. Once processed, check that the delivery has content; with no content, turn on the products. With content, look for the enrollment in the student's Purchases tab; with no enrollment, look for a second student record with the sale's email. With the enrollment active, the block is in another layer.
    venda{"Is the sale in Sales?"}
    postback["Check the postback on the gateway<br/>or wait for the approval"]
    status{"Sale status"}
    corrigir["Fix and reprocess"]
    conteudo{"Does the delivery have content?"}
    ligar["Turn on the products in the delivery"]
    matricula{"Active enrollment in Purchases?"}
    cadastro["Look for another student record<br/>with the sale's email"]
    camada["Block in another layer"]
    venda -->|No| postback
    venda -->|Yes| status
    status -->|With error| corrigir
    status -->|Processed| conteudo
    conteudo -->|No| ligar
    conteudo -->|Yes| matricula
    matricula -->|No| cadastro
    matricula -->|Yes| camada
    classDef destaque stroke:#ff005c,stroke-width:2px
    class corrigir destaque
```

### 1. Did the sale reach Cademí?

1. Open **Sales > Sales**.
2. In the search, pick **Email** and type the purchase email. If you have the sale ID, pick **Sale ID** and paste the ID.

What you can find:

- **A row with Sale status Approved.** The sale arrived. Go to step 2.
- **Nothing.** There are two possible causes:
  - In a one-time sale paid by boleto or Pix, the payment may not be confirmed yet. The sale only shows up when the approval arrives.
  - If the gateway already shows the purchase as approved, the gateway did not notify Cademí. On the gateway, check that the delivery's **Postback URL** is in the webhook settings. Also check that the purchase events are selected. Each gateway's step by step is in [Payment gateways](https://help.cademi.cloud/en/vendas/gateways.md). While nothing arrives, the delivery shows **No sale received yet** in **Sales > Deliveries**.
- **In a subscription, only Awaiting payment.** The gateway has not confirmed the payment yet. Boleto and Pix stay like this until they clear. The approval arrives in a new communication. There is nothing to do in Cademí.
- **Refund, Cancelled or Overdue after the approval.** The gateway suspended the access on purpose. In a cancelled subscription with **Subscription ends on**, the student keeps access until that date (see [Sales received](https://help.cademi.cloud/en/vendas/vendas-recebidas.md)). If the student settles the payment, the next approval reactivates the same enrollment.

**Heads up:** a sale made before the postback existed does not arrive on its own later. Ask the gateway to resend the notification, or grant the access by hand (step 5).

### 2. Did the sale arrive with an error?

On the same row, look at the **Status** column.

- **With error.** Cademí received the sale but could not turn it into access. Open the details. The reason is highlighted in the **Data** tab. The reasons and what to do about each are in [Sales received](https://help.cademi.cloud/en/vendas/vendas-recebidas.md). After fixing, click **Reprocess** on the sale itself.
- **Queued.** Cademí is about to apply the sale. Wait a moment and reload the page.
- **Processed.** Cademí applied what the sale asked for. Go to step 3.

### 3. Does the delivery have this identifier?

In the sale details, on the **Data** tab, look at two fields:

- **Offer** is the delivery the sale found.
- **Product ID in the gateway** is the identifier that came with the sale.

What you can find:

- **Offer shows a delivery.** Open that delivery in **Sales > Deliveries** and look at the **Delivered content** section. If it says **No content selected yet.**, the sale was processed, but the delivery grants no product. In the list of deliveries, it shows **No access configured**. Turn on the products or the showcase the student should receive. You do not need to reprocess: the delivery is live, and the student sees the content right away.
- **The right delivery is another one.** The sale's identifier is in a delivery that grants something else. Compare the **Product ID in the gateway** with the **Product ID** of each delivery, character by character. The gateway often sends the offer code while the delivery only has the product code, or the other way around. Fix the delivery and reprocess the sale.
- **A cart.** Each item has its own **Offer:**. If an item shows **No delivery**, the whole sale fails and ends up **With error** (step 2).

### 4. Was the enrollment created?

1. Open **Students**.
2. Find the student by the purchase email.
3. Open the **Purchases** tab.

Each row is an enrollment. The row shows:

- the delivery;
- the date, in **Purchased on**;
- the **Identification**: **Sale ID** or **ID - SUBSCRIPTION**, linking to the sale;
- the **Status**.

What you can find:

- **The delivery is there, with Status Active.** The enrollment exists. Go to step 6.
- **The delivery is there, with Status Inactive.** A refund, a cancellation or a late payment suspended the enrollment. Or someone deactivated it on this screen. If the gateway controls the sale, the next approval reactivates the enrollment. If it was a mistake, click the status to activate it.
- **The delivery shows Valid until.** The enrollment has an end date. The date comes from two places:
  - from **Schedule access end**, in the row menu;
  - from a subscription cancellation, when the gateway sends the end date. In that case, the row shows **Inactive** and the student keeps access until the date.

  If the date has passed, access ended on it. In a subscription, renewing on the gateway reactivates the same enrollment.
- **The delivery shows the Cancelled badge.** It is a subscription cancelled on the gateway, with an end date. Later, someone activated the enrollment again on this screen (with a click on **Inactive**, for example). Activating does not clear the date the gateway sent:
  - access lasts only until **Valid until**, and the status no longer changes with a click;
  - if the date has passed, the student still has no access, even with the enrollment active;
  - to give more time, use **Schedule access end**, in the row menu, with the new date. **Remove end date** is not enough, because the gateway's date applies again;
  - the next approval of the subscription on the gateway clears the date and the badge.
- **The delivery is not there.** The sale did not become an enrollment in this student record. The student may be in another record. Go to step 5.

### 5. Did the student sign in with another email?

**Heads up: this is where most mistakes happen.** Bia buys the course with `bia.work@example.com`. Then she signs in to the student area with `bia.home@example.com`. The sale is **Processed**, but the record for `bia.home@example.com` does not have the purchase. The purchase is in the other record, the one with the sale's email.

1. Open **Students**.
2. Search for the email that is on the sale.

There is almost certainly a second student record, with the purchase inside. Cademí does not merge two student records. Choose one way out:

- **Tell the student to sign in with the purchase email.** If they forgot the password, use **Change password** or resend the access from their profile.
- **Give the delivery to the record they use.** In the student's profile, click **Add delivery** and pick the purchase's delivery. That enrollment is manual and stays under the account's control. A refund of the original sale does not suspend this enrollment.

The document can also send the sale to another record. If the account checks documents, a purchase with a new email and an already registered CPF goes to the oldest student with that document. The student may be looking for the access in the wrong record.

### 6. The access exists and the product is still locked?

If the enrollment is active and within its period, the problem is no longer the sale. Open the student's **Products** tab. Each product shows:

- **Released until**: the date, or **Lifetime**;
- **Release**: **Scheduled**, when the release rules apply, or **Immediate**.

The possible causes, from here on:

- the product or the showcase is a draft (students do not see drafts, even with an enrollment);
- a release rule has not opened the module or lesson yet (a future date, days after purchase, an exam, progress);
- the account requires lessons in sequence, and the student has not completed the previous one;
- the student cannot sign in. That is a different problem, even with access in good standing.

The diagnosis of these layers, in order, is in [Why the student cannot access](https://help.cademi.cloud/en/alunos/por-que-o-aluno-nao-acessa.md).

## Good to know

- **Reprocessing does not duplicate.** Reprocessing a sale finds the enrollment of that sale. It does not create another one and does not add a second period. Reprocess freely after fixing the delivery.
- **Do not create a manual enrollment on top of a sale that failed.** Fix the delivery and reprocess. That way the enrollment stays linked to the sale, and the gateway takes care of it (refund, renewal). A parallel manual enrollment hides the delivery problem and does not follow the gateway.
- **The account's student limit.** The limit blocks the creation of a new buyer. The sale ends up **With error**, and no student record appears. Someone who is already registered is not blocked.
- **A refund does not remove tags.** A refunded buyer keeps the tags from the purchase. If a segment depends on them, remove the tags by hand.

## Frequently asked questions

**The gateway says it sent the notification, but there is nothing in Sales > Sales.** Check the **Postback URL** pasted into the gateway and the selected events. The URL is specific to your account. Then make a test purchase with an email that does not belong to an administrator. See whether the delivery starts showing **Last sale received**.

**I granted the access by hand to solve it right away. Do I need to do anything else?** Yes. Fix the delivery and reprocess the sale anyway. That way, the next purchase of the same offer does not fail. The reprocessed sale takes over the manual enrollment, and the access start becomes the purchase date.

**The student bought a bundle and only received some of the courses.** In the sale details, look at the **Items**. Each item finds its own delivery. The item with no delivery (or with the wrong one) is the missing piece. Fix it and reprocess.

**The student says they paid, but the sale shows as Refund.** The gateway reported a refund, and the access was suspended on purpose. If the student settles the payment on the gateway, the next approval reactivates the same enrollment.