"I'm a Finance Director…" — your 39 questions, answered.

No — there are two components, and we'd rather you budget both from day one. The recurring cost is the platform fee: Launch at $650 per month ($6,500 if paid annually), Growth from roughly $1,300–$1,950 per month depending on catalogue and features, and Enterprise agreed per deal. The second component is a one-time Launch & Onboarding Package covering catalogue ingest, app design, store submission and launch support, which is agreed per publisher based on catalogue size and scope, and can be staged across the launch period. Beyond what you pay us: payment processing on your own checkout (typically 1.5–3% to your payment provider), and your own team's time to market the channel. We model all of this with you, on your numbers, at the demo — and hand over the spreadsheet.

It covers everything between signature and a live app: catalogue ingest and conversion checks, app design in your brand, Apple and Google developer account setup (in your name — see 4.2), store submission, storefront integration, QR asset generation for your print runs, and launch-week support. Yes, it can be staged — publishers typically split it across the onboarding period rather than paying on day one.

Arithmetically: whenever 20% of your annual direct digital revenue exceeds our annual fee. At the Launch fee of $7,800/year ($650 × 12), the crossover sits at $39,000 of direct digital revenue; on annual billing ($6,500) it's $32,500. Below the crossover, a commission model is genuinely cheaper — and we'll tell you so, and suggest the cheapest sensible way to build toward it. Above it, every additional dollar of direct revenue widens the gap in your favour, because our fee doesn't grow with your success. A commission provider takes more from you in absolute terms every year your channel grows; that is precisely the wrong incentive structure for a channel whose whole purpose is growth. For comparison, typical commission models in this market charge 20% of gross or net revenue plus setup fees of £250–£750, forever.

Whatever your payment provider charges you — we add nothing. Because checkout runs on your terms (your web checkout, in-app purchase, offline, or vouchers — your choice of mix), the processing relationship is yours: typically 1.4–2.9% + a small fixed fee per transaction with mainstream providers. We are not the merchant of record on your web sales, we don't sit in your money flow, and there is no Publish360 transaction fee. The only channel that carries a platform-level fee is in-app purchase, where Apple and Google set the terms (see 1.5) — which is why we make in-app checkout an option you control, not a default you're forced into.

If you enable in-app purchase, Apple and Google charge their platform commission — 15% for most publishers under their small-business programmes (under $1M/year through the store), 30% above that threshold. That's why we treat in-app purchase as one option in your checkout mix rather than the backbone: most publishers route the bulk of sales through their own web checkout (0% platform fee) and use in-app purchase selectively, where the convenience of one-tap buying justifies the margin. Recent regulatory changes (in the US, EU and elsewhere) increasingly allow apps to link out to external checkout; we track these changes and pass the benefit through to you as store policies evolve. You choose the mix — and can change it.

Royalties on direct sales are governed by your author contracts, not by us — but the platform is built so that the accounting is never the obstacle. Every direct sale is recorded with title, price paid, buyer territory and date, and exports cleanly to your royalty system. Two things are worth knowing. First, most standard contracts pay royalties on net receipts — and your net receipts on a direct sale are far higher than on the same sale through a retailer, so authors typically earn more per copy from your direct channel even at unchanged royalty rates. Second, many publishers choose to share the direct-channel margin further — some agents now expect it — and a higher direct royalty rate is one of the strongest cards you hold in the next contract negotiation: it aligns your authors with the channel's success. We'd encourage you to decide your direct-royalty policy before launch and communicate it to authors and agents proactively; see 2.5 for what to tell agents.

By actual reading. The platform records which titles each subscriber opened and how much of each they consumed, so subscription revenue can be allocated per title on a consumption basis — the same principle streaming services use, but with the ledger in your hands rather than a black box. That gives your royalty team an auditable basis for paying authors on subscription income, and gives agents a straight answer instead of a shrug. Before launching any subscription tier, check your contracts permit subscription exploitation (see 2.2) and decide the allocation basis in writing; we'll give you the data to operate whichever basis you choose.

