Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.getovra.com/llms.txt

Use this file to discover all available pages before exploring further.

The checkout runtime defines who does what during a payment. Ovra always issues credentials. The merchant always settles via its own acquirer. Your agent picks one of three runtimes to bridge them.
ComponentOwner
Merchant API or checkout formMerchant
Card credentials (DPAN, cryptogram, expiry)Ovra (server-side, encrypted)
Payment executionYour agent runtime
PAN and CVV never enter the agent’s context in any runtime — the credential boundary is enforced by JWE wrapping (MPP) or the harness boundary (CUA).

​
Runtime 1 — MPP

For merchants that speak MPP:
1

Intent approved

Standard intent flow with expectedMerchant set.
2

Mint credential

POST /v1/mpp/credentials/mint (or POST /v1/mpp/pay for one-shot).
3

Present

Merchant call with Authorization: Payment <cred>.
4

Verify

Merchant calls POST /v1/mpp/credentials/:id/verify with their merchant key.
Server-to-server. No browser. Settlement happens at the merchant’s acquirer; Ovra writes the transactions row on verify.

​
Runtime 2 — CUA

For merchants that only have a checkout form (CUA):
1

Intent approved

Standard intent flow with expectedAmountEuros.
2

Mint autofill token

POST /v1/cua/autofill-tokens returns aft_* (30s TTL, single-use, intent + card + merchant origin + amount cap).
3

Hand off to harness

Pass aft_id to your CUA harness over your own internal channel — not the LLM context.
4

Harness redeems + fills

Harness calls GET /v1/cua/autofill-tokens/:id/redeem with X-CUA-Harness-Secret, gets DPAN, fills the form via CDP Input.insertText.
5

LLM clicks submit

LLM only sees { status: "filled", masked_last4: "1234" }. Merchant settles.

​
Runtime 3 — direct API execute (legacy)

For server-to-server flows where Ovra is the gateway: 
curl -X POST https://api.getovra.com/checkout/execute \
  -H "Authorization: Bearer $OVRA_AGENT_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "intentId": "int_...",
    "targetUrl": "https://api.merchant.com/charge"
  }'
targetUrl must be HTTPS and SSRF-safe. Ovra resolves credentials, executes the merchant call via the PCI-proxy Forward Pull, returns the result.

​
Security layers

LayerProtection
Intent FSMrequireIntent enforced; expired intents rejected
Grant TTLConfigurable, default 5 min
Credential TTLConfigurable, default 5 min, 24h max
MPP credentialJWE-wrapped, single-use CAS consume
CUA autofill tokenX-CUA-Harness-Secret-gated, 30s TTL, one-shot
DPANNetwork token, not the FPAN
CryptogramSingle-use CAVV — bound to the transaction
Policy engineRe-evaluated at every checkpoint
IdempotencyRequired on every money-moving POST

​
Choosing a runtime

SituationRuntime
Merchant returns WWW-Authenticate: Payment 402MPP
Merchant only has a checkout formCUA
Server-to-server, you control both endsDirect API execute

​
Next

MPP

Wire flow, error matrix, merchant onboarding.

CUA

Threat model, harness boundary, JWKS prep.

Pay

The Pay pillar overview.