Phase: Phase 2 — coming

Embedded checkout#

What "embedded" means at Povito#

The drop-in mounts checkout.povito.com in an iframe inside your page. Card numbers are never typed into a Povito-controlled DOM, let alone yours: inside that frame, card methods redirect to or embed the PCI Level 1 provider's own page. That is what keeps you at PCI SAQ A — see security. It also means the drop-in cannot offer "native" card fields, arbitrary CSS, or a way to read what the shopper types.

The session is still created on your server with your secret key. The browser only ever holds a publishable key (povito_pk_…) and the session code.

Planned JavaScript API#

<script src="https://checkout.povito.com/js/v1/checkout.js" async></script>

const checkout = PovitoCheckout.mount({
  publishableKey: "povito_pk_live_…",
  sessionCode: session.code, // from your server's POST /checkout/sessions
  el: document.querySelector("#checkout"),
  locale: "ar",
})

checkout.on("complete", ({ sessionId, referenceId }) => {
  // Same rule as the hosted page: verify server-side, then fulfil.
  window.location.assign(`/checkout/return?session_id=${sessionId}&reference_id=${referenceId}`)
})
checkout.on("cancel", () => checkout.unmount())
checkout.on("error", ({ code }) => showRetry(code))

// The same as sending the shopper to session.url yourself.
PovitoCheckout.redirectToCheckout({ sessionCode: session.code })

Events the frame will post to the parent, all without money: ready, resize (height), complete (sessionId, referenceId), cancel, error (code). The parent never receives the amount, the phone or the method — read those from GET /checkout/sessions/{id} on your server.

Styling limits#

You control the container's width and position. The frame controls everything inside it: Povito's palette with your merchant accent, your logo and display name, the locale. There is no CSS injection and no theming API beyond the accent Povito sets on your merchant record. Height is reported through the resize event so the frame can be inlined without scrollbars.

Content Security Policy#

Your page will need frame-src https://checkout.povito.com and script-src https://checkout.povito.com. The frame sets frame-ancestors to your registered return hosts; it refuses to load anywhere else, which is why those hosts must be registered before you embed.

Planned Flutter package#

povito_checkout opens the hosted page in a hardened in-app browser — Custom Tabs on Android, SFSafariViewController on iOS, never a WebView — and returns to the app through the povito://checkout/return scheme.

final result = await PovitoCheckout.present(
  sessionUrl: session.url,           // from your server
  returnScheme: 'povito://checkout/return',
);
// result.sessionId, result.referenceId — then verify on your server

While the shopper is in the browser the package polls GET /public/attempts/{attempt_id} with your publishable key — the attempt lookup that needs no session code, built for return pages opened in a different browser — so a completed payment closes the browser even if the vendor's redirect never arrives.

The public surface it uses#

Both clients speak to /v1/public/* with a publishable key and the session code; those routes exist today and are what the hosted page itself uses. They are documented in the API reference so you can see exactly what a client can and cannot do — notably GET /public/sessions/{code} never returns metadata or anything about other sessions.