Payment Cards

A payment card is a credit or debit card, the same kind commonly used to pay for goods and services digitally or in person. It carries a card number, the Primary Account Number (PAN), issued by a bank and permanently tied to the account.

A cardholder typically pays with a payment card by presenting it physically or entering the PAN. An agent could enter the PAN the same way, but that would give it unrestricted access to the account. Skyfire scopes a pay or kya-pay token for an agent to hold instead, and never exposes the PAN.

This page explains how tokenization works, and how Skyfire creates a scoped token to represent a payment card.

Network tokens vs agentic tokens

This section covers how card tokenization works today, independent of Skyfire. The rest of the page builds on it to explain Skyfire's own role: enrolling a card as an agentic token, and wrapping the resulting payment credential in a pay or kya-pay token.

When a cardholder enrolls their payment card with a payment provider, for example Skyfire, Apple Pay, or Google Pay, enrollment replaces the PAN with a token. Future payments use that token instead of the PAN, which reduces exposure and simplifies purchases.

Both types of token:

• Cannot be reversed to reveal the original PAN
• Cannot be used to pay on their own
• Are stored by the payment provider, so the cardholder does not need to repeat enrollment for future purchases

They differ in scope and purpose:

• Network token (merchant-scoped): Created by the issuing bank during enrollment, scoped to a single merchant. It predates agentic commerce.
• Agentic token (agent-scoped): Created by the issuing bank during enrollment, but scoped instead to the cardholder, their device, and the agent platform acting on their behalf. Card networks defined this variant specifically for agents.

The rest of this page follows the stages a card moves through once Skyfire enrolls it as an agentic token, ending in a pay or kya-pay token an agent can use to pay.

Who's involved

Four parties carry a payment card through to a pay or kya-pay token:

The four stages

Together, these parties carry a card through four stages, shown below. Each stage describes a type of credential in transformation, as the payment card turns into a JWT that an agent can use to pay.

flowchart LR
    A["Payment card (PAN)"] --> B["Agentic token"] --> C["Payment credential"] --> D["pay or kya-pay token (JWT)"]

Payment card

As described at the top of this page, a payment card is a cardholder's real credit or debit card, identified by its PAN. A PAN has no built-in restrictions. Whoever holds it can charge the account, at any merchant, for as long as the account stays open.

When a cardholder registers a payment card with a payment provider, a step called enrollment, the account gains a more limited way to be charged. The payment provider sends the PAN to the card network, which relays it to the issuing bank. The cardholder authenticates the request, for example with a one-time passcode or a passkey. The issuing bank verifies the cardholder and tokenizes the card, returning an agentic token.

Agentic token

An agentic token represents a tokenized card that is scoped to a cardholder, their device, and the agent platform acting for them. It can be used to pay any merchant but only by that cardholder on that device, via that agent platform.

Step-up authentication and device binding enforce that binding. Only that agent platform, on that device, can use the resulting token for that merchant.

At the time of a purchase, the cardholder authorizes the payment, and the payment provider passes the agentic token to the card network along with a payment mandate describing that specific purchase. The card network relays the mandate to the issuing bank, which creates and returns a payment credential.

Payment credential

A payment credential is a new, 16-digit number with an expiration date and verification code, the same shape as a PAN. Unlike the agentic token, which is an opaque string, a payment credential looks like an ordinary payment card, but is valid for only a particular purchase.

When Skyfire receives the payment credential, it encodes it into a pay or kya-pay token.

pay or kya-pay token

Every pay and kya-pay token records how it is funded. This is the stp claim, its settlement type, which the merchant or service reads.

A settlement type of card means the token was funded by a payment card rather than a wallet balance. In that case, the token's sti claim carries the payment credential returned by the issuing bank when the payment was authorized.

Separately from settlement, a kya-pay token also carries identity claims: hid for the human principal, aid for the agent, and optionally apd for the agent platform, the same parties an agentic token stays bound to. Carrying them in the token lets the merchant verify that binding directly, rather than relying on the payment provider alone to have enforced it.

See PAY Token for the full claim reference, and KYAPay Tokens for the full set of claims across all token types.

---

These four stages take a payment card from its original, unrestricted form to one scoped narrowly enough for an agent to use. That narrowing is what allows an agent to purchase with a payment card and makes the payment credential PCI-exempt.

Next steps

• For how identity and payment are presented across an agentic purchase, see Agentic Commerce with Payment Cards.