Bitrefill / Airfill Prepaid AB

  • Name: Bitrefill / Airfill Prepaid AB
  • URL: https://www.bitrefill.com/
  • Category: crypto commerce operator / gift-card-and-eSIM catalog company / invoice-and-redemption workflow boundary
  • Tags: bitcoin-ecosystem
  • Summary: Bitrefill clears the bar for companies/ because the sticky dependency is not merely a catalog of gift cards and eSIMs exists; it is that a named operator admits partners, decides which catalog and Thor inventory are exposed, issues personal versus business versus affiliate credentials, hosts invoice and webhook truth, controls the OAuth/API-key boundary for agent purchases, and wraps the whole stack in a Swedish legal and privacy perimeter tied to Airfill Prepaid AB. The product note still matters for the software shell, but the practical authority sits with the company-operated commerce workflow.
  • What it does:
    • Operates the Bitrefill consumer account, balance, invoice, and order-delivery boundary for gift cards, eSIMs, mobile refills, and adjacent catalog products
    • Issues different access tiers across Personal, Business, and Affiliate APIs, including self-service personal API keys and approval-gated business or affiliate credentials
    • Runs the standard B2B partner workflow for catalog caching, invoice creation, payment handling, webhook delivery, and redemption-code retrieval
    • Hosts the eCommerce MCP endpoint with OAuth or API-key access so agents can search products, create invoices, track status, and retrieve delivered order data through a curated tool set
    • Packages partner distribution through the Bitrefill integration widget and related partner-program review flow rather than exposing a purely permissionless resale surface
    • Sells Thor Lightning utility inventory and related order flows under the same company-run account, payment, and delivery shell
  • Key claims:
    • The API overview says Personal API access is self-service through a Bitrefill account, while Business and Affiliate access require applying to Bitrefill programs and then receiving separate credentials, which makes partner admission and credential issuance a real company control surface
    • The same API overview says Business access adds full product catalog access, test products, account deposits, and dedicated support, reinforcing that Bitrefill decides who gets the deeper operational surface
    • The reseller integration-flow docs define a standard five-step partner pattern of caching products, creating invoices, paying invoices, receiving webhooks, and delivering codes to users, which is strong evidence that invoice state, stock freshness, webhook truth, and redemption handling all sit inside one operator shell
    • The hosted MCP docs say every MCP session is authenticated through Bitrefill account OAuth by default, with an API-key fallback and a bounded set of 7 tools, which makes Bitrefill the access-control and workflow source of truth for agent purchases rather than a neutral protocol endpoint
    • The help-center integration article and partner-page copy say Bitrefill’s widget lets partners offer thousands of products inside their own sites or apps while earning passive income, and that requests route to Bitrefill’s management team if the partnership is a good fit, which makes partner approval and resale packaging explicitly company-mediated
    • Search-result snippets pointing at Bitrefill’s official privacy and terms pages say the privacy policy is issued on behalf of AIRFILL PREPAID AB, a Swedish company and data controller, and that Bitrefill transactions and disputes are governed by Swedish law and courts, which is enough to justify a named legal-entity boundary even though direct fetches of those pages were Cloudflare-blocked in this pass
    • The verified Bitrefill GitHub org publicly packages MCP, CLI, agent, and machine-payments tooling around the same commerce backend, reinforcing that one company curates multiple access and distribution layers above the catalog itself
  • Whitepaper: No classic standalone company whitepaper is the useful artifact here. The strongest current materials are Bitrefill’s own API, reseller, MCP, help-center, GitHub, and legal-page sources collected in ../whitepapers/bitrefill-company-primary-sources-2026-08-07.md.
  • Sources:

Internal linkages

Protocol / company boundary

  • bitrefill should stay focused on the product shell: catalog browsing, MCP and CLI packaging, Thor utility products, and the software-facing purchase surface.
  • This company note isolates the broader operator boundary: partner approval, credential issuance, account and balance workflow, invoice and webhook truth, product-stock freshness, affiliate attribution, redemption handling, and the legal/privacy perimeter behind the Bitrefill brand.
  • That split matters because the practical dependency integrators inherit is not only gift-card APIs exist; it is a company-managed commerce graph that decides who may resell, how purchases authenticate, what webhook truth looks like, and which inventory remains available.

Control surface

  • Practical leverage sits in partner-program admission, Personal-versus-Business-versus-Affiliate credentialing, product and inventory inclusion, invoice lifecycle, payment-method exposure, webhook delivery, order redemption handling, affiliate attribution, Thor inventory terms, and the Airfill legal/privacy shell around customer and partner data.

  • The sticky dependency is operational rather than purely technical: once an app or agent hardens around Bitrefill account OAuth, API keys, invoice IDs, webhook states, catalog freshness assumptions, and delivered-code retrieval, the lock-in is to the company-run workflow boundary.

  • Read Bitrefill here as a named commerce operator first. The crypto rails and AI wrappers are important, but they are packaged inside one operator-controlled business surface.

  • Last reviewed: 2026-08-07 UTC