Skip to main content
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. 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:
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

​
Choosing a runtime

​
Next

MPP

Wire flow, error matrix, merchant onboarding.

CUA

Threat model, harness boundary, JWKS prep.

Pay

The Pay pillar overview.