Cowrie Research

zaprite

4 min read

Zaprite

  • Name: Zaprite
  • URL: https://zaprite.com/
  • Category: bitcoin merchant-operations company / non-custodial checkout and invoicing operator / hosted order, redirect, and webhook workflow shell
  • Tags: bitcoin-ecosystem
  • Summary: Zaprite belongs in companies/ because the meaningful dependency is not a neutral payment rail or even only the checkout product surface. The named operator creates the organization account shell, issues and scopes API keys, controls hosted checkoutUrl behavior, defines webhook retry and delivery semantics, packages invoices / payment links / POS / event tickets around the same order machinery, and sells that merchant workflow on a subscription plan. The practical leverage sits with the company that runs merchant admission, dashboard truth, credential lifecycle, support, and product packaging around a nominally non-custodial wallet handoff.
  • What it does:
    • Operates a hosted merchant stack for orders, checkouts, invoices, recurring invoices, payment links, POS flows, and event tickets
    • Exposes a public API centered on Orders, Contacts, and Webhooks, with organization-scoped bearer-token credentials and versioned /v1 resources
    • Packages redirect-based checkout plus webhook-driven reconciliation as the normal integration path for merchant software
    • Lets merchants connect their own wallets rather than handing custody to Zaprite, while still shaping the order lifecycle and payment-status publication surface around that wallet handoff
    • Offers sandbox organizations, API-key rotation and revocation, help-center-guided onboarding, and a broader dashboard shell for merchant operations
    • Wraps some fiat/card-connected payment experience into the same merchant shell without becoming a neutral settlement rail
  • Key claims:
    • The homepage says Zaprite helps businesses migrate to a bitcoin standard, supports any wallet, and is not a payment processor because payments flow directly into the merchant’s wallet of choice
    • The homepage also says anyone can create an account with just an email address and quotes subscription pricing, which is a strong clue that merchant admission, account lifecycle, and commercial packaging sit inside one company-run shell rather than a neutral protocol
    • The developers page says Zaprite offers a public API and webhook service for custom bitcoin, Lightning, and card-payment flows, which is a cleaner description of the real product than the generic merchant-marketing copy
    • The API llms.txt says Zaprite is a single API for Orders, Contacts, and Webhooks designed for hosted checkout flows: create an order, send the customer to checkoutUrl, and use webhooks to keep the merchant system in sync
    • The same API docs say each API key is scoped to a single Zaprite organization, keys can be created as full-access or read-only, and keys can be rotated or revoked in Zaprite API settings, which makes organization policy and credential issuance part of the live control surface
    • The API docs say Zaprite retries webhook deliveries that do not return 200 responses, which makes delivery semantics and retry behavior part of the operator-controlled workflow truth merchants inherit
    • The help-center taxonomy shows the broader company shell spans Accounts, Organizations, Contacts, Connections, Payment Links, Event Tickets, Invoices, Recurring Invoices, POS, Payment Requests, Checkouts, Orders, Transactions, API, and product updates rather than one narrow accept bitcoin widget
  • Whitepaper: No classic standalone company whitepaper is the point here. The clearest primary materials are the homepage, developers page, API docs, and help-center corpus already captured in ../whitepapers/zaprite-primary-sources-2026-04-30.md, plus a light live refresh of those same first-party surfaces in this pass.
  • Sources:

Internal linkages

Product / company boundary

  • zaprite remains the product-layer note for the hosted order model, checkout redirects, invoice and POS packaging, webhook events, and the wallet-handoff behavior developers integrate with.
  • This company note isolates the operator boundary: Zaprite controls organization creation, API-key issuance and revocation, sandbox access, hosted checkout behavior, webhook retry policy, dashboard/account truth, pricing, support, and the broader merchant-ops shell around that product.
  • That split matters because how does the checkout and order API behave? and which named operator controls merchant access, credentials, and lifecycle publication around that API? are related but not identical questions.

Control surface

  • Practical leverage sits in merchant and organization admission, API-key issuance and privilege level, hosted checkoutUrl behavior, webhook delivery and retry semantics, dashboard truth, connected-wallet and payment-method packaging, and the support/pricing shell around the product.

  • The sticky dependency is not custody of funds. It is that one named company normalizes the order object, redirect flow, webhook publication path, account lifecycle, and surrounding merchant tooling into a single operating perimeter.

  • Read Zaprite as a merchant-operations company first and a hosted checkout product second.

  • Last reviewed: 2026-08-12 UTC

Graph View

Backlinks