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

# Pay

> Agents pay anyone for anything with scoped virtual cards.

Pay is one concept — **Agentic Pay** — with two execution modes. Whichever mode runs, every transaction lands on a `transactions` row with `requireIntent` enforced and a full audit trail.

| Mode                                                 | When to use it                                                                                                                | Status                  |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ----------------------- |
| **MPP** ([Machine Payments Protocol](/concepts/mpp)) | Merchant returns `402 Payment Required` with `WWW-Authenticate: Payment`. JWE-wrapped network token, server-to-server settle. | Code-complete (Phase 7) |
| **CUA** ([Computer-Use Autofill](/concepts/cua))     | Merchant only has a browser checkout. Tokenized DPAN injected into form by a harness — never via the LLM context.             | Phase 8 (just shipped)  |

<Note>
  Both modes are sandbox-only today. Real merchant settlement is on the v1.3+ roadmap.
</Note>

## The shared lifecycle

<Steps>
  <Step title="Intent">
    Agent posts an intent. Policy engine and risk engine evaluate it. Result: `approved`, `pending_approval`, `denied`.
  </Step>

  <Step title="Credential">
    Either Ovra mints an MPP credential (JWE-wrapped) or a CUA autofill token (single-use, 30s TTL). Both bind the credential to the approved intent.
  </Step>

  <Step title="Execute">
    MPP: agent presents the credential to the merchant via `Authorization: Payment`. CUA: harness writes the DPAN into the form via CDP `Input.insertText` — the LLM only sees `{ status: "filled" }`.
  </Step>

  <Step title="Settle and audit">
    Transaction row written, ledger entries posted, webhooks fire (`mpp.transaction.completed`, `transaction.completed`), audit event lands.
  </Step>
</Steps>

## Choose the right surface

<CardGroup cols={2}>
  <Card title="REST" icon="code">
    `POST /intents` · `POST /v1/mpp/pay` · `POST /v1/cua/autofill-tokens`
  </Card>

  <Card title="SDK" icon="cube">
    `payments.payViaMpp(...)`, `payments.mintMppCredential(...)`
  </Card>

  <Card title="MCP" icon="terminal">
    `ovra_pay` (action: `checkout` | `handle_402` | `status` | `discover`)
  </Card>

  <Card title="Dashboard" icon="display">
    Pay is developer-driven; the dashboard shows transactions, decisions, audit. No "pay now" button.
  </Card>
</CardGroup>

## Quick example — MPP one-shot

The high-level orchestrator handles the 402 round-trip, mint, present, and verify in a single call:

```bash theme={}
curl -X POST https://api.getovra.com/v1/mpp/pay \
  -H "Authorization: Bearer $OVRA_AGENT_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "url": "https://shop.example.com/checkout/abc",
    "intentId": "int_...",
    "cardId": "ca_..."
  }'
```

Response (200):

```json theme={}
{
  "credential_id": "mppc_...",
  "merchant_status": 200,
  "receipt": "eyJ2ZXJzaW9uIjoiMSIs...",
  "merchant_body": { "order_id": "ord_42" }
}
```

## Quick example — CUA mint

```bash theme={}
curl -X POST https://api.getovra.com/v1/cua/autofill-tokens \
  -H "Authorization: Bearer $OVRA_AGENT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "intentId": "int_...",
    "cardId": "ca_...",
    "merchantOrigin": "https://shop.example.com",
    "amountCentsMax": 2999
  }'
```

Returns `{ aft_id: "aft_...", expires_at: "..." }`. Hand the `aft_id` to the harness — only the harness can redeem it via `X-CUA-Harness-Secret`.

## What Pay does *not* do

* **No direct merchant call from the LLM context.** PAN/CVV never enter the model. CUA enforces this at the harness boundary; MPP enforces it via JWE.
* **No live settlement.** Both modes use sandbox card data and simulated wallet effects. Live mode opens in v1.3+.
* **No wallet provisioning** for Apple Pay / Google Pay / Click-to-Pay yet (the rails exist via the network token service but are not surfaced as a product promise today).

## Sacred guarantees

* `requireIntent` is enforced at every checkpoint — `intent`, `grant`, `issue`, `redeem`, `checkout`.
* A money-moving POST without an `Idempotency-Key` is rejected with `E_IDEMPOTENCY_REQUIRED`.
* Single-use credentials enforce CAS consume — replay returns `402 invalid-challenge`, never an oracle.

## Next

<CardGroup cols={2}>
  <Card title="MPP deep-dive" icon="lock-keyhole" href="/concepts/mpp">
    402 challenge format, JWE wrapping, mint + verify endpoints.
  </Card>

  <Card title="CUA deep-dive" icon="browser" href="/concepts/cua">
    Autofill token TTL, harness boundary, Trusted Agent Protocol prep.
  </Card>

  <Card title="Intents" icon="file-signature" href="/concepts/intents">
    The approval primitive every payment depends on.
  </Card>

  <Card title="Cards" icon="rectangle" href="/concepts/cards">
    Multi-card per agent, freeze, rotate, network tokens.
  </Card>
</CardGroup>