Cowrie Research

strike

4 min read

Strike

  • Name: Strike
  • URL: https://strike.me/
  • Category: bitcoin-and-cash payments operator / Lightning settlement and payout company / dashboard-and-OAuth money-movement control plane
  • Tags: bitcoin-ecosystem
  • Summary: Strike belongs in companies/ because the durable dependency is not only a developer-facing payment API. It is a named operator that decides business onboarding, owner/operator verification, dashboard access, API-key issuance and revocation, OAuth permission grants, which banking and payout services are live in supported regions, and what service-status truth integrators inherit when money movement breaks. The useful question is not just how do I create invoices or send dollars over Lightning? but which company controls the account, credential, payout, and operational shell around that workflow?
  • What it does:
    • Operates Strike accounts for individuals and businesses through the Strike app and Strike Dashboard rather than exposing a neutral unaffiliated payment rail
    • Runs business onboarding that verifies business information, documents, and the identities of owners and operators before API use or broader business activity
    • Issues dashboard-managed API keys with operator-selected scopes for financial actions such as invoice creation and quote generation
    • Packages OAuth-based third-party access, example-app patterns, and account-linked payment workflows under the same company-run account shell
    • Exposes multiple live operating surfaces including Banking Services, Lightning payments, onchain bitcoin payments, withdrawals, onboarding and KYC, the Strike API, Strike OAuth Connect, and the Strike Dashboard
    • Packages cash balances, bitcoin balances, Lightning settlement, and bank-payout-adjacent workflow into one company-managed money-movement environment
  • Key claims:
    • The account overview says businesses must sign up through the Strike Dashboard, provide business information and documents, verify owners and operators, and only then gain access to deposit cash, buy bitcoin, and make transactions, which is unusually explicit evidence that the company boundary matters
    • The API-key overview says keys are created inside the Strike Dashboard, can be given named scopes for operations such as invoice creation or quote generation, never expire by default, and can perform financial transactions, which makes credential issuance and revocation a real control surface
    • The walkthrough overview says Strike lets applications send and receive dollars over the Lightning Network without direct bitcoin custody or price exposure, reinforcing that the company is packaging a managed money-movement shell rather than only publishing sample code
    • The example-apps page shows first-party patterns for invoice links, split bills, URL paywalls, in-person checkout, and OAuth integrations, which is strong evidence that Strike wants integrators to treat its account and permission model as reusable application infrastructure
    • The public status page breaks service truth out into Banking Services, Bitcoin Payments: Lightning, Bitcoin Payments: On-Chain, Bitcoin Withdrawals, Buy Bitcoin, Exchange Rates, Onboarding & KYC, Send Globally, Strike API, Strike OAuth Connect, and the dashboard, which makes the company-run operational perimeter legible in a way a pure protocol note cannot
  • Whitepaper: No classic standalone company whitepaper is the important artifact here. The clearest primary materials are the official account, API-key, walkthrough, example-app, and status pages; the broader source bundle remains ../whitepapers/strike-primary-sources-2026-05-01.md.
  • Sources:

Internal linkages

  • Product-layer note: strike.
  • Useful adjacent company reads: river, ibex, and lightspark.
  • Merchant-stack contrast where the question is the product surface more than the company shell: btcpay-server.

Protocol / company boundary

  • strike should stay on the merchant- and developer-facing product surface: invoices, quotes, OAuth flows, dashboard-linked integration patterns, and the account-level payment actions an integrator directly builds against.
  • This company note isolates the broader operator shell above that product: business approval, owner/operator verification, dashboard and credential issuance, OAuth permissioning, banking and payout-service availability, service-status publication, and the legal/operational environment users inherit when they route money through Strike.
  • That split matters because the dependency most integrators inherit is not a neutral Lightning standard. It is a company-managed workflow graph spanning account approval, credentials, payment routing, and operational truth.

Control surface

  • Practical leverage sits in business onboarding, supported-region policy, owner/operator verification, dashboard access, API-key scope design, key revocation, OAuth permission grants, service availability across banking and payout surfaces, and the status page or support channels users trust during outages or disputes.

  • The sticky dependency is operational memory: once a product hardens around Strike-managed account state, scoped credentials, OAuth permissions, payouts, and service-status truth, the real lock-in is to the company-run money-movement shell rather than only to Lightning invoice semantics.

  • Read Strike as a company-operated account, credential, and payout boundary first, and as a reusable payment API second.

  • Last reviewed: 2026-08-08 UTC

Graph View

Backlinks