Roles
ACK defines several functional roles that can be implemented flexibly, depending on specific use cases and organizational needs:| Role | Description |
|---|---|
| Client Agent | Systems initiating service requests or payments on behalf of end-users or autonomous processes (e.g., applications, other agents). |
| Server Agent | Systems delivering services/resources, verifying identities (ACK-ID) and receipts (ACK-Pay), and fulfilling requests (e.g., APIs, service agents, MCP providers). |
| Identity Provider | Services issuing and verifying identity credentials (DIDs/VCs via ACK-ID) to establish trust. |
| Payment Service | Manages ACK-Pay payment execution, acting as an intermediary handling settlement, compliance, conversions, and human oversight flows. Payment Services may be implemented as agents, or as API services exposed by tools. |
| Receipt Service | Issues and validates cryptographically verifiable ACK Receipts (as Verifiable Credentials) upon payment confirmation. |
| Settlement Network | Underlying financial infrastructures processing value transfer (e.g., banking rails, card networks, blockchains). |
Organizations implementing ACK may map these roles flexibly. Multiple roles
might be combined into a single service, or roles might be distributed across
specialized components.
Core Interaction Patterns
ACK outlines two primary interaction patterns: Server-Initiated and Client-Initiated sequences. Both patterns leverage the Payment Service to handle the complexities of payment execution and utilize the standardized ACK Receipt as verifiable proof.Server-Initiated Sequence
This pattern is typically used when a Server Agent requires payment before
fulfilling a Client Agent’s request for a resource or service.
Client-Initiated Sequence
This pattern is used when a Client Agent initiates a payment based on a
known out-of-band obligation (e.g., paying an invoice or completing an
e-commerce checkout).
Server-Initiated Sequence
Below is an overview of the Server-Initiated Sequence: To enlarge this mermaid markdown diagram, zoom in on your browser (CMD +)1
Client Request & Optional Identity Verification
Client Agent requests a service/resource from the Server Agent. The Server
Agent may optionally verify the Client’s identity (requesting Proof of
Agency) before replying.
2
Server Sends Payment Request & Optional Identity Verification
Server Agent determines payment is needed and sends a standardized ACK-Pay
Payment Request payload to the Client (idiomatically via HTTP 402, or
embedded in other protocols). The Client Agent optionally verifies the
identity of the Server Agent.
3
Client Interacts with Payment Service
Client Agent selects a payment option from the Payment Request and interacts
with the designated Payment Service. This interaction may involve optional
mutual Proof of Agency between the Client and Payment Service, or additional
requirements based upon various risk triggers. Human-in-the-loop approvals
may occur at this stage.
4
Payment Execution by Payment Service
Payment Service executes the payment. This may include currency conversions,
compliance checks, or additional internal approvals.
5
Receipt Generation & Optional Server Callback
Payment Service confirms successful payment and coordinates with the Receipt
Service to request a verifiable ACK Receipt (as a Verifiable Credential). If
a callback URL was included in the original Payment Request, the Payment
Service transmits the Receipt to the Server Agent via the callback.
6
Receipt Delivery to Client
Payment Service returns the ACK Receipt to the Client Agent.
7
Client Presents Receipt to Server
Client Agent presents the ACK Receipt to the Server Agent (typically when
re-requesting the resource or in a follow-up interaction). This may not be
necessary if a Server callback occurs.
8
Server Verifies Receipt & Delivers Service
Server Agent verifies the ACK Receipt (cryptographically, and against its
policies) and, if valid, delivers the requested service/resource.
Client-Initiated Sequence
Below is an overview of the Client-Initiated Sequence: To enlarge this mermaid markdown diagram, zoom in on your browser (CMD +)1
Identify Obligation & Construct Payment Request
Client Agent identifies the payment obligation (recipient, amount, currency,
reference). The Client Agent then constructs a structured Payment Request
payload, potentially using a Payment Service API for assistance (e.g., to
parse an invoice, a shopping cart summary, or interpret an end-user’s
instruction).
2
Select Payment Service & Initiate Payment
Client Agent selects/identifies an appropriate Payment Service (which may be
pre-configured or dynamically discovered). The Client Agent provides its
identity proof to the Payment Service.
3
Authorize Payment & Optional Identity Verification
Client Agent interacts directly with the Payment Service’s API to authorize
the payment. This interaction may involve optional mutual Proof of Agency
between the Client and Payment Service, or additional requirements based
upon various risk triggers. Human-in-the-loop approvals may occur here.
4
Payment Execution by Payment Service
Payment Service executes the payment. This may include currency conversions,
compliance checks, or additional internal approvals.
5
Receipt Generation & Optional Server Callback
Payment Service confirms successful payment and coordinates with the Receipt
Service to request a verifiable ACK Receipt (as a Verifiable Credential). If
a callback was included in the Client’s constructed Payment Request (or if
the Payment Service knows the ultimate recipient Server), the Payment
Service may transmit the Receipt to that Server Agent via a callback URL.
6
Receipt Delivery to Client & Optional Notification
Payment Service returns the ACK Receipt to the Client Agent. The Client
Agent may then optionally inform the original recipient Server (if no
callback occurred) or simply persist the receipt for its own records and
auditing.
Human-in-the-Loop Integration
ACK incorporates strategic human oversight at distinct levels:- Operational Oversight: Payment Services provide hooks for internal approval workflows, risk monitoring, and exception handling processes to ensure compliance and transaction integrity in accordance with organizational policy (e.g., manual review of high-value or suspicious transactions).
- User/Owner Authorization: Client applications or agents may require explicit end-user or owner approvals for sensitive operations (e.g., confirming payments beyond a defined policy threshold), ensuring control and transparency.