The headline break-even — 143 direct sales a month at typical prices, or 100 subscribers at $6.50 — covers the platform fee. Your true break-even adds two lines: payment processing (1.5–3%) and the author royalty on each direct sale, which depends on your contracts. As a worked example: on a $13 ebook, with 2% processing and a 25% net-receipts royalty, you keep roughly $9.55 per direct sale versus roughly $6.30 net from a typical retail sale after the retailer's cut and the same royalty — so each direct sale is still worth about half as much again as a retail sale, and break-even on incremental margin (direct versus retail on the same unit) needs materially fewer sales than the headline number suggests. Bring your actual royalty rates to the demo and we'll run the calculation on your numbers, in a spreadsheet you keep.

Yes — it's your checkout and your price file. Publishers use direct pricing three ways: matching retail (simplest, no channel-conflict questions), premium bundles (ebook + audiobook + bonus content at a price no retailer can assemble), and direct-first editions or early windows at full price. What we'd caution against is systematic undercutting of retail on identical products: it invites trade friction (see 7.1) and trains readers to see your channel as the discount bin. The stronger play — and the one the whole platform is designed around — is to make the direct edition worth more (exclusive content, formats bundled, early access) rather than cost less. Note that if you sell any titles under agency terms, your agreements may constrain retail price relationships (see 7.3).

On your web checkout: you are. The sale happens on your storefront, on your terms, and the customer relationship — including the money — is contractually yours. That's a deliberate structural choice: merchant-of-record platforms (where the vendor takes the payment and remits to you) are simpler to start with but put your revenue, your customer records and your refund policy inside someone else's company. On in-app purchases, Apple or Google is the merchant of record, as on every app on those stores. On offline sales and vouchers, you are. If you'd rather not carry merchant-of-record obligations for digital VAT in some territories, we'll discuss the right structure at the demo — including where a merchant-of-record checkout for specific territories can be sensible (see 3.1).

On web, offline and voucher sales: no. Reader payments go to your payment provider and settle to your bank account on your provider's normal schedule; we never hold your revenue, and there is no settlement delay, minimum payout or reserve on our side. In-app purchases settle from Apple/Google to you on their standard cycles (roughly 30–45 days). Our invoice to you — the platform fee — is a separate, predictable line item. Your FD can treat direct revenue as first-party revenue, because it is.

Thirty days' notice, no long-term lock-in. If you leave, you keep the app (it's on your developer account), your reader data (full export), and your content; see 8.3 for exactly what offboarding involves. We think notice periods are a test of confidence: a vendor that needs to lock you in for three years is telling you something about how it expects you to feel in year two.

Partly — and that's fine, because a cannibalised sale is worth more to you. When a reader buys from you instead of a retailer, your net receipt on that unit typically rises by 30–50% (see 1.8), so even a fully cannibalised sale is margin-accretive. But three effects mean direct channels are not zero-sum in practice. First, the QR mechanism converts print buyers — people who already bought through the trade — into digital app users, which is additive, not substitutive. Second, exclusive content and bundles create purchases that don't exist at retail. Third, subscription income is a category retailers barely offer for your list at all. The honest position: some substitution happens, it's profitable substitution, and the channel's growth comes mostly from purchases the retail channel was never going to generate. Model both cases in the calculator — set the substitution assumption as high as you like and watch what it does to net margin.

Three, honestly. Marketing time: the channel succeeds on audience-building — budget a few hours a week of marketing attention for push campaigns, email, QR placement in new print runs, and promotion planning; publishers who treat the app as shelfware get shelfware results. Royalty administration: one-off work to confirm your contracts cover direct and subscription sales (see 2.1), and a small recurring addition to royalty runs. Finance setup: confirming VAT treatment in your main territories (see 3.1–3.2). What you should not budget: developers, hosting, app-store liaison, DRM licensing, or customer-care infrastructure — that's what the platform fee buys. No new headcount is the honest claim; no new hours would not be.

Your contracts set the floor; the market is setting expectations above it. At standard net-receipts rates, authors already earn more per direct sale than per retail sale, because your receipts are higher — that's the mechanical answer, and for many lists it's sufficient. But agents increasingly argue that if the publisher keeps 85–100% of a direct sale instead of 35–70%, the author should share the uplift — and several publishers with successful direct channels have made a higher direct royalty part of the pitch to authors, treating it as an acquisition and retention tool rather than a cost. Our guidance: decide a policy deliberately (standard rate, uplifted rate, or uplift above a volume threshold), document it, and lead with it in agent conversations. A direct channel with author buy-in markets itself; one that looks like margin hoarding invites contract friction. The platform's reporting supports whichever policy you set.

