> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pocketsflow.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Orders & customers

> Use Orders, Subscriptions, and Customers to support buyers, track recurring revenue, and reconcile every payment on Pocketsflow.

The **Orders** and **Customers** areas of your dashboard are your day-to-day
control center for support, reconciliation, and growth. Pocketsflow records a
transaction for **every** successful payment — whether it's a one-time product
purchase or a subscription charge — so nothing slips through the cracks.

## One-time orders vs subscriptions

Pocketsflow tracks two kinds of paid transactions, and it's worth
understanding the difference because they surface in different places:

<CardGroup cols={2}>
  <Card title="One-time orders" icon="bag-shopping">
    A buyer pays once for a product (course, download, bundle, upsell). It
    produces a single order and, if configured, may include an **upsell**.
  </Card>

  <Card title="Subscriptions" icon="repeat">
    A buyer starts a recurring plan. This creates a **subscriber** record plus a
    **payment every billing cycle** — the first (initial) charge and one for
    each renewal after it.
  </Card>
</CardGroup>

Both are recorded as transactions, but a subscription's transactions are labeled
as recurring (each carries a **billing reason** of `initial` or `renewal`) and
point at the subscription plan instead of a one-time product.

## The Orders page and its two tabs

The Orders page is split into two tabs so recurring revenue never gets mixed in
with one-off sales:

### 1. Orders tab (one-time)

Lists your **one-time product** transactions only — subscription charges are
deliberately kept out of this list (they have their own ledger). For each order
you'll typically see:

* **Order reference** and **date**.
* **Buyer** (email / name).
* **Product** purchased, plus any **upsell** attached to the order.
* **Gross** amount and **currency**.
* **Net** amount (after tax, fees, and any affiliate cut).
* **Tax** collected and the buyer's **country**.
* **Status** — completed, **refunded**, or **disputed**.

The list is paginated (20 per page by default) and sorted newest-first. Use it
to confirm a payment went through, issue [refunds](/payments/refunds-and-disputes),
and see which products sell best over a chosen period.

### 2. Subscriptions tab

Lists your **subscribers** — one row per active or historical membership rather
than one row per payment. For each subscriber you'll see the plan, the buyer,
the current **status**, and the billing details. This is the roster of *who is
subscribed*; the individual recurring charges live in the subscription's payment
history (below) and in the subscription-transactions ledger.

<Note>
  There is also a **subscription-transactions** ledger — the per-payment view of
  every subscription charge (initial + renewals) across all subscribers,
  mirroring the one-time Orders tab. Use the subscriber roster to answer "who is
  subscribed?" and the transactions ledger to answer "which charges happened?".
</Note>

## Subscription status

Every subscriber carries a live **status**, kept in sync by the payment
provider's webhooks. The ones you'll see most often:

| Status     | What it means                                                                                           |
| ---------- | ------------------------------------------------------------------------------------------------------- |
| `active`   | The subscription is live and billing normally.                                                          |
| `trialing` | In a free-trial period before the first real charge.                                                    |
| `past_due` | A renewal payment **failed** — billing is retrying. The member keeps access while the provider retries. |
| `paused`   | Billing is temporarily paused.                                                                          |
| `canceled` | The membership was canceled (by you, the buyer, or after failed retries) and will not renew.            |
| `refunded` | The subscription was refunded and canceled.                                                             |

<AccordionGroup>
  <Accordion title="How a subscription becomes past_due">
    When a renewal charge fails, the provider fires a payment-failed event and
    the subscriber flips to `past_due`. Billing keeps retrying; if it recovers,
    the status returns to `active`, otherwise it ends up `canceled`.
  </Accordion>

  <Accordion title="How a subscription becomes canceled">
    Either you cancel it, the buyer cancels from their billing portal, or the
    membership is deactivated (e.g. after exhausted retries). A cancel-at-period-
    end request keeps the member active until the end of the paid period.
  </Accordion>

  <Accordion title="Active subscriptions in analytics">
    Only `active` and `trialing` subscribers count toward active-subscription
    and MRR figures in [Analytics](/operations/analytics).
  </Accordion>
