Checkout-профиль: покупка товаров

Профиль Stipendex для сценария «агент покупает товар для человека». Платёжная механика — прямое воплощение модели 4agents order-flow v2.1 (hold на оценку+допуск, «ACCEPT — источник истины по сумме», capture ≤ hold), выраженное объектами Stipendex.

Разделение зон: Stipendex покрывает полномочия и движение денег; торговую оркестрацию (корзина, резервы стока, доставка, споры, MoR, фискализация) ведёт платформа-оркестратор — например, 4agents. Граница описана внизу.

Отличия от service-профиля

Поток

Агент/хост         Кошелёк               Платформа (4agents)          Рельс (Connect)
  │ get_quote ─────────────────────────────▶│ (резерв стока, оценка
  │ ◀── Quote{estimate+tolerance, TTL 15м} ─│  доставки — её зона)
  │──Quote──▶│ мандат: allowlist+лимиты     │
  │          │ HITL: итог+допуск ──────────▶ принципал
  │          │ ◀─ Confirmation (approve) ───
  │          │ hold(estimate+tol) ─────────────────────────────────────▶│
  │          │◀──────── Proof{mode:hold} ────────────────────────────────│
  │ place_order + Proof ────────────────────▶│ Receipt{held}
  │                                          │ … продавец ACCEPT:
  │                                          │ подтверждает цену/сток/итог
  │                                          │ capture(amount_final ≤ hold)──▶│ split
  │ ◀──────── Receipt{captured, amount_final, order_id} ────────────────────│
  │
  │  DECLINE / таймаут / итог вне допуска:
  │ ◀──────── Receipt{voided} ── void холда, деньги не двигались ───────────│

Нормативные правила

• C1. Confirmation обязателен до hold; в подтверждении принципалу показывается итог, допуск и состав заказа. SHOULD: principal_assertion (passkey) — сильное доказательство акцепта (см. mandate-wallet.md).
• C2. capture только после явного ACCEPT продавца и только подтверждённой суммы; amount_final ≤ estimate + tolerance — иначе MUST void + re-quote + новое подтверждение. Никаких incremental auth сверх допуска.
• C3. Тайминги: TTL Quote (и мягкого резерва) ≈ 15 мин; ACCEPT-окно ≪ срока жизни холда (часы, hard-cap; дальше auto-void). Числа — конфигурация платформы, Stipendex требует лишь ACCEPT-окно < hold-TTL с запасом.
• C4. Мульти-продавец: Quote и суб-платёж — per-получатель; частичный ACCEPT = capture принятых суб-заказов, void остальных; повторное подтверждение принципала при изменении итога сверх допуска.
• C5. Отмена принципалом до ACCEPT → void без потерь. После capture — возврат (refund) по политике платформы, вне happy path Stipendex.
• C6. Конфигурация рельса MUST сохранять продавца как merchant of record (direct charges или destination charges с on_behalf_of), а платформу — вне владения/контроля средств во всех потоках, включая возвраты и споры (см. rails.md).

Цепочка доказательств для споров

К моменту спора/чарджбэка платформа может предъявить полную машиночитаемую цепочку:

Mandate (подпись принципала: лимиты, срок, назначение)
  → Confirmation (подпись + passkey: «согласен на итог $92.40 ± $8.40», timestamp, канал)
    → Quote (подпись продавца: состав, оценка, допуск)
      → Proof{hold} → Proof{capture(amount_final)}
        → Receipt{captured, order_id}

Это закрывает главный юридический риск агентных покупок («а был ли акцепт?», H5 из анализа 4agents): согласие человека на конкретную сумму зафиксировано криптографически, а не «репликой в чате».

Граница Stipendex ↔ платформа-оркестратор

Платформа видит от Stipendex только: Proof/Confirmation-ссылки и Receipt'ы. Лимиты и allowlist принципала ей не раскрываются.