Served designs

A paywall or onboarding flow written in HTML, published from the dashboard, rendered in a hardened webview — the way a brand-new design reaches installed apps.

A served design is raw HTML/CSS/JS stored as the surface's config (template: "webview"). The SDK renders it in react-native-webview and injects a bridge, window.__FICTURA__, before the page's own scripts run. Devices pick a newly published design up on their next config refresh — no release.

The paywall bridge

packages

array

Live store packages — {id, product_id, price_string, period, trial_days…}. Prices are never baked into the HTML; they're injected at runtime from the store adapter.

purchase(id)

function

Runs the native store purchase for a package. Buying never happens inside the page.

openWebCheckout(id)

function

Hands off to web checkout when it's available; webCheckoutAvailable says so.

restore()

function

Restores purchases through the adapter.

close()

function

Dismisses the paywall.

track(event, properties)

function

Logs an event, namespaced paywall_web_<event> so a design can't forge funnel metrics.

Hardened by construction

Only about:blank and data: loads are allowed — a served design cannot navigate to the open web.
DOM storage and file access are off; new windows are blocked.
If react-native-webview isn't installed, the SDK shows a graceful fallback with a working Close.

Served onboarding

Onboarding has the same mechanism (config template: "webview") with a flow-shaped bridge: window.__FICTURA__.answer(step, value) records an answer, complete(answers) finishes the flow, and track() is namespaced onboarding_web_<event>. Publish from Dashboard → Onboarding → the custom-HTML editor.

Served designs and native templates share everything else: placements, experiments, automatic funnel events, and the web-checkout-first buy path.

The paywall bridge

Served onboarding

On this page