That's your choice, at the granularity you choose. The platform's dashboards show sales, revenue and reading engagement per title in real time; you decide what to expose to whom. Some publishers give authors live read-only access to their own titles' figures (launch-day sales visible hour by hour is, in our experience, the single most-loved feature among authors); others fold direct-channel lines into their existing royalty statements. Either way, the underlying ledger exports to your royalty system, and every number an agent might challenge is auditable back to individual transactions.

It follows the merchant of record, channel by channel. In-app purchases: Apple and Google are merchant of record and handle VAT/sales tax globally — that's the one real advantage of their commission. Your web checkout: you are the merchant, and digital VAT obligations are yours — which sounds worse than it is, because modern checkout stacks automate nearly all of it: EU sales run through a single OSS (One Stop Shop) registration; the UK, and US states with digital-goods nexus rules, are handled by your checkout's tax engine. If your finance team would rather not carry those registrations at all, options include routing specific territories through in-app purchase or using a merchant-of-record checkout for exports. We walk through your specific territory mix at the demo — this is a solvable plumbing question, not a strategic obstacle, but it deserves a real answer rather than a hand-wave, and your accountants should sign off the structure.

Possibly one: if you sell digital products to EU consumers and aren't already registered for the EU's OSS (or its non-Union equivalent), that single registration covers all 27 member states — most publishers with any existing digital direct sales already have it. Domestically, digital sales simply join your existing VAT return. In the US, economic-nexus thresholds (commonly $100k of sales per state) mean small and mid-size publishers rarely trigger registration duties in early years, and checkout tax engines monitor thresholds for you. The honest summary: for most publishers, direct digital selling adds at most one registration and some checkout configuration — but confirm your specific position with your advisers before launch, not after.

The platform is independently penetration-tested, with encryption in transit and at rest as standard, and a security summary document is available on request before you sign anything. Behind the platform sits Eden Interactive's operating record: consumer ecommerce run continuously since 1999 — two decades of handling payment-adjacent consumer data at retail scale. If your IT team has a security questionnaire, send it over; a straight, complete answer is part of the service.

On your web checkout, your refund policy applies, within consumer law: in the UK/EU, the statutory 14-day cooling-off right for digital content is waived once the customer consents to immediate access and acknowledges losing the right — which is the standard, lawful pattern for ebook delivery, and the checkout flow implements it. Faulty content must always be refundable. In-app purchases follow Apple/Google refund processes, which they adjudicate. Subscriptions must be cancellable as easily as they're started (a legal requirement in a growing list of territories, and good retention hygiene anyway — a reader who can leave easily trusts you enough to come back). Our customer-care layer handles the reader-facing mechanics; your policy sets the rules.

You take it with you; it was yours throughout. On termination you receive a full export of your reader data — identities, contact details (with consent status), purchase history, and reading-engagement data — in standard machine-readable formats (CSV/JSON), after which our copies are deleted on the schedule in the DPA. Because the app lives on your developer accounts, the install base and store listing also remain yours (see 8.3). The design intent is simple: exit should be a logistics exercise, not a hostage negotiation — and we're happy for you to test the export before you rely on it.

Because it converts the app from a service you rent into an asset you own. The Apple and Google developer accounts determine, contractually and technically, who owns the store listing, the app's ratings and reviews, its install base, and its push-notification relationship with every reader who installed it. If the app lives on a vendor's account, then no matter what your contract says, leaving the vendor means leaving the asset: your readers' installed app belongs to someone else's account, and you start again. On your own account, a change of platform provider is an update your readers receive, not an app they lose. It costs you $99/year (Apple) and a one-off $25 (Google) — we set both up in your name during onboarding — and it is, in our view, the single most important structural question to ask any app vendor in this market. Most don't volunteer the answer.

The platform absorbs it — that's a core part of what the fee buys. Store policies shift constantly (IAP requirements, external-link rules, privacy-label demands, SDK deadlines), and the regulatory environment is currently moving in publishers' favour — courts and regulators in the US and EU have been forcing the stores open to external checkout links. When rules change, we update the platform and every publisher's app inherits the fix; when rules loosen, you inherit the opportunity (e.g., link-out checkout reducing IAP exposure — see 1.5). Because your checkout mix is diversified by design (web, in-app, offline, vouchers), no single store's policy change can hold your revenue hostage — which is precisely the resilience argument for owning a multi-channel checkout rather than living inside one store's rules.

