Make XGuard the universal Pay-All checkout for multi-merchant payments

[moelayyan90]

Primary product direction

XGuard becomes a universal multi-merchant payment cart rather than only a settlement-truth / retry layer.

User-facing invariant:

Add payments -> Review once -> Approve once -> XGuard pays everyone.

The payer can collect multiple independent Payment Claims from merchants, services, agents, invoices, or rails, review one combined checkout, authorize once, and receive one parent receipt with child settlement results.

New artifacts

• docs/UNIVERSAL_MULTI_MERCHANT_CHECKOUT.md
• specs/batch-payment-intent.schema.json
• packages/core/src/batch-payment.ts

packages/core/src/index.ts now exports the batch-payment contract.

Execution modes

1. ATOMIC_ONCHAIN — best first wedge for stablecoins / agentic payments. One batch authorization binds recipients, amounts, fees, expiry, nonce, and the claim-set commitment; a compatible batch router / signature-transfer path executes the allocations.
2. PLATFORM_SPLIT — for regulated PSP / marketplace rails that already support multi-seller or split settlement. XGuard supplies the allocation plan; the licensed PSP moves fiat funds.
3. COORDINATED_CHILD_PAYMENTS — one approval UX authorizes a bounded set of underlying payments when unrelated rails cannot legally or technically share one native transaction. The receipt must disclose each child transaction.

Atomicity policies are explicit: ALL_OR_NOTHING, BEST_EFFORT, or GROUP_ATOMIC.

Payment Claim

Each merchant/service exposes or has its platform translate an authenticated claim containing beneficiary, amount, currency/asset, destination rail, invoice/order/resource reference, expiry, and provider/merchant evidence.

The adoption loop is:

If you want to be included in the Pay-All checkout, expose an XGuard-compatible Payment Claim.

Existing safety primitives

Settlement Truth and retry protection remain supporting infrastructure for child-payment correctness and receipts, but they are no longer the primary product story.

Commercial model

Pricing remains rail-specific and may include a disclosed payer batch convenience fee, platform/rail usage fee, per-child settlement fee, volume tiers, or contractually supported revenue share. XGuard must not silently divert merchant proceeds.

Truthfulness / legal boundary

XGuard does not claim that unrelated independent card merchants can be collapsed into one native card-acquiring transaction without a licensed marketplace / merchant-of-record / payment platform that supports that model. Where that boundary is unavailable, XGuard either uses explicit coordinated child payments under a valid user mandate or does not support that combination.

Goal

Make XGuard the common Pay-All / batch-authorization layer between payable claims and heterogeneous payment rails.