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

# Managing Orders

> Find, deliver, refund and export orders from your Komerza dashboard

Every order your store takes lives under **Home → Orders** in the dashboard. From there you can search and filter orders, open any order for full detail, deliver or re-deliver it, resend the receipt, issue a refund, and export your order history.

## Finding an order

The Orders page has tabs - **All / Delivered / Pending / Undeliverable / Disputed / Refunded** - each with a live count.

The search box understands several inputs:

| Input                         | Behaviour                                                                                                                              |
| ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| Full order ID                 | Exact match                                                                                                                            |
| Full customer email           | Exact match - partial emails fall back to fuzzy matching                                                                               |
| Payment note (`xxx-yyy`)      | Exact match                                                                                                                            |
| Payment method or status name | Matches orders using that method or status                                                                                             |
| Anything else                 | Fuzzy match against customer emails, product names, coupon codes, delivered key/text content, and Discord username, display name or ID |

The **Filter** dropdown narrows results by date range, status, payment method, customer email and Discord.

## Order statuses

Every order carries one status describing where it sits between "cart created" and "goods delivered". The full reference is on the [Order Status](/api-reference/payment-status) page; here is what each one means operationally:

<AccordionGroup>
  <Accordion title="Incomplete - no action needed">
    A cart was created but never paid. It remains editable and the customer can
    still complete payment. Unpaid orders are automatically cancelled roughly 12
    hours after creation, which releases any reserved stock.
  </Accordion>

  <Accordion title="Pending - usually no action needed">
    Payment has been received or detected but funds are still settling. Typical
    for bank transfers and cryptocurrency. Orders paid with a [custom payment
    method](/guides/custom-payment-methods) show "Awaiting seller review" and
    **do** need you to approve or reject the proof of payment.
  </Accordion>

  <Accordion title="Verifying - no action needed">
    Funds withheld for verification. Treat as payment in flight.
  </Accordion>

  <Accordion title="PartiallyPaid - action needed">
    The customer underpaid a crypto invoice. The order is **not** fulfilled. The
    customer has already been emailed the expected amount, the received amount
    and the exact shortfall. Arrange the difference with them directly, then
    deliver manually.
  </Accordion>

  <Accordion title="Delivering - no action needed">
    A guard status while delivery executes. It should pass quickly on its own.
  </Accordion>

  <Accordion title="Delivered - no action needed">
    Paid and delivered. The customer received a delivery email with their items.
    **Resend receipt** and **Re-deliver** are available from the order page.
  </Accordion>

  <Accordion title="Undeliverable - action needed">
    Paid, but delivery failed - most commonly missing stock, but also a dynamic
    delivery endpoint returning a non-200 response. The warning banner on the
    order page names the cause. Fix it, then use **Deliver manually**.
  </Accordion>

  <Accordion title="Cancelled - no action needed">
    Expired or cancelled. A cancelled cart is not dead: it can be revived,
    edited and paid again.
  </Accordion>

  <Accordion title="Refunded / Disputed">
    A refund was issued, or a chargeback was opened with the payment provider.
    Disputes are handled in your payment provider's own dispute tooling.
  </Accordion>
</AccordionGroup>

<Note>
  Once a payment is in flight, cart items lock. A customer who tries to change
  items sees: "A payment for this order has already been detected and is being
  confirmed - items can no longer be changed." This protects the amount the
  payment was matched against.
</Note>

## Delivering an order manually

Open the order and use **Deliver manually**, available when the order is Pending, Incomplete, Cancelled, Undeliverable or PartiallyPaid. It runs the normal delivery flow exactly as if the order had been paid: stock is consumed, the receipt email is sent, the `order.completed` webhook fires, and Discord roles are granted. The order is stamped **Delivered Manually** with the team member's email.

<Warning>
  Manual delivery does **not** verify payment. Confirm you were actually paid
  first. Manually delivered orders can only be refunded to customer balance,
  never back to the gateway.
</Warning>

