ACK Integration
Agent Commerce Kit — an LCP reference in the ACK-Pay receipt credential, covered by the issuer's proof.
This section is advisory and non-prescriptive. It describes what the host protocol permits, read from its own primary artifact. Where this page and the host protocol disagree, the host is correct — build from its schema, not from an example here.
Checked against agentcommercekit/ack, packages/ack-pay/src/schemas/valibot.ts, read 2026-09-07.
What it is. An open-source set of patterns and building blocks for agent identity and payments, published by Catena Labs under the MIT licence and built on W3C standards: ACK-ID establishes verifiable agent identity using Decentralized Identifiers and Verifiable Credentials, and ACK-Pay covers payment flows and receipts issued as Verifiable Credentials, with human oversight designed in. It is a reference toolkit rather than a governed standard — it publishes no specification release train, working group, or extension registry.
Tier A — Available today. ACK-Pay issues a PaymentReceiptCredential whose claim carries
paymentRequestToken and paymentOptionId alongside an optional, unconstrained metadata object — typed
in the reference implementation as an open string-to-unknown record. An LCP reference placed there requires no
coordination:
{
"type": ["VerifiableCredential", "PaymentReceiptCredential"],
"credentialSubject": {
"paymentRequestToken": "...",
"paymentOptionId": "...",
"metadata": {
"legalContext": {
"type": "sha256",
"value": "0x7f83b165...",
"legalContextUrl": "https://example.com/atr/k7VdYqZw1uJmH6cnR0aA-g"
}
}
}
}Because the reference sits inside a Verifiable Credential, it is covered by the issuer's proof — bound to the issuer's assertion rather than merely transported alongside it. This makes ACK one of the few surfaces in this appendix where a Tier A placement is signed by default.
Tier B — Forward work. There is no upstream body to register with. Standardization would take the form of the ACK maintainers documenting a conventional key, which is a documentation act rather than a specification change.
Limitations. The metadata object is optional and unconstrained, so a consumer is not required to read it
and different implementations may use different keys for the same idea. ACK publishes patterns and a reference
implementation rather than a conformance surface, so "what ACK does" is defined by that implementation rather
than by a versioned specification — an integration should be re-checked against the code, not against this
illustration.
Steward invitation. Catena Labs is invited to document a conventional legal-context key in the receipt credential's metadata and to publish guidance on the relationship between ACK-ID agent identity and merchant-side terms records.
Mastercard Verifiable Intent Integration
SD-JWT credentials — there is no Tier A carrier for an LCP constraint; registration is the path.
Relationship to Authorization Protocols
LCP captures the merchant's side of a transaction. Authorization protocols capture the consumer's side. Together they form a complete agreement.