---
updatedAt: 2026-09-01T14:29:24.000Z
---

Fetch the complete documentation index at: https://docs.skyfire.xyz/llms.txt. Use this file to discover all available pages before exploring further. Append .md to any documentation page URL to get its markdown version.

# Agentic Commerce with Payment Cards

What changes when an agent makes the purchase, and how identity and payment travel with it.

> New to payment cards? <Anchor target="_blank" href="/docs/payment-cards">Payment Cards</Anchor> covers what a payment card, agentic token, payment credential, and `pay`/`kya-pay` token are, if you want that background first. This page adopts its terminology, including referring to the end user as the **cardholder**.

In agentic commerce, an AI agent completes a purchase: it searches, adds to cart, and pays a merchant on behalf of a cardholder. This page explains how `kya` and `pay` tokens make that possible with a payment card, the same credit or debit card commonly used to pay for goods and services digitally or in person.

## Buy now vs buy later

Agentic commerce introduces a layer between the cardholder and the merchant: the agent/agent platform. This layer can complete a purchase without the cardholder present at the time of purchase. That capability is why authorization matters, and why two kinds of purchase emerge: *buy now*, and *buy later*.

In the "buy now" model, the agent/agent platform completes the purchase right away. In the "buy later" model, it waits until a condition the cardholder set is met, for example a price drop or an item coming back in stock.

Both kinds authorize the same details: a merchant, and an amount, among other transaction specific details. That amount is always a ceiling, not a guaranteed charge, even for a purchase completed right away. The agent/agent platform can never spend more than the cardholder approved.

## Where KYAPay tokens fit into an agentic purchase

Once a cardholder authorizes a purchase, KYAPay tokens carry that authorization, and the agent/agent platform's identity, through the rest of it. An agent/agent platform attaches a `kya` token to prove who it is or that it's authorized to pay. It attaches a `pay` token to complete the purchase. Here's what that typically looks like, from search to checkout. The exact sequence depends on what the merchant requires.

1. **Chat.** A cardholder tells the agent/agent platform what they want, for example "find me funny coffee shirts."
2. **Search, with identity.** The agent/agent platform makes requests to the live merchant site (website and/or APIs including MCP servers) to find products. Many sites sit behind bot managers that block automated traffic, so the agent/agent platform attaches a `kya` token to each request. The site, or the bot manager in front of it, can then identify the agent/agent platform and allow it through rather than block it.
3. **Add to cart, with identity.** The agent/agent platform narrows the search results to what fits the cardholder's ask, and adds the selected product to the cart. A `kya` token continues to be attached to these requests, linking the cart to the agent/agent platform throughout the session.
4. **Checkout, with identity and payment.** The cardholder authorizes the purchase. The agent/agent platform attaches a `pay` token to complete it, alongside the `kya` token already identifying it. The merchant can use that `kya` token to create a guest checkout account.

NOTE: `kya` tokens sit along side session tokens, session identifiers, OAuth access tokens and other session management mechanisms that merchants use. `kya` is complementary to these and it enriches these with the human and agent context. This enables merchants to make runtime business decisions on whether to allow verified agents, that are acting on behalf of human principals, to access their sites.

## How much identity to request

The walkthrough above shows how identity is continually presented with a `kya` token so an agent/agent platform is never anonymous. How much identity is required at each step is set by the merchant, and it can vary by use case.

| Step                 | Typical identity need                                                                                         | What that looks like                                                           |
| -------------------- | ------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| **Search**           | Minimal, enough to distinguish the agent/agent platform from anonymous bot traffic                            | A `kya` token with no additional identity fields requested                     |
| **Checkout (guest)** | Enough about the cardholder to create a guest checkout account or meet the merchant's compliance requirements | A `kya` token with `identityPermissions` for fields like name and phone number |

> An agent/agent platform requests specific identity fields through `identityPermissions` on the token it creates, matched against the fields a merchant requires through its own `humanIdentityRequirement`. See <Anchor target="_blank" href="/reference/identity-fields">Identity Fields</Anchor> for the full list of fields a merchant can require and an agent/agent platform can share.

***

From the merchant's side, an agentic purchase is never anonymous. A `kya` token identifies the agent/agent platform on every request, from the first search onward, and a `pay` token carries the payment. What the merchant requires at each step determines how much identity that `kya` token needs to carry.

## Next steps

* To build an agentic checkout with Skyfire's Payments React SDK, see <Anchor target="_blank" href="/docs/building-an-agentic-checkout">Building an Agentic Checkout</Anchor>.
* To originate tokens for your own customers' agents, see <Anchor target="_blank" href="/docs/originate-tokens">Originate Tokens</Anchor>.