# ACK · Integra

> The seller-signed Payment Request takes the ATR hash as its id.

URL: https://integraledger.com/protocols/ack

Protocol

## ACK

Agent Commerce Kit

The seller-signed Payment Request takes the ATR hash as its id. [Source: lcp docs: agentic checkouts⁠ (opens in a new tab)](https://github.com/IntegraLedger/integra-protocol/blob/66274bf/docs/guides/checkouts.md)

ACK, the Agent Commerce Kit, is a Catena Labs project. [Source: LCP §C.10⁠ (opens in a new tab)](https://github.com/legal-context-protocol/legal-context-protocol/blob/c8df26d/spec/legal-context-protocol-v1.md#c10-ack-agent-commerce-kit) Integra is not affiliated; we read their published interfaces.

**Sources (1)**

[lcp docs: agentic checkouts⁠ (opens in a new tab)](https://github.com/IntegraLedger/integra-protocol/blob/66274bf/docs/guides/checkouts.md)

[The protocol’s own site⁠ (opens in a new tab)](https://www.agentcommercekit.com) [The standard’s illustration of this protocol (LCP §C.10)⁠ (opens in a new tab)](https://github.com/legal-context-protocol/legal-context-protocol/blob/c8df26d/spec/legal-context-protocol-v1.md#c10-ack-agent-commerce-kit)

### What it is

ACK is an open-source set of patterns and building blocks for agent identity and payments, built on W3C standards: ACK-ID for verifiable agent identity, ACK-Pay for payment flows and receipts. [Source: LCP §C.10⁠ (opens in a new tab)](https://github.com/legal-context-protocol/legal-context-protocol/blob/c8df26d/spec/legal-context-protocol-v1.md#c10-ack-agent-commerce-kit)

**Sources (1)**

[LCP §C.10⁠ (opens in a new tab)](https://github.com/legal-context-protocol/legal-context-protocol/blob/c8df26d/spec/legal-context-protocol-v1.md#c10-ack-agent-commerce-kit)

### Where the ATR hash rides

The payment request the seller signs is named by the ATR hash.

#### The standard

In ACK’s payment flow the seller answers with a `402` carrying a signed Payment Request. The package makes the ATR hash that request’s `id`, as its LCP string, with the link beside it in the `402` body. [Source: lcp docs: agentic checkouts⁠ (opens in a new tab)](https://github.com/IntegraLedger/integra-protocol/blob/66274bf/docs/guides/checkouts.md)

ACK defines no payer signature, so nothing the buyer signs carries the ATR hash, and the pairing’s record says so. [Source: lcp docs: agentic checkouts⁠ (opens in a new tab)](https://github.com/IntegraLedger/integra-protocol/blob/66274bf/docs/guides/checkouts.md)

A receipt issued after settlement embeds the signed Payment Request, so the ATR hash can be read back from it with `fromReceipt`, on a receipt you have verified. [Source: lcp docs: agentic checkouts⁠ (opens in a new tab)](https://github.com/IntegraLedger/integra-protocol/blob/66274bf/docs/guides/checkouts.md)

### What a payment through it proves

Each pairing’s record states what a payment through it shows, and what it does not, in the package’s own words. These are read from the package when the site is built. [Source: lcp docs: pairings reference⁠ (opens in a new tab)](https://github.com/IntegraLedger/integra-protocol/blob/66274bf/docs/reference/pairings.md)

Of these 1 pairings, 0 have the buyer’s signature cover the ATR hash, 0 leave a public proof of it, and 0 let anyone read it back from the chain alone. [Source: lcp docs: pairings reference⁠ (opens in a new tab)](https://github.com/IntegraLedger/integra-protocol/blob/66274bf/docs/reference/pairings.md)

Switch to Technical to see each pairing, and the sentence its record states about what a payment through it proves.

**Sources (1)**

[lcp docs: pairings reference⁠ (opens in a new tab)](https://github.com/IntegraLedger/integra-protocol/blob/66274bf/docs/reference/pairings.md)

#### The standard

- **`ack/payment-request` Native Field Buyer signs H: no H on chain: no Public proof: no Recoverable from chain: no**

  Pattern: [Native Field (LCP §8.3.1)⁠ (opens in a new tab)](https://github.com/legal-context-protocol/legal-context-protocol/blob/c8df26d/spec/legal-context-protocol-v1.md#831-native-field)

  What a payment through it proves: Before this payment, the buyer signed and paid an agreement transaction carrying this ATR's hash on \<network>, recorded in \<transaction>. This ATR's hash was issued to the seller as the id of its signed ACK Payment Request, with the link to deliver beside it before payment; a receipt for that request, issued after settlement, embeds the signed request. Neither the request nor the receipt was seen in making this record. ACK defines no payer signature, so nothing the buyer signed carries the hash. The seller checked nothing the buyer signed, and settlement is the seller's report. This does not show that the buyer's approval carried the hash.

Where a sentence names `<network>` and `<transaction>`, the pairing’s record fills them in: they name the agreement payment the buyer made first. [Source: lcp docs: pairings reference⁠ (opens in a new tab)](https://github.com/IntegraLedger/integra-protocol/blob/66274bf/docs/reference/pairings.md) · [Source: lcp docs: the agreement URL⁠ (opens in a new tab)](https://github.com/IntegraLedger/integra-protocol/blob/66274bf/docs/concepts/buyer-gate.md#the-agreement-url)

### The rails it settles on

A checkout through this protocol is paid by the provider the checkout names, so it lists no rail of its own.