</AccordionGroup>

## Opening a subscription

Click into a subscriber to open its detail. This is where you see the **customer
plus the full payment history** of that one membership:

<Steps>
  <Step title="Subscriber & plan">
    The buyer (email, name, country), the subscription plan they're on, the
    price and billing frequency, and the current **status**.
  </Step>

  <Step title="Payment history — initial + renewals">
    Every successful charge recorded for this membership, newest-first: the
    **initial** payment that activated it and **each renewal** after it. Each
    row is a real transaction you can open. (Charges are matched to the
    subscriber both by its stored id and by its plan id, so the very first
    payment is included even though it can arrive moments before the subscriber
    record is finalized.)
  </Step>

  <Step title="Actions">
    From here you can **cancel** the subscription or **refund** it (which refunds
    the paid invoices and cancels the membership).
  </Step>
</Steps>

This view answers the most common subscription support questions at a glance —
"when did they start?", "did the last renewal go through?", "how much have they
paid in total?".

## A single payment's detail

Opening any transaction — a one-time order **or** a subscription payment — shows
its full detail.

### Quick-copy IDs

At the top of every order or subscription detail page, you'll find **quick-copy
chips** for the relevant IDs:

* **Order ID** / **Subscription ID** — the unique identifier for the transaction
  or subscriber record.
* **Product ID** / **Customer ID** — click to copy the ID for API calls or
  support lookups.
* **Portal link** (subscriptions) — copy the subscriber's billing-portal URL to
  share with them directly.

Click any chip to copy its value to your clipboard instantly.

### Payment breakdown

The payment breakdown shows the complete money flow:

* **Customer paid** — the total amount charged to the buyer.
* **Sales tax** — collected from the buyer and remitted to tax authorities (not
  part of your earnings).
* **Payment infrastructure fee** — charged by banks and card networks to move
  the money, screen for fraud and chargebacks, provide dispute prevention, and
  pay out your balance. Pocketsflow doesn't take any of this.
* **Pocketsflow fee** — our flat 2% platform fee. No monthly fees, no setup
  costs, no hidden charges.
* **You receive** — your net payout after all fees, added to your balance.

### Other details

* **Buyer / customer** — email and linked customer record.
* **What was purchased** — the product (for one-time orders) or the subscription
  plan (for subscription payments); one-time orders also show any **upsell** and
  its metadata.
* **Billing reason** — for subscription payments, whether this was the `initial`
  charge or a `renewal`.
* **Status flags** — refunded / disputed.
* **Review** — if the buyer left one linked to this sale.

From an individual order you can also **resend the receipt** to the buyer.

## Customers

The **Customers** view aggregates activity at the **buyer** level. A customer
record is created (or reused) the first time someone buys from you, keyed by
their email, so repeat buyers stay as a single customer. Typical fields:

* **Name** and **email**.
* **Country**.
* **First** and **most recent** purchase.
* **Total spend**, products owned, and any active subscriptions.

Use it to identify your best customers, see what a specific buyer owns before
answering a ticket, and target upgrade or win-back offers.

## Searching, filtering & exporting

Both Orders and Customers support:

* **Search** by email, name, or ID.
* **Filters** by date range and product (subscriptions can filter by plan).
* **Pagination** for large accounts.

For accounting or external analysis, **export to CSV** — a full export or only
records **since your last export**. Orders and subscriptions each have their own
export, including amount, country, status, plan/frequency, and payment
references.

## Related topics

* [Analytics](/operations/analytics)
* [Subscriptions](/selling/subscriptions)
* [Refunds & disputes](/payments/refunds-and-disputes)
* [Managing subscriptions (buyer)](/buyers/managing-subscriptions)
* [Buyer common issues](/buyers/common-issues)