Sell to Your Customers' Agents
What it takes to sell to your own customers' agents, and the decisions specific to that setup.
Your organization can act as a unified seller that your own customers' agents transact with. You run a MCP server, an API, webpage, or a model. Your customers' agents reach it with KYAPay tokens, and you are on both ends of the exchange.
This is a special case of Buy-side organizations in the Organization Guide: your organization users are set up exactly as any buy-side organization's are, and your organization additionally creates one seller agent and seller service to receive their tokens.
Follow Buy-side organizations in the Organization Guide first: choosing a designated admin, creating organization users, deciding who verifies them, and deciding how they access Skyfire's APIs. This page picks up from there.
You are on both ends
Every token exchange has two roles: a buyer that creates a token, and a seller that receives it. Here your organization holds both.
| Role | Party |
|---|---|
| Buyer | Your organization users, i.e. your customers. Each has a buyer agent that creates tokens. |
| Seller | Your organization, through a single seller agent that receives those tokens. |
Your customers are already set up as organization users with buyer agents, per Buy-side above. To receive their tokens, your organization also needs a seller agent, and at least one seller service for it to offer, the same building blocks any Skyfire seller uses. See Seller Guide and How Seller Services Work for what each of those is.
Being on both ends also means managing two kinds of keys correctly: a customer's own agent API key creates a token on their behalf, and your seller agent's API key is what charges it. Using the right one for each keeps every charge attributed to the customer it belongs to. See Verify, deliver, and charge in How Seller Services Work for how charging works.
Design decisions
Whether to charge for access is the same choice any seller makes on Skyfire. See How Seller Services Work for that. Two decisions are specific to running a single seller for your whole organization.
1. Who owns your seller agent
Tokens you receive are addressed to a seller agent, and any funds settle into its wallet. You choose which organization user owns that agent.
The designated admin you chose at onboarding creates the seller agent and your seller service.
You create an additional organization user dedicated to this, and it holds the seller agent. This keeps your receiving side apart from the user that backs your organization.
2. Whether your seller service appears in the directory
Any seller service requires approval before anyone can create tokens for it. What is specific here is who can discover it afterward, since your customers already know where to find it.
Only your own organization users create tokens for the seller service, and it stays out of the public Skyfire Directory.
Any Skyfire buyer can discover the seller service and pay for it, not just your customers. Worth considering if what you offer has value beyond your own customer base.
If you choose to keep your seller service private to your customers and out of the public Skyfire Directory, contact [email protected].
Setting up your one seller agent and service
The organization user chosen in decision 1 completes this setup once.
See Seller Guide for how to.
Configure what it costs and requires. See How Seller Services Work.
Skyfire reviews the seller service before your customers can create tokens for it.
Once approved, your seller service works like any other on Skyfire. From there, you build and run whatever infrastructure you want behind it, verifying tokens, delivering access, charging, and managing payments however suits your organization.
Next steps
- For setting up your organization users, see Buy-side organizations in the Organization Guide.
- To let your customers fund their wallets from inside your own application, see Credits Wallet Embed SDK.
- For holds, charges, and settlement timing, see Payments & Settlement.
Updated about 11 hours ago