Zaprite

• Name: Zaprite
• URL: https://zaprite.com/
• Category: merchant checkout and invoicing shell / hosted order and webhook middleware / non-custodial wallet handoff
• Tags: bitcoin-ecosystem
• Summary: Zaprite at the project layer is the hosted merchant-checkout and order-workflow surface inside a broader Zaprite company shell. The useful product cut is order creation, checkout redirects, webhook reconciliation, invoicing, and POS / event-ticket packaging; the wider operator boundary now lives in zaprite, which is the cleaner place to reason about organization accounts, API-key lifecycle, pricing and support, and the hosted workflow truth merchants inherit.
• What it does:
  • Runs hosted checkout and payment-link flows for Lightning, onchain bitcoin, and some fiat/card-connected merchant flows
  • Exposes API resources for orders, contacts, and webhooks so merchants can build their own checkout and reconciliation paths
  • Packages invoices, recurring invoices, payment requests, event tickets, and POS flows around the same hosted order machinery
  • Uses redirect-based checkout plus webhook events as the normal integration pattern
  • Lets merchants connect their own wallets rather than handing custody to Zaprite
• Key claims:
  • Zaprite is clear about the posture: it is merchant software, not the money holder
  • The product surface is broad, but most of it reduces to the same control points: order creation, checkout handoff, connected-wallet defaults, webhook truth, and organization/API-key policy
  • The API docs matter more than the branding because they show a real merchant-integration stack with sandboxing, scoped credentials, versioned resources, and hosted checkout flow assumptions
  • The extra ticketing, invoice, and POS features are packaging around that merchant middleware core
• Whitepaper: No canonical standalone Zaprite whitepaper or litepaper surfaced in this pass. The clearest current source of truth is the official site, developers page, API docs, llms.txt, and help-center corpus; see ../whitepapers/zaprite-primary-sources-2026-04-30.md.
• Sources:
  • https://zaprite.com/
  • https://zaprite.com/developers
  • https://api.zaprite.com/
  • https://api.zaprite.com/llms.txt
  • https://api.zaprite.com/openapi.json
  • https://help.zaprite.com/
  • https://help.zaprite.com/en/collections/10412605-api
  • https://help.zaprite.com/en/collections/10334945-point-of-sale-pos
  • https://www.npmjs.com/package/@zaprite/api

Internal linkages

• Company boundary for the broader merchant-account, credential, pricing, and support shell: zaprite.
• Best self-hosted merchant-stack contrast: btcpay-server.
• Closest hosted-operator peers once the question is merchant workflow rather than the bitcoin rail itself: opennode and anypay.

Product / company boundary

• Keep this note on the hosted merchant-workflow product surface: order creation, checkoutUrl generation, redirect handoff, connected-wallet flow, webhook reconciliation, invoices, POS, event tickets, and other packaging around the same checkout machinery.
• Use zaprite when the sharper question is who creates the organization account, issues and revokes API keys, sets pricing and support posture, controls the dashboard shell, and becomes the source of hosted workflow truth merchants actually depend on.
• That split matters because Zaprite is not only a Bitcoin-friendly checkout UX. It is a merchant middleware product nested inside a named operator boundary for credentials, billing, support, and lifecycle publication.

Control surface

• At the product layer, power sits in order creation, checkoutUrl generation, redirect behavior, connected-wallet handoff, webhook truth, invoice/POS/event-ticket packaging, and which merchant workflows Zaprite keeps inside its own hosted surface.

• For the wider operator shell around organization accounts, API-key issuance and revocation, pricing, support, and dashboard truth, read zaprite.

• Read it as hosted merchant middleware. The bitcoin standard story is branding over that.

• Last reviewed: 2026-08-12 UTC