# Purchase commitment

The record that connects an exact purchase to its terms and refund path.

## Bind the terms before payment

The intended protocol uses an immutable, versioned commitment accepted before payment. The current JSON is a schema example only; its `signature` is `null` and `verification_status` is `unsigned_fixture`.

## Field reference

| Field | Meaning in the fixture |
| --- | --- |
| `purchase_id` / `order_id` | Exact purchase and merchant order references. |
| `merchant_id` | Fictional enrolled merchant. Not a verified identity. |
| `amount_units` / `asset_decimals` | 100 integer DEMO units with zero decimals. Do not use floating-point money. |
| `asset` / `network` | DEMO and simulation-only. No live token or chain. |
| `payment_destination` | Destination for the original payment. |
| `refund_beneficiary` | Explicit recipient of a refund, fixed in the terms. |
| `collection_source` | Enrolled source allowed to fund the refund. |
| `policy_version` / `maximum_refund_units` | Accepted policy version and cumulative purchase cap. |
| `claim_window_seconds` | 604800 seconds, starting at confirmed settlement. |
| `delivery_due_seconds_after_settlement` | 86400 seconds after confirmed settlement. |
| `covered_failure` / `evidence_rules` | Covered reason and evidence that the decision authority evaluates. |
| `decision_authority` | Reviewer permitted by the accepted policy. |
| `partial_collection_allowed` | Whether available funds may pay part of the award. |
| `offer_expires_at` / `nonce` | Illustrative acceptance deadline and replay-prevention material. |
| `guarantee` | Null. No explicit funded guarantee. |

## Complete example

### purchase.json · unsigned fixture

```json
{
  "schema_version": "0.1.0",
  "mode": "simulation",
  "purchase_id": "DEMO-1087",
  "merchant_id": "demo-atlas-api",
  "order_id": "export-1087",
  "asset": "DEMO",
  "network": "simulation-only",
  "amount_units": 100,
  "asset_decimals": 0,
  "payment_destination": "demo-merchant-001",
  "refund_beneficiary": "demo-buyer-001",
  "collection_source": "demo-reserve-001",
  "policy_version": "demo-v1",
  "maximum_refund_units": 100,
  "claim_window_seconds": 604800,
  "claim_window_starts_at": "confirmed_settlement",
  "delivery_due_seconds_after_settlement": 86400,
  "covered_failure": "export_not_delivered_by_deadline",
  "evidence_rules": [
    "fictional_service_receipt",
    "fictional_independent_delivery_log"
  ],
  "decision_authority": "demo-reviewer",
  "partial_collection_allowed": true,
  "guarantee": null,
  "offer_expires_at": "2026-10-31T00:00:00Z",
  "nonce": "fictional-1087",
  "signature": null,
  "verification_status": "unsigned_fixture"
}
```

## What a verifier must establish

- Authentic merchant enrollment and signing/configuration authority.
- The exact policy, purchase, amount, asset/network, beneficiary and collection-source binding.
- Attributable acceptance before expiry and unambiguous subsequent settlement.
- Historical policy/key versions, cumulative limits and replay protection.

These are requirements for a future implementation, not checks performed by the static example. The simulator also does not enforce the illustrative offer expiry against the wall clock.

Download the [JSON Schema](schemas/purchase.json) or [raw example](examples/purchase.json). Schema conformance alone cannot establish authenticity, funding or enforceability.