Building an Agentic Checkout

The mechanics of an agentic checkout with a payment card, and where to start building one.

This page explains how agentic purchases with a payment card are built with Skyfire's Payments React SDK. It covers the parties involved, the two hosted flows the SDK provides, one to authorize a purchase and one to manage enrolled cards, and how a pay or kya-pay token is created from a payment card. It closes with reference implementations of the whole pattern.

NOTE: SDKs for other frameworks and languages are also available. Please contact us for yours.

For a high level explanation of an agentic purchase from search to checkout, see Agentic Commerce with Payment Cards.

Roles

Several parties make an agentic purchase with a payment card possible. Here's who's responsible for what:

RoleResponsibility
CardholderThe person who owns the payment card, the human principal. Authenticates during enrollment, and authorizes each purchase.
Agent / Agent platformResponsible for running the integration. It hosts the application the cardholder works in, installs the Payments React SDK, collects the cardholder's approval, and creates the pay token. It takes that token and presents it to a merchant or service to complete the purchase. How these responsibilities are split internally is an architecture decision.
Payments React SDKA React library from Skyfire that the agent/agent platform installs. It renders an iframe that loads a hosted flow, and relays information between the agent/agent platform and that iframe.
NOTE: SDKs for other frameworks and languages are also available. Please contact us for yours.
SkyfireServes the hosted flows, stores the enrolled card, and issues the token.
Merchant / serviceReceives the token and reads its settlement type to see how it was funded.

Agent platform and agent are distinct roles, not necessarily distinct systems. In Skyfire's own reference implementation, the agent platform consists of a Next.js application together with the agents that run within it: the Next.js application creates the pay token, and the agents use it to pay merchants. Your own implementation might split these responsibilities differently, and doesn't have to use React to do it. If the Payments React SDK doesn't fit your stack, reach out to [email protected] and we'll provide what you need.

Supported card networks

However these responsibilities are split, card support itself is uniform. Skyfire currently supports payment cards from Visa and Mastercard. Support for AMEX and Discover is coming soon. Enrolling a card and creating a token work the same way regardless of network.

The two hosted flows

A cardholder enrolls and pays with a card through two hosted flows. Each is a short sequence of screens rendered in an iframe that the SDK provides.

  • Card management flow: Lets the cardholder enroll, lock/unlock, or remove payment cards. Locking blocks a card from new payments without removing it. An unlocked card can be used again. A removed card must be re-enrolled before an agent/agent platform can pay with it.
  • Purchase authorization flow. The cardholder adds or selects a previously enrolled card, then authorizes a specific amount. This is the flow that produces a token, and the next section traces it step by step.

Both flows appear inside the agent/agent platform's application, so the cardholder never leaves it. Card details are encrypted before being sent to Skyfire, keeping them out of PCI DSS scope. The agent/agent platform cannot read what happens inside the iframe, so card details never reach its application.

How pay and kya-pay tokens are created from payment cards

Only the purchase authorization flow creates a token. Card details never leave that flow. Only the resulting authorization data does, which the agent/agent platform then sends to Skyfire to mint the token.

The steps below trace that process, from opening the flow to paying the merchant:

  1. The purchase authorization flow opens. The agent/agent platform renders the SDK's purchase authorization component with the amount to authorize and the seller, either a seller domain/URL or a seller service ID. Product details (name, price, quantity, URL) are optional. The SDK passes this context to the flow.
  2. The cardholder adds or selects a card. To enroll a new card, they enter their card details and confirm ownership. To use a card they enrolled earlier, they select it.
  3. The cardholder authorizes the payment. They authorize the exact amount shown, using their passkey. Nothing proceeds until they do.
  4. The flow returns authorization data. The SDK passes it to the agent platform as a ready-to-send request body, and the platform hands that body to the agent.
  5. The agent platform creates the token. It sends the body to Create Token, authenticated with the agent's own Skyfire credential, minting the pay or kya-pay token.
  6. The agent pays the merchant. The agent platform hands the token to the agent, which presents it to the merchant or service to complete the purchase.

In Skyfire's reference implementation, the agent platform consists of a Next.js application together with the agents that run within it. The Next.js application creates the token, and the agents use it to pay merchants. Your own implementation might split these responsibilities differently, and does not have to use React. See Agentic Commerce with Payment Cards for more on how these roles relate.

Starting points

Rather than building all of this from scratch, you can start from a reference implementation. Two starting points cover most integrations:

PieceYour options
Chat UIAdopt our Next.js reference, or use your own front end
Shopping agentAdopt our FastAPI/Strands reference, or bring your own agent
Storefront to shop fromWe host one for you, nothing to run

These are not the only combinations. You might bring your own agent but use our protection layer, or host your own store while adopting our reference agent, or start at point 1 and grow into point 2 later.

Tell your Skyfire contact what you are trying to evaluate, and we will point you at the pieces you need.

Getting access

Trying this out means getting access to Skyfire payment cards, the reference repositories, and the Payments React SDK, along with sandbox credentials for the pieces you choose to adopt.

The reference implementation lives at eCom-shopping-agent-demo-reference. The repository is private. If your GitHub account has already been granted access, the link opens it directly. If not, reach out to [email protected] to get set up.

Next steps


Did this page help you?