You get named support for your publishing team during UK business hours, with reader-facing customer care handled separately so your readers are looked after without consuming your staff's time. Uptime targets, response-time commitments by severity and support channels are all stated plainly in the service agreement — ask for the current figures at the demo and we'll put them on the record.

Yes — that's the design. Checkout on your terms means the four routes (your web checkout, in-app purchase, offline/point-of-sale, and gift vouchers/access codes) are a mix you choose and can rebalance, not a decision you make once at gunpoint. Typical pattern: web checkout carries the volume (0% platform fee), in-app purchase serves impulse and convenience where its margin cost is justified, vouchers and codes serve gifting, events and B2B, and offline/POS turns festival stands and launch events into app-acquisition moments. All four routes land content in the same reader library and the same ledger — one customer, one library, however they paid.

Yes: gift vouchers for consumer gifting, access codes for review copies, influencer campaigns, prize fulfilment and corporate gifting, and bulk code batches for institutional and B2B sales. Codes are more strategically interesting than they look: every redeemed code converts an anonymous recipient into a named reader in your data, which makes vouchers simultaneously a revenue product and an acquisition channel. Review-copy distribution through codes also replaces emailing unprotected PDFs to strangers — your publicity team's most cherished piracy tradition.

No per-gigabyte surprises: hosting, streaming and download delivery are included in the platform fee. This is worth asking every vendor in this market, because audio delivery costs real money and some pricing models pass it through as usage fees that only appear when your audiobook programme succeeds. Flat and predictable is the design principle of our fee generally; audio is where that principle earns its keep.

Yes — promotional pricing and campaigns on your checkout (your prices, your calendar, no retailer approval process), coupon and voucher mechanics (see 5.6), and free sampling (opening chapters free in-app; a free-sample funnel is the cheapest reader-acquisition instrument in publishing). Direct-channel promotion has one structural advantage worth internalising: a retail promotion buys a spike that vanishes into someone else's customer file; a direct promotion buys the same spike plus the named readers it brought, who can be re-marketed for free, forever.

Launch period (first 6–8 weeks): a few hours a week from marketing (campaign assets, email copy, QR placement decisions) plus pockets of time from ops (catalogue checks) and finance (setup — see 1.14). Steady state: the honest range is 2–5 hours a week of marketing attention — the channel runs on the same campaign calendar your marketing team already keeps, with the app as an additional (and unusually measurable) channel for each campaign rather than a separate workstream. What takes zero hours: development, hosting, store compliance, DRM, reader tech support. The honest failure mode isn't overwork — it's neglect: a channel nobody feeds for a quarter stalls, which is why "no new headcount" is true and "no new hours" would be a lie. We'd rather you budget five hours a week and be pleasantly surprised.

Honest answer: adoption varies with the drivers you'd expect — the size of your email list, your print volumes, the strength of the launch offer and how visibly the QR codes are placed. The calculator on this site uses inspectable assumptions rather than guarantees, and at the demo we model the crossover point on your own numbers. What we won't do is dress projections up as track record: we show you the live evidence we have, on the record, and let the inspectable calculator speak for itself — your titles, your assumptions, your numbers.

Match the model to the reading pattern. All-access suits deep, genre-coherent backlists with voracious readers (romance, crime, category fiction). Per-author clubs suit houses with marquee names whose fans want everything, early. Books-plus-exclusive-content suits literary lists and fandoms where intimacy is the product. Focus-area subscriptions suit specialist non-fiction (a subject shelf as a service). Audio-only suits commuter-heavy audiences and keeps the tier's delivery costs legible. Library-style (any N titles at a time) suits broad general lists — it caps consumption economics while feeling generous. Two rules from the Innovation page's logic: subscription must offer readers something ownership doesn't (breadth, earliness, or intimacy — not just a different payment schedule), and check rights before enrolling titles (see 2.2). Start with one model, priced simply; a confused subscription page converts nobody.

