Рельсы-адаптеры

Stipendex не проводит расчёты сам — их исполняют существующие платёжные системы через адаптеры. Протокол фиксирует интерфейс адаптера и формат evidence в Proof; всё остальное (лицензии, KYC, конверсия, антифрод) — зона рельса.

Интерфейс адаптера (в кошельке)

RailAdapter {
  scheme: string                       // "account" | "stripe-mpp" | "stripe-connect" | "x402" | …
  pay(quote, railParams)      → evidence          // service: capture сразу
  hold(quote, railParams)     → evidence          // checkout: предавторизация estimate+tolerance
  capture(evidence, amountFinal) → evidence'      // checkout: списание ≤ холда
  void(evidence)              → void              // отмена холда без списания
  refund(evidence, amount)    → evidence'         // расширение
}

На стороне получателя симметрично: verify(proof) → ok | invalid (локально или запросом к фасилитатору/сети).

account — счёт у фасилитатора (дефолт «из коробки»)

Prepaid-ledger у hosted-оператора. Цель — нулевой порог входа: разработчик не трогает ни карты, ни крипту, ни регуляторику.

• Принципал пополняет счёт привычным способом (карта/инвойс); кошелёк получает scoped-токен на списания в пределах мандата.
• pay = подписанная фасилитатором проводка ledger; evidence = JWS фасилитатора.
• Верификация получателем = один запрос к фасилитатору (или проверка подписи фасилитатора офлайн, если получатель ему доверяет).
• Tab-сессии settle'ятся внутри ledger бесплатно — микроплатежи не несут сетевых комиссий вообще. Механически tab — платёжный канал: открытие холдирует cap (один вызов), каждый платёж — офлайн-инкремент с подписью кошелька, который получатель проверяет локально, а расчёт — закрытие канала: получатель предъявляет ПОСЛЕДНИЙ инкремент-proof, обёрнутый в settlement С ПОДПИСЬЮ ПОЛУЧАТЕЛЯ (ключ получателя пиннится при открытии — иначе плательщик, владеющий всеми инкрементами, мог бы закрыть канал ранним маленьким claim'ом), получает его running total, остаток холда возвращается на счёт. Невостребованный холд возвращается целиком после TTL tab'а (закрывайте до истечения).
• Деньги держит лицензированный оператор; кошелёк и SDK средств не касаются (граница money-transmission).

Фасилитатор дополнительно даёт: pending-очередь HITL, velocity-антифрод, revocation мандатов, выплаты получателям (по расписанию/порогу).

stripe-mpp — фиатные machine-платежи

Мост в Stripe Machine Payments Protocol: сессионная агрегированная тарификация на фиатных рельсах. Естественный выбор для получателей, уже живущих в Stripe. evidence = идентификатор MPP-сессии/чарджа; tab-сессии Stipendex мапятся на MPP-сессии почти один в один.

stripe-connect — checkout-профиль

Рельс товарных покупок (модель 4agents order-flow v2.1, решение D1):

• hold = PaymentIntent с capture_method=manual на estimate + tolerance;
• capture(amountFinal) = частичный capture подтверждённой суммы (≤ холда);
• split получателю/платформе = direct charges или destination charges с on_behalf_of + application fee — комиссия платформы удерживается атомарно, а продавец остаётся merchant of record. Голые destination charges без on_behalf_of делают MoR платформу — это мисконфигурация для данного профиля;
• void = отмена intent'а без списания;
• платформа MUST оставаться вне владения/контроля средств во всех потоках — включая возвраты, споры и холды manual capture; деньги лежат у лицензированного PSP. Именно это удерживает платформу вне лицензирования money transmitter.

Налоги, резервы, выплаты, MoR — конфигурация платформы-оркестратора поверх Connect, вне Stipendex (см. checkout-profile.md).

x402 — крипто per-call

Для полной автономии и получателей без банковской обвязки:

• pay = перевод стейблкоина (USDC) по параметрам из quote.rails[] (network, asset, to); evidence = tx-hash + подписанный payload.
• Верификация — фасилитатором x402 или самим получателем по цепочке.
• hold/capture в базовом x402 отсутствуют → рельс не подходит для checkout-профиля (только amount, режим capture).

Совместимость сознательная: Stipendex-Quote несёт те же поля схемы, что и x402 paymentRequirements, чтобы получатель с готовым x402-стеком подключался переименованием полей, а не переписыванием.

Выбор рельса кошельком

1. Пересечение quote.rails[] с настроенными адаптерами.
2. Приоритет из конфигурации кошелька (по умолчанию: account → stripe-* → x402).
3. Пусто → denied(no_common_rail) — агент может сообщить получателю/принципалу.

Требования к любому рельсу (нормативные)

• R1. evidence проверяем третьей стороной (подпись/цепочка/API) — «честное слово кошелька» доказательством не является.
• R2. Идемпотентность: повторный pay/capture с теми же входами не создаёт второго движения денег.
• R3. capture ≤ hold всегда; рельс, не умеющий частичный capture, не заявляет поддержку checkout-профиля.
• R4. Ошибки рельса возвращаются кошельку машиночитаемо; кошелёк не ретраит вслепую операции с деньгами (ретраи — только идемпотентные).