Cryptorefills

• Name: Cryptorefills
• URL: https://www.cryptorefills.com/
• Category: crypto-spend catalog operator / digital-goods checkout company / agent-facing commerce and fulfillment shell
• Tags: bitcoin-ecosystem ethereum-ecosystem
• Summary: Cryptorefills belongs in companies/ because the useful control-surface question is not only how does the search → quote → order → pay → deliver flow work? but which named operator controls supplier and brand admission, owns the catalog and delivery relationship, publishes the API and agent-access lanes, decides which payment methods and networks stay live, and acts as the support and disclosure boundary users are told to trust? The public materials make that operator role unusually explicit: Cryptorefills says it handles delivery, requires product UIs to disclose that the user is using Cryptorefills service, and offers both partner-authenticated APIs and lower-friction MCP / x402 agent lanes under the same company-run shell.
• What it does:
  • Operates a catalog of gift cards, mobile top-ups, eSIMs, flights, and stays purchasable with Bitcoin, Lightning, stablecoins, and other crypto assets
  • Packages a partner API for catalog browsing, quoting, validation, order creation, and order-status tracking across the full purchase lifecycle
  • Publishes agent-facing access paths through MCP manifests, agent skills, and x402-powered autonomous purchase flows that sit under the same operator boundary as the conventional API
  • Handles product delivery and customer-support responsibility for ordered products according to the API marketing materials
  • Manages supplier and brand relationships, including direct brand API integrations or stocked-code supply relationships, which gives the company real distribution choke-point power rather than just frontend branding
  • Sells one operator-managed crypto-spend shell to wallets, rewards programs, mini apps, and AI-agent workflows instead of exposing a neutral payment or commerce protocol
• Key claims:
  • The homepage says users can choose from 6,600+ gift cards, eSIMs, flights, stays, and mobile top-ups, pay with BTC, ETH, USDT, USDC, and many more assets, and receive products instantly; that is useful catalog-scale context, but the more important point is that one company packages the whole discovery-to-delivery flow
  • The API landing page describes Cryptorefills as the stablecoin checkout API for gift cards, mobile top-ups and eSIMs and frames the experience as one deterministic flow from search to quote to payment to delivery, which is exactly why the operator boundary matters
  • The same API page says Cryptorefills handles delivery, requires integrators to disclose to end users that they are using Cryptorefills service, and says Cryptorefills is available to support customers; those are unusually direct first-party statements that the company, not just the API object model, is the live fulfillment and support boundary
  • The developer and machine-readable materials show two access models under one roof: a partner-oriented API with conventional integration expectations and lower-friction MCP / x402 lanes that work without account, OAuth, or API-key provisioning for some agent workflows
  • The llms.txt and agent-skills materials show Cryptorefills is not only a gift-card storefront; it is deliberately trying to become an agent-native commerce operator whose HTTP, MCP, and x402 surfaces all terminate inside the same company-run catalog and fulfillment stack
  • The supplier-partnership page says Cryptorefills can onboard inventory through direct brand API integration or stocked-code relationships and already distributes through both direct users and partners such as Binance, which reinforces that supplier admission and reseller distribution sit at the company layer
  • Official materials are inconsistent on catalog scale, with some pages citing 6,600+ brands/products and llms.txt citing 10,500+ brands; that inconsistency does not change the control-surface read, but it is worth carrying as a reminder that the company itself is the source of catalog truth and marketing numbers
• Whitepaper: No standalone company whitepaper is the artifact that matters here. The strongest current primary materials are the homepage, API landing and developer docs, llms.txt, machine-readable MCP and agent-skill discovery endpoints, supplier-partnership materials, and the public Cryptorefills/agents repository; see ../whitepapers/cryptorefills-primary-sources-2026-05-02.md.
• Sources:
  • https://www.cryptorefills.com/
  • https://www.cryptorefills.com/en/api-docs
  • https://www.cryptorefills.com/en/api-docs/developers
  • https://www.cryptorefills.com/en/ai-agents
  • https://www.cryptorefills.com/en/consumer-and-digital-brands
  • https://www.cryptorefills.com/llms.txt
  • https://api.cryptorefills.com/.well-known/mcp.json
  • https://api.cryptorefills.com/.well-known/agent-skills/index.json
  • https://github.com/Cryptorefills/agents

Internal linkages

• Product-layer note: cryptorefills.
• Useful adjacent company/operator reads: bitrefill, moonpay, and crossmint.
• Useful protocol and interface contrasts: x402 and open-payments.

Protocol / company boundary

• cryptorefills should stay focused on the purchase mechanics integrators and agents wire against directly: catalog search, quote generation, order validation, payment-address creation, SSE or polling-based order tracking, and the newer MCP / x402 access paths.
• This company note is the cleaner place to reason about who controls supplier admission, catalog curation, delivery responsibility, customer-support workflow, which payment methods and networks remain live, and which distribution channels Cryptorefills chooses to expose to partners, end users, or agents.
• That split matters because how does the checkout API behave? and which company controls the catalog, fulfillment, disclosure, and support shell around that API? are related but not identical questions.

Control surface

• Practical leverage sits in supplier and brand admission, country and catalog availability, quote and checkout defaults, payment-method and network exposure, order-state and delivery truth, customer-support workflow, and the policy choice to expose some purchase lanes through partner APIs while opening others through MCP or x402.

• The sticky dependency is operational rather than purely technical: once a wallet, mini app, rewards program, or AI agent starts depending on Cryptorefills for quote truth, order acceptance, delivery, and support, the real dependency is on the company-run catalog and fulfillment shell rather than on any neutral spending protocol.

• Treat Cryptorefills as a commerce and fulfillment operator first. The API, MCP, and x402 surfaces are access lanes into that operator shell, not replacements for it.

• Last reviewed: 2026-08-12 UTC