No general legal obligation compels it — you set your direct prices. The practical considerations: where you sell ebooks under agency terms you control retail price anyway (and should check your agreements for any parity language); where retailers discount at their own expense under wholesale terms, your direct price may sometimes be undercut by Amazon, which is survivable because your channel's offer is value, not price (see 6.1). Our guidance is boring and firm: hold direct prices at or near RRP, win on bundles and exclusives, and never train readers to comparison-shop you.

You'd be inconvenienced, not destroyed — by design. The assets that matter survive independently of us: the app listing and install base live on your developer accounts; your reader data is yours and exportable at any time (test the export whenever you like — see 3.9); your content files are yours; and the DRM is Readium LCP, an open standard operated by an independent non-profit ecosystem (EDRLab), not our proprietary lock — LCP-protected libraries don't die with any single vendor. The platform's service — the running backend — would need replacing, and that's real disruption we don't minimise: readers' apps would need a successor platform behind them. But compare the failure modes across the market: a shared-app vendor's failure deletes your channel and your readers' libraries outright; ours leaves you holding the app, the audience, the data and openly-licensed content, shopping for a new engine rather than a new life. See 8.2 for continuity specifics.

The strongest continuity provision isn't a contract clause — it's the structure: the app sits on your developer accounts, your reader data is exportable in full at any time, and your content is protected by Readium LCP, an open standard rather than a proprietary lock. Contractual continuity commitments — wind-down notice periods and data-return guarantees — are stated in the agreement, and we'll walk your FD through them before signature.

You keep: the app (it's on your developer accounts — listing, ratings, install base), your readers (full data export: identities, consents, purchase history, engagement data — see 3.9), your content (your files, plus LCP-protected copies readable in any LCP-compliant system), and your storefront (it was always yours). Offboarding on 30 days' notice involves: final data export and verification, transfer of any operational credentials, and an agreed reader-communication plan for the service transition. What leaving costs you: the platform's running services (delivery, sync, analytics, care) until a successor is in place. What it doesn't cost you: your audience, your asset, or your history. We'd rather be kept by merit than by moat — and an exit this clean is only a risk to vendors who expect customers to want one.

We're early, and we won't pretend otherwise. We share adoption data from our founding publisher cohort at the demo, plus direct reference calls where publishers have agreed to take them. What we won't do is decorate this page with logos of houses that ran a pilot once. The platform's economics don't require you to take adoption on faith — bring your own catalogue to the demo and the evidence is your own titles, your own readers, your own numbers.

Eden Interactive has run consumer ecommerce since 1999 and has operated Eden.co.uk — one of the UK's largest independent online book retailers — since 2004, serving over three million customers and selling many millions of books. That matters for a specific reason: Publish360 wasn't built by a software company guessing at retail; it's the productisation of two decades of actually selling books to actual readers — merchandising, checkout, customer care, promotion cycles, Christmas peaks and all. We're also an EDRLab member (the European Digital Reading Lab, home of Readium and LCP), which anchors the platform's open-standards commitments in governance, not just marketing copy. The candid version of "why trust us": don't — verify us. The inspectable calculator, the exportable data and the 30-day notice period are all designed so that trust is continuously optional.

Professional indemnity, cyber liability and public liability cover are in place, with certificates available on request — ask at the demo or during procurement and we'll send the current schedule the same day, so your procurement team gets what it needs without an email round-trip.

Seven questions, and we'll answer all of them on this page or at the demo: (1) Whose developer account is the app published under — and what happens to the install base if we separate? (See 4.2.) (2) Who is merchant of record, and does our revenue flow through your accounts? (See 1.10.) (3) What DRM do you use, and is it an open standard or your proprietary lock? (See 4.4.) (4) Who controls our reader data, under what DPA, and in what format do we get it back? (See 3.3, 3.9.) (5) What does exit actually involve — walk us through offboarding. (See 8.3.) (6) What are the total costs — setup, commission, transaction fees, delivery/bandwidth, and fee-growth as we grow? (See 1.1, 5.8.) (7) Show us adoption evidence from live publishers — or tell us honestly that you're early. (See 8.4.) We've published this list because the comparison genuinely favours structures like ours — and because a publisher who asks all seven of every vendor will make a good decision even if it isn't us. That's the confident version of candour, and it's the house style.