Context
ACK-Pay already has the right high-level primitives for agent commerce: a server-issued payment request, client/payment-service execution, and a verifiable receipt. Since MPP and x402 are both evolving quickly around HTTP 402 flows, it would be useful to document how ACK-Pay maps to those protocols without making ACK depend on either one.
Current protocol anchors:
- MPP models HTTP payment flows as Challenge -> Credential -> Receipt, with HTTP, MCP/JSON-RPC, and WebSocket transports.
- x402 models PaymentRequired -> PaymentPayload/Payment-Signature -> Payment Response, with schemes such as exact, upto, and batch settlement.
- ACK-Pay models PaymentRequest -> payment execution -> PaymentReceiptCredential.
Proposal
Add a small docs/spec page or appendix that maps ACK-Pay concepts to MPP and x402 concepts:
| ACK-Pay |
MPP |
x402 |
| Payment Request |
Challenge |
PaymentRequired / PaymentRequirements |
| Payment option |
Payment method / payment request |
scheme + network + requirements |
| Payment execution proof |
Credential |
PaymentPayload / Payment-Signature |
| Payment receipt VC |
Receipt |
Payment Response / signed receipt extension |
| Receipt issuer |
Server/payment verifier |
facilitator/resource server |
| Human oversight / policy |
client/payment-service policy |
client/facilitator policy layer |
The page should be explicitly non-normative at first: it would explain where ACK can compose with MPP/x402, what ACK adds beyond rail-specific payment execution, and what fields should remain opaque extension metadata.
Why this helps
- ACK can stay rail-neutral while giving builders a clear migration/interoperability path.
- MPP is adding session, subscription, card, stablecoin, MCP and WebSocket transport surfaces.
- x402 is adding multiple schemes, signed offers/receipts, idempotency, batch settlement and MCP examples.
- Catena's own roadmap already calls out x402 interop and broader payment protocol interoperability.
Small first slice
I would start with docs only:
docs/ack-pay/operational-considerations.mdx or a new docs/ack-pay/interoperability.mdx- one diagram or table mapping ACK-Pay <-> MPP <-> x402
- one short example showing an ACK receipt carrying an MPP/x402 execution reference in metadata without changing the core VC shape
No SDK dependency is needed for the first slice.
Context
ACK-Pay already has the right high-level primitives for agent commerce: a server-issued payment request, client/payment-service execution, and a verifiable receipt. Since MPP and x402 are both evolving quickly around HTTP 402 flows, it would be useful to document how ACK-Pay maps to those protocols without making ACK depend on either one.
Current protocol anchors:
Proposal
Add a small docs/spec page or appendix that maps ACK-Pay concepts to MPP and x402 concepts:
The page should be explicitly non-normative at first: it would explain where ACK can compose with MPP/x402, what ACK adds beyond rail-specific payment execution, and what fields should remain opaque extension metadata.
Why this helps
Small first slice
I would start with docs only:
docs/ack-pay/operational-considerations.mdxor a newdocs/ack-pay/interoperability.mdxNo SDK dependency is needed for the first slice.