**Re-deliver order** appears only on Delivered orders. It reruns the entire original delivery: it consumes new license keys from inventory, re-fires dynamic delivery webhooks, and re-sends emails. Use it deliberately.

Both actions require the deliver-orders permission, and a second attempt while a delivery is in flight is quietly ignored, so orders cannot be double-delivered by accident.

## Resending a receipt

**Resend receipt** re-emails the already-delivered items, with no new fulfilment. It is available for Delivered and Disputed orders and is rate-limited.

<Note>
  If an order was created with receipts turned off - for example via the
  send-receipt toggle on a payment link - resend reports success but sends
  nothing.
</Note>

## Refunds

Refunds are issued from the order page with **Process refund**. Refunds are only possible on **Delivered** orders and are always for the **full amount**; there are no partial refunds.

The modal asks for two things:

<Steps>
  <Step title="Refund reason">
    Fraudulent, Requested by customer, Duplicate, or Other. The reason is stored
    with the order, included in notifications, and may be forwarded to the
    gateway. See [Refund Reason](/api-reference/enums#refund-reason) for the API
    values.
  </Step>

  <Step title="Refund destination">
    **Original payment method** - the gateway processes the refund
    automatically. Available for Customer Balance, Mollie, Square,
    Authorize.net, Stripe, SumUp, PayPal (modern integration), Shopify, Paddle
    and FastSpring.

    **Customer balance** - instant store credit that never touches the gateway.
    The destination is locked to balance when the order was paid with customer
    balance, was delivered manually, used a gateway with no refund API (NMI,
    MoneyMotion, Pandabase, Storrik, VenPayr), or used a method that can only be
    settled manually (all cryptocurrencies, custom payment methods, Cash App,
    PayPal Friends & Family, legacy PayPal).
  </Step>
</Steps>

A successful refund sets the order to **Refunded**, reverses any affiliate commission, and fires the `order.refunded` webhook. If the gateway rejects the request, the order is safely restored to Delivered and the UI reports the failure. Simultaneous refund attempts are blocked, so two team members cannot double-refund the same order.

<Warning>
  **Cryptocurrency refunds move no funds.** Marking a crypto order refunded
  changes its status only - you must return the cryptocurrency to the customer
  manually. The same applies to custom payment methods, Cash App and PayPal
  Friends & Family.
</Warning>

Two balance-specific rules: a balance top-up order can never be refunded to balance (it would double-credit), and refunding a top-up to the card also claws the credited balance back. For split payments, each part returns to its own source.

## Exporting orders

**Export CSV** on the Orders page opens a modal with a start and end date, defaulting to the last 30 days. The file has one row per order with these columns:

```
OrderId, DateCreated, Status, Gateway, Amount, Products,
AmountPaid, CurrencyCode, TransactionId, CustomerEmail
```

<Note>
  Exports require a logged-in dashboard session - this endpoint cannot be called
  with API keys - and are rate-limited. For a single order, **Export PDF** on
  the order page produces a printable invoice.
</Note>

## Order data for developers

* Orders created through the API are marked **Source: API** in the order's Technical Details.
* You can attach custom **metadata** at creation: up to 20 keys, each key up to 40 characters and each value up to 500 characters. Metadata is merchant-only and is always stripped from anything the customer can see.
* The **Webhook Execution Logs** card on an order page shows the most recent 100 webhook deliveries for that specific order.

## Next steps

<CardGroup cols={2}>
  <Card title="Store Webhooks" icon="webhook" href="/guides/webhooks">
    Get order events pushed to your own server.
  </Card>

  <Card title="Custom Payment Methods" icon="money-check-dollar" href="/guides/custom-payment-methods">
    Approve or reject manually-paid orders.
  </Card>

  <Card title="Order Status Reference" icon="list-check" href="/api-reference/payment-status">
    Every status and its meaning.
  </Card>

  <Card title="Orders API" icon="code" href="/api-reference/endpoint/orders/get-list">
    Query, deliver and refund orders programmatically.
  </Card>
</CardGroup>