"I look after IT and data protection…" — your 27 questions, answered.

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.

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).

Per title, by buyer territory. Your rights metadata governs where each title can be sold: a reader whose store territory (and payment/billing country on your checkout) falls outside a title's rights territories doesn't see it offered for sale. This mirrors how retailers enforce territoriality, with one advantage: the ledger of where each sale happened is yours, so a rights query from a co-publisher or agent can be answered with data rather than assurances. Note the usual boundary: territorial enforcement governs sale; a reader who legitimately bought a title while resident in-territory doesn't lose their library when they travel.

You are the controller of your reader data; we process it on your instructions under a data processing agreement. That's the legal expression of the platform's core promise — the reader relationship is yours. Reader personal data (identities, emails, purchases, reading behaviour) is collected under your privacy notice, used for your purposes, and exportable by you at any time; we don't use your readers for our own marketing, don't sell data, and don't commingle your readers with other publishers' audiences. Your DPO gets a DPA with a named sub-processor list (see 3.4). Contrast this with shared-app and marketplace models, where the vendor is often controller or joint controller of your readers — which is precisely how publishers ended up renting their own audiences back.

Yes — the DPA, sub-processor list, and security summary are available before you sign anything, not after. Send them straight to your DPO and IT lead; the demo can include a session with our technical team to answer their questions directly.

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.

The reading experience is built on EPUB 3 and Readium — the open-standards stack that the accessibility community itself develops against — with adjustable typography, reflowable text, screen-reader compatibility and text-to-speech support. The EAA, in force since June 2025, makes accessibility a market-access requirement for ebooks and reading apps sold to EU consumers — and it applies to your app, so you should ask any platform vendor for a conformance statement, not a vibe. Ask us for ours at the demo. Two of the strongest vendors in adjacent markets publish WCAG 2.2 AA conformance; that's the benchmark this platform should meet or state its path to.

Children's publishers need two things: no collection of children's personal data without verifiable parental consent (COPPA in the US, age-appropriate design codes in the UK/EU), and an app-store listing that correctly declares its audience. The standard pattern — which the platform supports — is an adult-purchaser model: the account holder is the parent/adult customer, purchases and data belong to the adult, and child reading profiles hold no personal data beyond a display name. Store-listing age declarations and privacy-label entries are configured per app during onboarding. If your list is substantially children's content, raise it at the demo so the design gets it right from the start — retrofitting consent flows is expensive.

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.

Three structures dominate this market, and the label "white label" gets applied to all of them, unhelpfully. A shared app (the most common model) means your readers use the vendor's app — your books appear inside it, sometimes with your branding on the shelf, but the app listing, the install base and often the customer relationship belong to the vendor. An SDK means the vendor licenses you reading-engine components and your developers build and operate your own app around them — maximum control, but you become a software team. A true white-label app — Publish360's model — means a complete branded app built and operated for you, but published under your own Apple and Google developer accounts, so the asset is structurally yours without your team writing code. The question that cuts through every vendor's marketing: whose developer account is the app published under, and who keeps the readers if we separate? Ask it of everyone, including us.

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.

Readium LCP — the open, passphrase-free DRM standard developed by EDRLab, of which Eden Interactive is a member. Why LCP: it protects content with real encryption (unlike watermarking, which only identifies leaks after the fact) while treating readers like customers rather than suspects — no Adobe ID, no third-party account, no device-authorisation ritual that fails at 9pm on launch night. Why not Adobe DRM: it's a closed system with per-transaction costs, a reader experience that publishers' own support inboxes testify against, and a dependency on one company's licensing decisions. Why not watermarking alone: for some lists it's a reasonable choice, but most trade publishers and agents want encryption on frontlist. LCP is also what a publisher should want strategically: because it's an open standard, your protected files aren't hostage to any single vendor — including us.

We prepare and manage the submissions on your developer accounts, and store review is our problem to absorb, not yours to learn: we know the current review guidelines, the reader-app category's specific rules (including what a reader app may and may not link to), and the documentation each store expects. Rejections in this category are almost always resolvable formalities — a metadata clarification, a screenshot revision, a purchase-flow adjustment — handled in days as part of onboarding, and the launch timeline we give you includes review contingency. Post-launch, every update goes through review the same way, invisibly to you. What you'd feel as existential risk alone — "Apple said no" — is, for a platform that ships app updates continuously, routine weather.

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.

We do — it's a maintained platform, not a bespoke build. OS-version updates, security patches, crash fixes, store-policy compliance and feature releases ship to your app continuously, under your developer account, with no work from your team; you never inherit a codebase, a backlog or a maintenance invoice. This is the structural difference from agency-built apps, which are famously cheap to quote and ruinous to keep alive: the $104k–$325k build-it-yourself estimate on our pricing page is the entry price of that road — the 15–20% annual maintenance is the toll.

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.

The roadmap is ours to run and yours to influence: features ship platform-wide, so every publisher inherits every improvement without integration projects (that's the economics that keep the fee flat). Publisher requests are weighted by how many houses need them. Genuine custom development — features exclusive to one publisher — is Enterprise-tier conversation territory: possible where it doesn't fork the platform, honestly declined where it would, because a forked platform quietly becomes the bespoke build we've been warning you about (see 4.10).

Standard ONIX is the happy path: title, contributors, descriptions, pricing, rights territories, subjects and assets map from your existing feed, and ongoing changes flow through on the same feed rather than a second data-entry burden. If you don't run ONIX, structured exports work. The design principle: your existing metadata operation should feed the direct channel automatically — a channel that demands parallel data entry gets abandoned by month three, and we'd rather engineer against that than exhort against it.

Your website connects during onboarding: orders flow to the reader's app library automatically, catalogue and pricing stay in sync, and your checkout remains exactly where your customers already trust it. Common platforms such as Shopify and WooCommerce use pre-built connectors; custom and legacy sites connect via API — common and custom integrations are all within reach. The point of integrating rather than replacing: you've already paid — in money and SEO and customer habit — for a working website; a platform that demands you abandon it is charging you twice.

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.

Reader and event data flows to your existing email/CRM stack, because the app should feed the marketing operation you already run, not compete with it. Minimum viable answer even without native connectors: full data export means your list lives wherever you work. The non-negotiable design principle: reader emails gathered by your app belong in your ESP, under your consent records — see 6.6.

You do — entirely, exportably, and under your own consent records. Readers who opt in to marketing did so under your privacy notice, to hear from you; we never email your readers for our purposes, never share them with other publishers, and never charge you to access your own list. This deserves a blunt answer because the market's default is the opposite: retailer channels give you no reader identities at all, and some platforms in this space treat your reader list as their asset with usage-based pricing for reaching it. The email list your channel builds may end up the single most valuable marketing asset your house owns; check any vendor's answer to this question against their data-export terms before believing it — including ours, which is why export is contractual (see 3.9).

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.

Two layers. In transit and at rest, content lives encrypted on the platform's infrastructure with access controlled per reader entitlement. At the reader's device, Readium LCP encrypts every delivered file with per-user licensing — a copied file is unreadable without its licence, which is revocable and expirable (that's also what makes lending/subscription mechanics enforceable — see 2.9). No DRM prevents determined piracy — anyone who claims otherwise is selling something — but LCP raises the effort above the casual-sharing threshold where nearly all leakage actually happens, without punishing legitimate readers with the account-and-authorisation rituals that made older DRM infamous. Review copies deserve special mention: access codes with expiring licences (see 5.6) close publishing's leakiest pipe — the emailed PDF.

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.