SwarmSync.AI

benstone@swarmsync.ai

Applications Individual Submission agent payments AP2 VCAP escrow This document specifies how the Verified Commerce for Agent Protocols (VCAP) settlement layer binds to the Agent Payments Protocol (AP2) developed by Google and its coalition partners. AP2 defines payment intents, mandates, and verifiable digital credentials (VDCs) for agent-initiated transactions. VCAP defines escrow state machines, verification callbacks, and cryptographic proof bindings for verified delivery settlement. AP2's `PaymentIntent` supports `captureType: "escrow_release"` with `releaseCondition: "delivery-confirmation"`, but the AP2 specification does not define what constitutes a delivery confirmation, how it is cryptographically verified, or how the verification result triggers fund capture. This binding document fills that gap.

AP2 v0.1 defines the following in its PaymentIntent.terms object:

json

The AP2 specification defines the lifecycle states of a PaymentIntent:

Where: authorized = funds are reserved/escrowed captured = settlement rail moves funds to seller settled = both parties receive notarized receipts However, AP2 does not specify: What triggers the authorized → captured transition when captureType is escrow_release What format delivery-confirmation takes — is it a boolean? A signed attestation? A proof bundle? Who performs the verification — the buyer agent, a third-party verifier, or the marketplace? What happens on timeout — if delivery is neither confirmed nor denied within the disputeWindow How the verification result is cryptographically bound to the specific PaymentIntent VCAP answers all five questions.

When an AP2 PaymentIntent transitions to authorized with captureType: "escrow_release", the marketplace MUST create a corresponding VCAP escrow_hold.

AP2's mandate system (Intent Mandate, Cart Mandate, Payment Mandate) maps to VCAP's negotiation phase:

The VCAP verification_callback triggers AP2 state transitions:

AP2's PaymentIntent.evidence array is extensible. VCAP adds a new evidence type:

json

This evidence entry: Provides the cryptographic binding (proof_hash + proof_signature) that AP2's delivery-confirmation requires but does not define Is verifiable independently of the marketplace (any party with the proof bundle can recompute the hash) Links the AP2 payment to the VCAP verification via verification_id

When a PaymentIntent specifies releaseCondition: "delivery-confirmation", the VCAP binding defines delivery confirmation as: > A verification_callback message (per VCAP Section 3.6) where passed = true, containing a valid proof_hash and proof_signature that can be independently verified against the shared secret between the marketplace and verifier.

A delivery is confirmed when ALL of the following are true: A VCAP verification_request was dispatched for the PaymentIntent's escrow A VCAP verification_callback was received with passed: true The proof_hash matches the SHA-256 of the canonical proof bundle The proof_signature matches the HMAC-SHA256 of the proof body The verification_id in the callback matches the dispatched request 6. The callback was received within the disputeWindow period

A delivery is rejected when ANY of the following are true: A VCAP verification_callback was received with passed: false The proof signature fails verification (tampered or forged) The verification timed out AND manual review determined non-delivery

json

json

json

AP2's participant objects can include ATEP trust data:

json

Based on ATEP trust tier, the escrow parameters MAY be adjusted:

To add VCAP settlement support to an existing AP2 implementation: Detect escrow PaymentIntents: Check for terms.captureType === "escrow_release" and terms.releaseCondition === "delivery-confirmation" Create VCAP escrow on authorization: When PaymentIntent reaches authorized, create a VCAP escrow_hold with the field mappings from Section 3.1 Accept delivery with verification hints: When the seller agent submits delivery, extract verification_hints and dispatch a VCAP verification_request Process verification callback: On VCAP verification_callback, transition the PaymentIntent per Section 3.3 Append VCAP evidence: Add the vcap.verification_proof evidence entry per Section 3.4 6. Handle timeout: If no callback within timeout_seconds, follow Section 4.3

To add AP2 compatibility to an existing VCAP implementation: Accept AP2 PaymentIntent metadata: Store ap2_payment_intent_id in escrow metadata Emit AP2 webhook events: Emit the events from Section 5 alongside VCAP state transitions Support AP2 evidence format: Include vcap.verification_proof in AP2-compatible evidence arrays Respect AP2 dispute window: Use PaymentIntent.terms.disputeWindow as the VCAP timeout

The VCAP proof hash and signature MUST be computed independently of AP2's VDC signatures. This creates a dual-signature settlement: AP2's VDC signature proves the buyer authorized the payment VCAP's proof signature proves the delivery was independently verified Both must be valid for settlement to proceed.

The VCAP verifier MUST NOT exceed the scope defined in the AP2 Intent Mandate. If the mandate specifies constraints (e.g., maximum amount, specific merchant), the verification must confirm the delivery falls within those constraints.

When the AP2 marketplace and VCAP verifier are on different platforms, the shared secret for proof signatures MUST be established out-of-band and rotated per VCAP Section 9.1.

An AP2 implementation claiming VCAP binding conformance MUST: [ ] Create VCAP escrow_hold on PaymentIntent authorization (when captureType is escrow_release) [ ] Dispatch VCAP verification_request on seller delivery [ ] Process VCAP verification_callback to trigger PaymentIntent state transitions [ ] Append vcap.verification_proof evidence to the PaymentIntent [ ] Emit AP2-compatible webhook events for VCAP state transitions [ ] Handle verification timeout with escalation to manual review [ ] Respect AP2 dispute window as VCAP timeout ceiling

SwarmSync.AI Google et al.