The Types of Credentials Merchants are Receiving in Agentic Commerce

Autonomous agents have begun executing purchases on behalf of consumers, and merchants are being asked to accept a rapidly expanding set of payment credentials. At VGS, we've already seen merchants receive or prepare to receive at least six distinct credential types from agents and AI-driven commerce platforms.

This is not just a technical nuance; it is the operational reality merchants must prepare for. Each credential type carries unique implications for fraud, authorization performance, trust, data rights, and reconciliation.

And because this shift is being driven by “first to market” momentum in agentic commerce, some of these new credentials, especially network agentic tokens, are launching with constraints that could break early on and HAVE to evolve.

Let's unpack what merchants are facing.

 

The Six Credential Types Emerging in Agentic Commerce

Merchants may receive any combination of the following credentials when an agent initiates a transaction. Each has very different behaviors, liabilities, and lifecycle rules.

1. Agentic Token (New)

   • Created specifically for agent-driven transactions. They are not live yet, but plan to be soon.
   • To leverage agentic tokens, you will NEED experience with network tokens and network token APIs.
   • Represents an actual card number AND the carrier's embedded permission.
   • Today, agentic tokens are single-use, making them highly dynamic but also operationally unpredictable for merchants.
   • Early-stage spec: no historical data, unclear authorization performance, increased abstraction of identity.

2. Ecommerce Token (Apple Pay DPAN, etc.)

   • Traditionally used for device-based wallets.
   • Now being repurposed or rebranded for agentic contexts.
   • Stable, well-understood fraud and auth patterns.
   • Merchants tend to trust these more because they behave like consumer-presented credentials, but they may not reflect the same risk posture when used by agents.
   • If one of these is received, future cryptograms and life cycle events will be delivered by the requester (agent/platform), creating lock-in for future use.

3. Card-on-File (COF) Network Token

   • A token is issued to a specific merchant, mapped by the network.
   • Extremely valuable for merchants because:
     • Lifecycle is stable (persistent, not single-use).
     • It replaces PAN storage with token storage, reducing PCI scope.
     • It supports recurring or subscription transactions cleanly.
   • However, agents may attempt to utilize these in ways that merchants haven't modeled.
   • To receive one of these from an agent, the merchant would have needed to have onboarded with the agent/platform in advance as a TRTSP.
   • If one of these is received, future cryptograms and life cycle events will be delivered by the requester (agent/platform), creating lock-in for future use.

4. Virtual Cards

   • Often issued on demand for a single agent or single transaction.
   • Behave like a PAN but with built-in constraints (MCC, merchant ID, time window, velocity).
   • Unlike tokens that represent the underlying funding source, virtual cards have no connection to the underlying funding source, making it tough to analyze fraudulent transactions.
   • The merchant of record is the agent/platform, not the downstream merchant, making refunds or disputes more complex.
   • Merchants like clarity; issuers like control.
   • Potential challenge: fragmentation of reconciliation when virtual cards proliferate.

5. PAN (Primary Account Number)

   • The raw card number.
   • Still, the most universally accepted and truest form of credential.
   • Highest fraud exposure, but also the most transparent signal for risk models.
   • Some agents will default to PAN where possible, simply because legacy systems cannot yet accept network tokens.
   • With the PAN, merchants can make their own network tokens if desired, for auth rate improvement and future 'card on file' transactions.

6. PAN (Primary Account Number)

   • Credentials created by payment service providers.
   • Typically represent stored cards at the PSP level.
   • Behave well in current e-commerce flows, but PSP tokens may not seamlessly translate to agentic flows, which introduces edge cases around routing and liability.
   • Its unlikely that agents or platforms will pass this credential as it shows bias to a specific PSP.

The key tension lies in the fact that agents are capable of presenting any of these, depending on the user experience, the platform, the issuer, or the network. Merchants must be prepared to receive all six, even if they only want one of them.

 

Why This Creates Immediate Complexity for Merchants

Merchants normally deal with 2-3 credential types (PAN, network token, wallet token). Agentic commerce expands that to 6+, each with:

• Different lifecycle rules
• Different fraud signals
• Different methods of issuer recognition
• Different authorization likelihood
• Different data fields (and missing data fields)

Across these, the merchant is still the party liable for fraud.

Because the networks are racing to establish themselves early, the current generation of agentic tokens is single-use, meaning:

• The credential disappears after a single transaction.
• No stable history exists for risk modeling.
• No ability to recognize repeat agents or repeat customers.
• Subscriptions or incremental transactions must fall back to other credentials.

This creates churn in systems not designed for ephemeral credentials. Merchants will need new logic to rationalize these transactions, aggregate them, and manage the relationship with the underlying customer, all without having direct visibility into the customer.

A PAN and a PSP token have radically different fraud surfaces.

An agentic token has no track record.

A virtual card may be constrained—but may also hide useful signals.

Merchants should anticipate:

• Uneven authorization rates
• Inconsistent dispute patterns
• Unpredictable issuer responses
• New fraud typologies driven by agent impersonation

Example:

A merchant receives a refunded PAN, but the original transaction used a single-use agentic token. How do you match them?

Multiply that by millions of transactions.

 

Why Merchants Need a Credential Strategy

Merchants cannot treat these credentials as interchangeable. They need policy.

Key questions to define:

1. Agentic Token (New)

   Some merchants may initially refuse agentic tokens.

   Others may require that agents use COF network tokens for repeatability.

2. What risk posture applies to each credential?

   Should a single-use agentic token be subject to the same fraud threshold as a long-lived COF token? Probably not.

3. What data do you need, and from whom?

   Merchants will need:

   • Metadata on the agent
   • Metadata on the credential
   • Clarity on the underlying funding source (where allowed)

   This data does not naturally flow today.

4. How will you connect transactions across credential types?

   If an agent uses an agentic token today, a virtual card tomorrow, and a PSP token next week, how do you consolidate that activity into a unified “customer” view?

The Takeaway: Agents Will Not Choose a Single Credential. Merchants Must Prepare for All of Them

Agents and AI commerce platforms will optimize for their user experience, not for merchant operational burden. They may swap credential types dynamically depending on:

• Issuer rules
• Network incentives
• User settings

• Fraud thresholds
• Availability of tokens
• Cost

• Routing strategy

Merchants, therefore, require an abstraction layer encompassing policy, data, and infrastructure to manage this volatility safely.