The Bitcoin Company

• Name: The Bitcoin Company
• URL: https://www.thebitcoincompany.com/
• Category: bitcoin spending and remittance company / gift-card and prepaid-card commerce operator / partner API and payout workflow shell
• Tags: bitcoin-ecosystem
• Summary: The Bitcoin Company belongs in companies/ because the practical control surface is a named operator that decides which merchants, prepaid-card products, remittance corridors, payout destinations, and future swap or exchange features customers and partners can actually access. The useful question is not just can an app spend bitcoin? but which company issues API credentials, sets remittance spread policy, controls gift-card and prepaid-card inventory, and acts as the source of truth for payment and payout workflow state?
• What it does:
  • Operates a consumer bitcoin spending stack built around gift cards, prepaid Visa cards, and rewards-linked shopping flows
  • Runs a remittances product for BRL and MXN payouts over PIX and SPEI rails, with positioning that explicitly targets partner app integration rather than only first-party app usage
  • Exposes API surfaces for organization credential creation, remittance spread-account configuration, bitcoin-funded invoices, and user USD-balance top-ups
  • Packages consumer commerce, corridor-specific remittances, and upcoming swap or exchange ambitions under one company-run shell rather than a neutral payment rail
  • Controls which payout destinations, merchant categories, and product branches are available to users and integrators at any given time
• Key claims:
  • The homepage describes The Bitcoin Company as the easiest way to spend bitcoin and earn rewards and markets prepaid Visa cards, gift cards, and broad merchant coverage rather than a narrow wallet utility
  • The remittances page says The Bitcoin Company can power your app with international remittances, specifically real-time MXN payouts over SPEI and BRL payouts over PIX, which is direct evidence of a partner-facing operator surface
  • The public OpenAPI document is titled TBC API documentation and includes organization credential creation, remittance spread-account management, anonymous-user bitcoin invoice creation, and bitcoin-funded USD-balance top-ups, which is much closer to a company-run commerce and payout control plane than to a single consumer app
  • The about page says the company wants to be a one-stop-shop for all your financial needs, which helps explain why rewards, prepaid spend, remittances, and future swap or exchange services are bundled together
  • The bug-bounty page advertises upcoming swap and fiat-to-bitcoin exchange services, reinforcing that the company boundary matters more than any one currently exposed frontend flow
• Whitepaper: No classic standalone company whitepaper is the important artifact here. The strongest primary materials are the homepage, remittances page, about page, bug-bounty page, and public API documentation; see ../whitepapers/the-bitcoin-company-primary-sources-2026-05-01.md.
• Sources:
  • https://www.thebitcoincompany.com/
  • https://www.thebitcoincompany.com/remittances.html
  • https://www.thebitcoincompany.com/about.html
  • https://www.thebitcoincompany.com/bug-bounty.html
  • https://api.dev.thebitcoincompany.com/openapi/api-docs/swagger.json

Internal linkages

• Project-layer alias for inbound references: the-bitcoin-company.
• Useful adjacent company reads: opennode, moonpay, and lightspark.
• Useful product comparison for merchant-funded bitcoin spending without the same remittance-company shell: bitrefill.

Project / company boundary

• Keep the-bitcoin-company only as an alias for the company note. The branded app, API, merchant catalog, prepaid-card path, remittance corridors, and future swap / exchange roadmap do not form a durable separate protocol or neutral product layer.
• This entity note is the real control-surface note: API-key issuance, organization setup, remittance spread policy, corridor and payout coverage, merchant and prepaid-card inventory, and future swap / exchange exposure all sit with one named company.
• That is why the company note should carry the analysis. Downstream users and integrators are not really depending on bitcoin payments in the abstract; they are depending on a company-managed commerce and payout workflow graph.

Control surface

• Practical leverage sits in API credential issuance, organization onboarding, remittance spread-account configuration, corridor admission, payout-destination support, merchant and prepaid-card inventory, invoice generation, and the dashboard / API surfaces that define payment and payout truth.

• The sticky dependency is operational rather than protocol-native: once a partner builds around The Bitcoin Company’s corridors, merchant catalog, invoice lifecycle, and payout workflow, the real lock-in is to the company-run commerce shell.

• Read The Bitcoin Company as a bitcoin commerce and remittance operator first, not as a neutral rail.

• Last reviewed: 2026-08-09 UTC