Tax, Legal & Compliance

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.

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.

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.