Security and compliance#

Key handling comes first and covers both APIs. The sections from what Povito holds to data retention describe Povito Checkout, which handles shoppers and payments. Vulnerability reports for either API go to one address.

Partner API keys#

• A key belongs to exactly one seller account and can never read another seller's data. There is no cross-seller or platform-wide key.
• The full key is shown once, at creation. Povito stores only an HMAC-SHA256 hash of the secret and compares in constant time, so nobody can read a key back; if you lose one, revoke it and create a new one.
• Grant only the scopes an integration needs — a nightly stock sync does not need catalog:write.
• test keys work only in the Sandbox and live keys only in Live, so a key leaked from a test setup cannot touch live data — see Keys and environments.
• Revoke keys in the Seller dashboard; revoking takes effect on the next request. Dashboard login tokens and Partner API keys are not interchangeable.

Checkout API keys#

• Secret keys (povito_ck_…) are server-side only. Never ship one in a browser, a mobile app, a public repository or a client-side config. If one leaks, ask Povito to revoke it; rotation issues a second key and both work until you revoke the old one, so there is no downtime.
• Publishable keys (povito_pk_…) can be public. They unlock only /v1/public/* for sessions of your merchant and mode, and every route there is also gated by the unguessable session code (26 base-32 characters, ~130 bits) and, for money-moving calls, by the shopper's phone-verified customer token.
• Scopes limit what a secret key can do; ask for the minimum set per integration — a fulfilment worker needs sessions:read and events:read, not refunds:write.
• An optional IP allowlist per key is available on request.

What Povito holds — and never sees#

Every admin and merchant mutation is written to an audit log with the actor, the action and the before/after state.

Card data and PCI DSS#

Povito Checkout operates at PCI DSS SAQ A. Card data is handled exclusively by PCI Level 1 providers on pages they serve; the hosted page redirects to them, and the Phase 2 drop-in embeds checkout.povito.com in an iframe that in turn redirects to or embeds the provider. checkout.povito.com runs with a Content Security Policy that forbids inline scripts and unknown frame ancestors, Subresource Integrity on every script, HSTS, Referrer-Policy: no-referrer and a Permissions-Policy that allows payment only for the checkout origin.

What that means for you: as long as you send shoppers to the hosted page (or embed the drop-in as documented) and never touch card data yourself, your own PCI obligation stays at SAQ A too — an annual self-assessment, no card data in your systems. Povito's SAQ A attestation and quarterly ASV scan results (L-11) are available to merchants on request.

Moving to native card fields in your own page would be SAQ A-EP or D for you and a separate decision for Povito; it is not on the roadmap.

Sessions and return URLs#

• Return hosts are allowlisted per merchant; an unlisted success_url is refused at create time, so a leaked key cannot redirect shoppers to a lookalike domain.
• The redirect to success_url carries only session_id and reference_id. Never fulfil from the return URL; GET the session.
• Gateway return handlers at checkout.povito.com/r/{attempt_id} ignore vendor query parameters for money purposes. A vendor callback is a hint; the vendor's own status API is the only source of "paid"; the captured amount must equal the presented amount — otherwise the attempt fails and an alert fires, never a partial success.
• Sessions expire (default 60 minutes, at most 24 hours); customer tokens are bound to one session and one phone.

Checkout webhooks#

• Outbound deliveries are signed (Povito-Signature, HMAC-SHA256 over the timestamp and raw body) with a per-endpoint secret; verify on the raw bytes with a constant-time compare and a five-minute window — see webhooks.
• Endpoints must be https:// on public addresses; private-network targets are refused to prevent Povito being used as a proxy into your network.
• Rotate the secret from the API; the old one is honoured for 24 hours.

Data retention#

A shopper's right-to-erasure request revokes saved instruments at the gateways first, then deletes the profile; transaction records stay, with the profile link severed. Data is held in Google Cloud, in the region documented in the privacy policy (L-06). The full schedule is L-13 in the document register.

Programme#

Threat model over the platform diagram (STRIDE); static analysis and dependency audit in CI; an external penetration test before live traffic and annually after; incident response and breach-notification procedure (L-12) with 72-hour notification to affected merchants; quarterly key-rotation drills.

Reporting a vulnerability#

Email security@povito.com. Include what you found, how to reproduce it, and how we can reach you. We acknowledge within 2 business days, keep you informed, and credit you if you wish. Please do not test against live merchants' sessions, other sellers' catalogs or other shoppers' data — Checkout test mode or the Partner API Sandbox, with your own keys, is the place for research. The vulnerability disclosure policy (L-20) that formalises safe-harbour terms is in review; until it is published, good-faith research reported to that address will not be pursued.