The core idea
An app or agent never holds a real card number. Instead it works with permission to spend and, at the moment of purchase, a one-time credential that only works for that exact purchase.The lifecycle
1
A purchase is proposed
An app creates a session for a specific order, or an agent creates a payment for a known
merchant and total. The amount and merchant are pinned up front.
2
The card is collected securely
The cardholder enters their card in Prava’s secure surface: an embedded iframe (SDK) or a hosted
page (Prava Pay). The raw card number never reaches the app, the agent, or their servers.
3
The owner's rules are applied
Prava checks the purchase against the account’s guardrails (spending limits, approvals, saved
addresses) before anything is charged. See Guardrails.
4
A one-time credential is issued
Prava returns credentials scoped to that single purchase: locked to the merchant, the amount, and a
short time window. They can’t be reused or repurposed.
5
Checkout completes
The credential is used at the merchant’s checkout to complete the payment. The outcome is confirmed
from the payment itself, so the status you get back is the real one.
Why it’s safe by design
No raw card exposure
The card is entered in Prava’s secure surface and tokenized (the number is replaced with a secure
stand-in). Apps and agents never see it.
Scoped credentials
What the caller receives works for one purchase: right merchant, right amount, short-lived.
Owner-set guardrails
Spending limits and approvals are enforced by Prava on every purchase, not by the caller.
No silent double-charge
If an outcome is ever uncertain, Prava declines to guess rather than risk charging twice.
Three ways to integrate
The same lifecycle powers all three integration paths:
Not sure which to pick? See Choosing Your Integration. For the money-side
details (mandates, credential scoping, and status), see Payments. For the
controls an owner sets, see Guardrails.