Copperx

• Name: Copperx
• URL: https://copperx.io/
• Category: non-custodial merchant-payments operator / hosted checkout-and-billing company / webhook-and-settlement workflow boundary
• Tags: ethereum-ecosystem solana-ecosystem
• Summary: Copperx belongs in companies/ because the useful question is not only what does the checkout or invoice API do? but which named operator issues the bearer tokens, runs the dashboard, decides supported chains and tokens, hosts the checkout/session state machine, signs the webhook and billing lifecycle merchants inherit, and packages recurring billing plus integrations around that shell? The old project note had already drifted into describing a company-run merchant workflow boundary rather than a protocol or neutral payment primitive.
• What it does:
  • Operates a non-custodial crypto payment gateway that settles merchant payments directly into merchant-controlled wallets rather than Copperx custody
  • Runs hosted checkout, invoice, subscription, recurring-invoice, and payment-link flows for businesses and developers
  • Issues bearer-token API access through the Copperx dashboard and exposes session-oriented APIs for creating, retrieving, listing, recovering, and partially completing checkout flows
  • Publishes webhook-driven merchant workflow so integrators can automate provisioning, billing, reminders, renewals, refunds, and other backend actions around Copperx-managed payment state
  • Packages no-code and low-code integrations such as WooCommerce, Zapier, Stripe, BigCommerce, and Magento beside the API surface rather than leaving merchants to assemble everything themselves
  • Decides the supported chain and token matrix merchants inherit across networks such as Solana, Ethereum, Polygon, BNB Smart Chain, Tron, Base, Optimism, and Arbitrum
• Key claims:
  • The docs introduction describes Copperx as a modern, non-custodial crypto payment gateway designed for developers and businesses and says it accepts payments directly into the merchant’s own wallet while Copperx never holds custody, which makes the company boundary analytically interesting because operator dependence persists even without pooled custody
  • The use-cases page positions Copperx across SaaS subscriptions, ecommerce, digital services, donations, event ticketing, developer APIs, and invoicing, which is broader than a single checkout widget and closer to a company-run merchant workflow shell
  • The FAQ says merchants can accept payments across multiple networks including Solana, Ethereum, Polygon, BNB Smart Chain, Tron, Optimism, and Arbitrum while also highlighting refund management, tax and promo-code support, payer-paid processing fees, and one-time plus recurring payments
  • The key-concepts page defines Copperx around non-custodial wallet settlement, checkout, invoicing, subscriptions, webhooks, test mode, and supported chains / tokens, which is exactly the sort of hosted lifecycle surface that belongs in companies/ once it becomes the practical dependency
  • The checkout-session reference exposes concrete API operations for session creation, retrieval, listing, auto-recovery by transaction hash, and partial-checkout completion, which shows the real control surface is the Copperx-run billing and session state machine rather than a neutral payment standard
  • The authentication page says all API requests require bearer-token authentication managed through the Copperx dashboard, which is a direct signal that merchant admission and credential issuance sit at the operator boundary
  • The docs llms.txt enumerates a surface spanning setup, payment configuration, invoices, subscriptions, webhooks, APIs, payment links, and platform integrations, reinforcing that Copperx is packaging a broader merchant-operations shell rather than one narrow API endpoint
• Whitepaper: No separate company whitepaper is the point here. The strongest primary materials are the official docs corpus, llms.txt, FAQ and key-concepts pages, the linked API reference, and the main site already captured in ../whitepapers/copperx-primary-sources-2026-04-30.md.
• Sources:
  • https://copperx.io/
  • https://docs.copperx.io/
  • https://docs.copperx.io/llms.txt
  • https://docs.copperx.io/getting-started/introduction-to-copperx.md
  • https://docs.copperx.io/getting-started/use-cases-how-you-can-use-copperx.md
  • https://docs.copperx.io/getting-started/key-concepts-and-terminology.md
  • https://docs.copperx.io/support/faq.md
  • https://docs.copperx.io/api-and-reference/authentication-and-security.md
  • https://docs.copperx.io/api-and-reference/checkout-session-api.md
  • https://copperx.readme.io/reference/sessionscontroller_create
  • ../whitepapers/copperx-primary-sources-2026-04-30.md

Internal linkages

• Product-layer alias: copperx.
• Useful adjacent operator-shell comparisons: coinflow, stripe, and exodus.
• More bitcoin-native merchant-software contrast: zaprite and coingate.

Protocol / company boundary

• Keep copperx only as the alias preserved for legacy links.
• Keep this note on Copperx as the named operator that issues credentials, runs the dashboard, hosts checkout and subscription state, defines supported-chain coverage, and signs the webhook-backed merchant lifecycle.
• That split matters because there is no especially useful standalone Copperx protocol layer doing separate analytical work from the company-run merchant workflow shell.

Control surface

• Practical authority sits in API-key issuance, dashboard-managed account access, supported chain and token coverage, checkout-session state, subscription and invoice lifecycle, webhook delivery, refund handling, and the integrations Copperx chooses to normalize.

• Non-custodial does not dissolve the company boundary here. Merchants still inherit a Copperx dependency for billing state, callback truth, recurring-payment workflow, and platform support.

• Read the durable risk as who operates the merchant checkout, billing, and webhook truth shell?, not only as who temporarily holds funds?

• Last reviewed: 2026-08-12 UTC