Running your store day to day

This is the playbook for whoever opens the dashboard every morning. It assumes the store is already live — if you are still setting one up, start with Set up a workspace and go live.

The shape of the day

Throttle does the mechanical work — taking payment, calculating tax, emailing the buyer — and escalates only what needs a human. In practice your day is three passes:

Clear the new orders. Anything paid and unfulfilled is waiting on you.
Handle the exceptions. Failed payments, returns, disputes, anything flagged.
Check what’s aging. Unpaid invoices and stalled fulfillments, before they become older problems.

Everything below fits into one of those three.

Orders as they arrive

An order’s status tells you what it is waiting for. The states that matter operationally:

Status	What it means	Your move
`pending`	Created, money not yet taken	Usually nothing — capture is automatic
`processing`	Paid, being worked	Fulfill it
`partially_fulfilled`	Some lines shipped	Ship the rest
`completed`	Everything fulfilled	Nothing, unless it comes back
`cancelled`	Abandoned before fulfillment	Nothing

Most orders walk this path without you. The ones that stop mid-path are the ones to look at.

Fulfilling

A fulfillment is the record of goods actually reaching the buyer. Throttle supports five types — shipment, digital, access, service, and in-person — because “delivered” means something different for a physical product than for a license key.

You can fulfill an order in parts. Ship three of five items and the order moves to partially_fulfilled; the remaining two stay outstanding and visible. Do not wait until everything is ready to record the first shipment — the buyer’s tracking email fires on the fulfillment, so holding it back just delays telling them.

When something goes wrong

Most exceptions are one of four things, and picking the right tool matters more than moving fast:

Buyer wants money back, nothing is returning — refund.
Order is being abandoned before it ships — cancel. Open authorizations are always voided, but captured money is only refunded if you explicitly ask.
Goods are coming back — open a return, so the inbound box is tracked.
Buyer wants a different item — exchange, which settles only the difference.

The full comparison, including the failure modes for each, is in Refunds and returns.

The one worth memorising: cancelling an order does not refund captured money by default. If you cancel an order you already captured and do not opt in, the buyer’s money stays with you and nobody is told.

Chargebacks and disputes

A disputed payment is money you already counted that is now contested. Card chargebacks arrive automatically from the processor and flag the payment; you can also flag one by hand, which is what you’ll do for a B2B buyer refusing an invoice.

Treat the flag as a notification, not a workflow. Throttle records that a payment is contested so it stops looking like clean revenue — contesting the chargeback itself happens in your processor’s dashboard, and a lost dispute stays flagged, so the flag alone won’t tell you what’s still open. See Disputes and chargebacks.

Customers

A customer record is the thread tying orders, saved cards, addresses, and subscriptions together. Two things are worth doing deliberately:

Set externalId if the buyer exists in your own system. It’s what lets you match a Throttle customer to your record without storing our UUIDs.
Don’t create duplicates. Look the customer up by email or external id before creating one. Two records for the same human means split order history and a buyer who can’t see half their purchases.

What to watch

Three numbers tell you whether the machine is healthy:

Failed payments. A rising rate usually means a processor or configuration problem, not a run of bad luck.
Aging receivables, if you sell on invoice terms. See Getting paid on invoice terms.
Abandoned carts. Throttle sweeps for these and can send recovery emails; a spike often means something broke in checkout rather than a change in buyer behaviour.

If checkout itself looks wrong, that’s a developer problem rather than an operations one — hand it over with the order or session id attached, which is the fastest thing you can give them.