REAPP — Agentic Payment Protocol for Stellar

What AP2 Solves

Launched September 2025 with 60+ institutional partners including Mastercard, PayPal, Coinbase, and Shopify, AP2 addresses the core authorization problem in agentic commerce: how does a payment network know that a human actually authorized an AI agent to make a specific purchase?

AP2's answer is the mandate — a tamper-proof, cryptographically signed digital contract used with W3C Verifiable Digital Credentials to carry user intent and authorization into payment execution and dispute evidence. Every payment has a cryptographic paper trail from user intent all the way to on-chain settlement. Disputes, compliance, liability — all answerable from the chain.

The Three Mandate Types

The three-tier structure is the core of how users express what agents are allowed to do — and how that authorization flows through to settlement.

AP2 Mandate Type Hierarchy

IntentMandates and CartMandates both derive a PaymentMandate presented to the payment network. The mandate_chain_hash links all three tiers for dispute resolution.

IntentMandateAutonomous / Human-Not-Present

I trust you to buy this category of thing

→User delegates broad purchasing authority upfront
→Defines merchant list, SKU categories, max spend, expiry
→Signed once with hardware-backed key (biometric)
→Agent operates autonomously within bounds until expiry
→Example: "spend up to $10/day on data APIs for 30 days"

CartMandateHuman-Present / Explicit

I approve this specific purchase

→Human is present and reviewing a specific transaction
→Merchant signs first — guaranteeing delivery at stated price
→User signs second to explicitly approve
→Cryptographic equivalent of traditional checkout confirmation
→Example: "yes, buy this specific $47 report from this vendor"

PaymentMandateDerived / Network-Facing

The network-facing credential

→Derived from either IntentMandate or CartMandate
→Presented to the payment network for settlement
→Includes ai_agent_present: boolean flag for compliance
→Contains mandate_chain_hash linking to original mandate
→Enables full audit trail from user intent to on-chain settlement

The Full Authorization Chain

AP2 Authorization Flow with REAPP Validator

From user biometric authentication through mandate validation to Soroban contract enforcement. The agent never touches the user's private key.

Mandate-to-Receipt Audit Linkage

A critical design decision is how AP2 mandate hashes link to Stellar settlement receipts. REAPP implements this atomically:

The Soroban registry maintains persistent state keyed by (mandate_hash → tx_hash) for every settled payment
Upon settlement, x402stellar returns an X-PAYMENT-RESPONSE header containing the Stellar transaction ID, payer address, and network confirmation
The SDK calls validate_and_consume() with both the mandate hash and tx hash, writing the linkage atomically to registry storage
Verifiers reconstruct the full audit chain: mandate_id → mandate_hash → tx_hash → Stellar ledger record

AP2 Dispute Evidence Chain

Every REAPP payment produces an immutable on-chain evidence chain. The atomic write to Soroban ensures mandate hash and settlement tx hash are always linked.

The Standards War — Honest Assessment

The proposal is, to be direct, betting on AP2 winning the agentic payments standard war. OpenAI and Stripe launched ACP in February 2026 going in a completely different direction — traditional payment rails, shared payment tokens, no blockchain path. The market has not picked a winner yet.

REAPP's mitigation is the adapter-first validator architecture: AP2 is abstracted behind a versioned interface, so the authorization standard can theoretically be swapped without rewriting the SDK. But that's an execution dependency, not a guarantee.

AP2 vs ACP — Standards Landscape

AP2 and ACP are diverging in architecture. AP2 targets cryptographic mandate chains and blockchain settlement. ACP targets traditional payment rails. REAPP's adapter layer is designed to absorb this uncertainty.

AP2 Dependency Risk Matrix

Google abandonment is low probability but existential impact. Breaking changes and the Android-first UX ceiling are the most likely near-term risks to materialize.

AP2 Risk Factors — Full Breakdown

AP2 spec volatilityHigh likelihood

AP2 is at v0.1. The AP2-compatible x402 extension is explicitly marked 'coming soon' in Google's own sample repository. Interface changes are likely before stability.

Mitigation:Abstract AP2 behind versioned adapter interface. Pin schema versions. Ship conformance test suite that catches upstream changes automatically via CI.

Google abandonmentLow likelihood, critical impact

Google has a documented history of killing products. If AP2 gets deprioritized or pivoted, REAPP's authorization layer loses its primary standard. This is existential if the adapter layer isn't clean.

Mitigation:Adapter-first architecture means the authorization standard can be swapped. Monitor AP2 adoption velocity. ACP adapter is a contingency deliverable if needed.

ACP wins the standard warMedium likelihood, high impact

OpenAI + Stripe ACP launched Feb 2026 targeting traditional payment rails. If enterprise adopts ACP over AP2, the mandate authorization layer needs to be rebuilt for a different credential model.

Mitigation:The x402 settlement layer and Soroban enforcement survive regardless of which authorization standard wins. Only the validator and mandate types need to change.

Android-first UX ceilingHigh likelihood, medium impact

Hardware-backed key signing in AP2 v0.1 is Android Digital Payment Credential first. iOS and desktop coverage is limited. Freighter Mobile does not support x402. This is a real UX ceiling for consumer-facing use cases.