Orders & entitlements

When a customer buys an ebook on packtpub.com, starts a subscription, or a company signs its team up for hosted access, something has to record what was bought and — more importantly — what that purchase now permits. Orders is that part of the platform: it captures first-party commerce on Packt's own storefronts, and every completed purchase produces an entitlement — a durable record of what this customer may consume, and where. Orders record the transaction; entitlements record the access.

This page covers the first-party side only. Sales made through partner channels — Amazon, subscription platforms, other retailers — never create orders here; those partners report sales in aggregate and settle through channel reporting instead. The split matters, and the sections below explain why.

What counts as an order

An order is a first-party transaction on a Packt storefront. Three kinds of activity flow through here:

• Purchases — a customer buys a product outright: an ebook, a print copy, a bundle. The product they buy comes from a catalogue, priced by that catalogue's price policy.
• Subscriptions — a customer (or a B2B organisation) pays for ongoing access rather than owning copies. The entitlement lives for as long as the subscription does.
• Refunds — the unwinding of either. A refund is a first-class part of the model, not an exception path.

What is deliberately not an order: a sale on Amazon, a read on a partner subscription platform, a library loan. Those happen outside the platform, on channel partners' own systems. The partner reports them back — typically in aggregate, on the partner's own schedule — and they settle through the channel relationship rather than through per-customer orders. One platform, two settlement paths:

Both paths feed the same royalty model in the end — authors are paid on sales wherever they happen — but only the first-party path creates entitlements, because only there does Packt itself serve the customer.

Entitlements: the customer-side gate

An entitlement is the plainest idea on this page, and the easiest to confuse with something else, so it is worth stating carefully.

An entitlement answers: may this customer access this product, here? It is created by a purchase or subscription, held against the customer's identity, and checked whenever the customer tries to read, download, or stream what they bought. It is the customer-side access gate.

A right answers a different question entirely: may Packt use this content in this way at all? Rights are the IP side — they come from contracts with authors and licensors, and they gate what the platform itself may do with content: publish it, ship it to a channel, serve it to an AI surface. The glossary keeps the two side by side for exactly this reason.

The two gates are independent, and both must pass. A customer with a valid entitlement still cannot be served content the platform has lost the rights to distribute; a title with perfect rights is still invisible to a customer who never bought it. Keeping them separate means neither system has to know the other's logic — Contracts never tracks customers, and Orders never interprets contract clauses.

From purchase to access

The flow is short by design. A customer, identified by the platform's Users service (sign-in itself is delegated to WorkOS), places an order on a storefront. When payment completes, the order produces one or more entitlements — one per product access granted. From then on, every time the customer opens the reader or downloads a copy, the entitlement is what says yes.

Subscriptions work the same way with one twist: the entitlement is tied to the subscription's life rather than granted permanently. While the subscription is active the entitlement stands; when it lapses, the entitlement lapses with it. B2B follows naturally — an organisation's subscription grants entitlements that cover the organisation's members, so a company signs one agreement and its whole team is covered.

Refunds unwind cleanly

A refund is not a deletion — it is a recorded reversal. When an order is refunded, the entitlements it created are revoked, and everything downstream sees the reversal rather than a gap: access ends, and the sale is backed out of any royalty accrual it fed, so an author is never paid on a sale that was returned. Nobody reconciles refunds by hand, and the history of what happened — bought, then refunded — is preserved rather than erased.

The same principle protects the customer in the other direction: a revoked entitlement removes access to the refunded item and nothing else. Everything else the customer owns is untouched.

Feeding royalties

Orders carry the facts that author payments are calculated from: what sold, for how much, and whether it was later refunded. The rules that turn those facts into money — rates, bases, advances, splits — live on the contract, and are described on the royalties page. The service that runs the calculation — accrual, statements, payouts — is a future piece of the platform; the model it will execute is settled now, which is why orders only ever record facts and never royalty amounts.

Signals

Like the rest of the platform, Orders will announce what happens as events, following the platform's naming grammar. None of these names are claimed yet — the table is a sketch of shape, not a registry:

Consumers you might expect: storefronts reacting to grants and revocations, and — eventually — the future Royalty service accruing from completed and refunded orders.

Related pages

• Contracts & Rights — the IP-side gate: what Packt may do with content, as distinct from what a customer may access.
• Royalties — the settled model that order facts will feed: rates, bases, advances, and splits.
• Catalogues — where the products a storefront sells, and their prices, are defined.
• Distribution & Channels — the third-party path: how sales on partner platforms reach customers and settle.
• Glossary — rights, entitlements, and the rest of the platform vocabulary in one place.