> ## 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.

# Checkout runtime

> How agents orchestrate payment execution at the merchant.

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.

| Component                                   | Owner                         |
| ------------------------------------------- | ----------------------------- |
| Merchant API or checkout form               | Merchant                      |
| Card credentials (DPAN, cryptogram, expiry) | Ovra (server-side, encrypted) |
| Payment execution                           | Your 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](/concepts/mpp):

<Steps>
  <Step title="Intent approved">
    Standard intent flow with `expectedMerchant` set.
  </Step>

  <Step title="Mint credential">
    `POST /v1/mpp/credentials/mint` (or `POST /v1/mpp/pay` for one-shot).
  </Step>

  <Step title="Present">
    Merchant call with `Authorization: Payment <cred>`.
  </Step>

  <Step title="Verify">
    Merchant calls `POST /v1/mpp/credentials/:id/verify` with their merchant key.
  </Step>
</Steps>

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](/concepts/cua)):

<Steps>
  <Step title="Intent approved">
    Standard intent flow with `expectedAmountEuros`.
  </Step>

  <Step title="Mint autofill token">
    `POST /v1/cua/autofill-tokens` returns `aft_*` (30s TTL, single-use, intent + card + merchant origin + amount cap).
  </Step>

  <Step title="Hand off to harness">
    Pass `aft_id` to your CUA harness over your own internal channel — not the LLM context.
  </Step>

  <Step title="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`.
  </Step>

  <Step title="LLM clicks submit">
    LLM only sees `{ status: "filled", masked_last4: "1234" }`. Merchant settles.
  </Step>
</Steps>

## Runtime 3 — direct API execute (legacy)

For server-to-server flows where Ovra is the gateway:

```bash theme={}
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

| Layer              | Protection                                         |
| ------------------ | -------------------------------------------------- |
| Intent FSM         | `requireIntent` enforced; expired intents rejected |
| Grant TTL          | Configurable, default 5 min                        |
| Credential TTL     | Configurable, default 5 min, 24h max               |
| MPP credential     | JWE-wrapped, single-use CAS consume                |
| CUA autofill token | `X-CUA-Harness-Secret`-gated, 30s TTL, one-shot    |
| DPAN               | Network token, not the FPAN                        |
| Cryptogram         | Single-use CAVV — bound to the transaction         |
| Policy engine      | Re-evaluated at every checkpoint                   |
| Idempotency        | Required on every money-moving POST                |

## Choosing a runtime

| Situation                                        | Runtime            |
| ------------------------------------------------ | ------------------ |
| Merchant returns `WWW-Authenticate: Payment` 402 | **MPP**            |
| Merchant only has a checkout form                | **CUA**            |
| Server-to-server, you control both ends          | Direct API execute |

## Next

<CardGroup cols={2}>
  <Card title="MPP" icon="lock-keyhole" href="/concepts/mpp">
    Wire flow, error matrix, merchant onboarding.
  </Card>

  <Card title="CUA" icon="browser" href="/concepts/cua">
    Threat model, harness boundary, JWKS prep.
  </Card>

  <Card title="Pay" icon="credit-card" href="/concepts/pay">
    The Pay pillar overview.
  </Card>
</CardGroup>