Flash
Flash is the business layer around Bitcoin payments: checkout tools, store flows, subscriptions, integrations, treasury visibility and wallet connections that let a merchant receive without treating Flash Wallet as the whole product.
Flash is the platform, Flash Wallet is the wallet
The first thing to keep straight is the product boundary. Flash Wallet is the mobile wallet that a merchant can install on iOS or Android. Flash is the business platform around that wallet and around other compatible wallets. The platform creates payment links, store pages, point-of-sale flows, subscription checkouts, integrations and API events. The wallet is where money can land. The platform is where a business sets up the transaction surface.
That distinction is not pedantic. If you evaluate Flash only as a wallet, you miss most of what a merchant actually uses. If you evaluate Flash only as a checkout page, you miss the custody and wallet-connection model that determines who controls funds. A small business owner needs both views at once: what the customer sees at checkout, and what happens after the invoice is paid.
Flash belongs in the commerce layer because its strongest documented use is business operations. The homepage now presents Flash as a Bitcoin treasury operating layer with wallets, exchanges, fiat payment rails, labels, cost basis, accountant exports and payments in one place. That is a different promise from a standalone Nostr client. It is closer to payment operations software for businesses that want Bitcoin in the workflow without turning every employee into a Lightning node operator.
The operator and public footprint
Public app-store records list Flash Lightning Solutions Inc. as the developer of Flash Wallet, and Flash's own website and documentation use the same brand for the payments platform. Public company coverage describes Flash as a Bitcoin payment gateway co-founded by Pierre Corbin and Hugo Ferrer, built to help businesses accept Bitcoin online and offline. That gives readers a clearer operator trail than a pseudonymous side project, even if the product itself still needs normal vendor diligence.
Flash's public footprint is heavier on product pages, docs, app-store listings, blog posts and partner announcements than on open-source code. That matters when you decide how much trust to place in it. A merchant can read the docs, test the app, inspect the user flows and contact the company, but cannot treat the platform as fully public infrastructure unless Flash publishes the relevant service code, reproducible mobile builds and detailed custody architecture.
The company narrative has also shifted over time. Earlier public language emphasized a Bitcoin payment gateway for merchants. The current homepage pushes a broader treasury layer: connect wallets and exchanges, label transactions, track cost basis, invite accountants and route payments. For a reader, that means Flash is not only about accepting a Lightning invoice at checkout. It is trying to own the operational layer after payment acceptance too.
Why the Nostr connection matters here
Flash's Nostr relevance comes through Nostr Wallet Connect, not through posting notes, following accounts or running a social feed. NWC, described in NIP-47, lets an app communicate with a Lightning wallet through Nostr relays. The app can request actions such as paying an invoice, while the wallet service listens on the relay, decrypts requests and returns responses. The user's ordinary social identity key does not need to be the payment identity.
That design fits Flash's product shape. A merchant creates a checkout, subscription, store or point-of-sale flow in Flash. Flash needs a way to route payment actions to a wallet without holding the merchant's funds. NWC gives the platform a standard connection string and relay-based transport instead of a separate custom integration for every wallet. The Flash docs are explicit that Flash can only be used with wallets supporting Nostr Wallet Connect, and they name Flash Wallet, Coinos and Alby as compatible choices.
For the merchant, an NWC connection string should be treated like a live payment credential. It may include relay information, keys and permissions that let the connected app request wallet actions. The practical advice is simple: create a dedicated wallet connection for Flash, scope permissions and budgets where the wallet allows it, test with small amounts, revoke connections that are no longer needed, and never paste an NWC string into a page you have not verified.
Payment links are the simplest product surface
Flash Payment Links are the easiest entry point because they do not require a full store or custom integration. The docs present them as customizable URLs that can define a default price, optionally allow the payer to choose an amount, and be shared directly or embedded into buttons. For a freelancer, donation page, small service invoice or event payment, that can be enough to start accepting Bitcoin without rebuilding a website.
The important operational line in the docs is that payments are routed directly to the selected wallet. That is the commerce promise behind Flash: the checkout page should not become a custodial holding account. The business chooses a wallet, creates the link, sends it to the payer, and then checks that the wallet and Flash dashboard agree on the result.
You should still run a complete payment drill before using links publicly. Create a tiny fixed-price link, pay it from a separate wallet, confirm the invoice, inspect the transaction record, test the payer experience on mobile, and see what happens if a payer opens the link twice or abandons it. Payment links feel simple, but they still create customer support questions around expired invoices, wrong amounts, duplicate attempts, receipts and refunds.
Point of sale brings Flash into physical commerce
The point-of-sale docs are aimed at physical businesses or manual transactions. Flash describes a POS flow that can connect multiple wallets, accept payments in Bitcoin or satoshis, calculate totals including taxes where applicable, and switch between a basic calculator mode and product-selection mode. That makes Flash relevant to a cafe, pop-up shop, brewery, event table or retail counter where a cashier needs to create an invoice quickly.
A POS product has different risk from a web checkout. The staff member may be under time pressure, the customer may be standing in front of them, the network may be weak, and the business needs to know whether the payment is final before handing over goods. Flash's POS flow should therefore be tested at the counter, on the device and network that will actually be used, with receipt printing, tax treatment and wallet notifications checked before a busy day.
The App Store release history for Flash Wallet is useful here because it mentions point-of-sale integration improvements, receipt printing, NFC support for Boltcards and fixes around Nostr login. That does not prove every deployment is mature, but it shows that the wallet and platform are being worked on around real retail flows. A merchant should still keep a fallback QR wallet ready until the Flash POS path has survived normal store conditions.
Hosted stores and product pages
Flash also documents hosted stores. The idea is straightforward: add products, let Flash combine them into a shareable storefront, and give customers a place to browse and purchase multiple items. The docs mention unique store URLs, embeddable URLs and product categorization. For a small creator or merchant with a limited catalog, this is a lighter path than building a full e-commerce site first.
Hosted stores are useful when the merchant wants to test demand before investing in a full storefront. They also concentrate operational questions in one place: product names, stock status, shipping notes, tax, refunds, customer communication and the wallet that receives payment. Bitcoin checkout removes card chargebacks, but it does not remove the need to deliver goods and handle support clearly.
The right test is not just whether a product page renders. Add a product, create the store, buy from another device, inspect the customer-facing confirmation, confirm wallet receipt, export or record the transaction, then change the product or price and see how old links behave. A hosted store is still a live sales surface, so the merchant should learn its edge cases before linking it from public social posts or newsletters.
Subscriptions are where records matter
Flash Subscriptions add recurring payments to the stack. The docs describe subscription plans, checkout page URLs, pre-filled user data such as email, Nostr ID or external UUID, API authentication, status retrieval, cancellations and webhook events for sign-ups, renewals and payment failures. This is more complex than a one-time payment because the business needs to map money to access over time.
Recurring Bitcoin payments can be attractive for memberships, communities, SaaS access, newsletters, media paywalls, coaching, support plans and creator revenue. They also expose the hardest accounting and support problems. A user can pay from one wallet, change identity, miss a renewal, request cancellation, or claim that access was not granted after a successful payment. Flash's subscription tools are only as good as the merchant's state machine around them.
If you use Flash Subscriptions, design for idempotency from day one. A webhook may be retried. A user may click twice. A payment failure may arrive after access has already changed. Store the Flash event ID or transaction reference, process each event once, log the raw payload safely, and build an admin screen that lets a human reconcile a customer without guessing from wallet notifications alone.
Webhooks and APIs make Flash developer-facing
The API documentation is narrower than a full public payments API reference, but it shows the developer direction. Flash says authentication is currently set up for subscription APIs, with valid authorization tokens in headers and JWTs signed with the secret key associated with the Flash account. The webhooks page describes event notifications, payloads, JWT-secured delivery, handler behavior and examples in several languages.
The webhook guidance matters because this is where Flash stops being a dashboard and becomes part of a product backend. A subscription app needs to know when a user signs up, renews, fails payment or cancels. A media paywall needs to unlock content. A membership site needs to extend access. A marketplace needs to update an order. None of that should depend on a human watching a wallet app.
Treat the API and webhook layer like any other payment integration. Use HTTPS, verify JWTs, return success only after durable processing, make handlers idempotent, keep secrets out of source control, separate test and production accounts, and monitor failures. Flash can simplify Bitcoin payment acceptance, but it cannot remove the software engineering responsibility that begins when payment state enters your own system.
WooCommerce, Shopify and Wix are not the same integration
Flash documents several e-commerce integrations, but they do not all have the same maturity or installation path. WooCommerce is described as a plugin flow where the merchant downloads a zip file from the dashboard, installs it in WordPress, configures an API key and enables Flash as a Bitcoin payment method. That is familiar territory for merchants already running WooCommerce.
Shopify is different. The docs say the Shopify integration requires custom setup because of Shopify's custom-app requirements, including use of a Shopify Partner Account and a short onboarding call with the Flash team. Wix is also documented separately. The practical reading is that Flash can support multiple store stacks, but not every path is self-service in the same way.
Before choosing Flash for an existing store, run the integration that matches your actual platform. Do not assume WooCommerce instructions apply to Shopify, or that a demo call means production support for every checkout edge case. Test taxes, order statuses, abandoned carts, refunds, email receipts, wallet settlement, API key rotation and how the store behaves when a Lightning invoice expires.
Treasury changes the product category
Flash's current homepage and Treasury page make a broader claim than payment acceptance. They describe connecting wallets, exchanges, custodians and fiat rails; showing real-time balances; tracking FIFO cost basis; surfacing realized and unrealized profit and loss; giving teams role-based access; giving accountants read-only access; and exporting full transaction history with the BTC price at the time.
That treasury shift is important. Many Bitcoin payment tools stop once an invoice is paid. Businesses do not. They need to know where funds went, what value was received, which wallet holds operational balance, what should be swept, who can see records, what the accountant needs, and how Bitcoin exposure affects the business books. Flash is positioning itself in that messy middle between wallet, checkout and accounting.
You should judge the treasury feature set with accounting reality in mind. Does the export match your jurisdiction's tax needs? Can labels be corrected? Are exchange imports reliable? Can accountant access be limited? Does FIFO match your chosen method? Does the dashboard distinguish BTC, L-BTC, Lightning balances, fiat payments and card or ACH rails? A treasury dashboard is useful only if it does not hide the assumptions that matter later.
Fiat rails widen the scope
The Payments product page says Flash can send invoices in fiat and Bitcoin, accept ACH, credit card, Lightning and on-chain payments, and connect those payments to treasury visibility. It describes ACH and card support as United States only. That is a different product surface from a Bitcoin-only link and should be evaluated with the additional compliance, partner and settlement dependencies that fiat rails introduce.
This wider scope may be useful for businesses that cannot go Bitcoin-only overnight. A merchant might accept Lightning from Bitcoin-native customers, on-chain payments for larger invoices, ACH from U.S. clients and cards from customers who are not ready for Bitcoin. If those flows land in one treasury view, Flash becomes more of an operating layer than a niche checkout widget.
It also means the trust and dependency model changes. Direct wallet settlement through NWC is one thing. ACH and card processing involve payment partners, rules, chargebacks, identity, banking availability and regional limits. A business should ask which entity processes each rail, what fees apply, who handles disputes, when funds are available, and whether the product is appropriate for its country, industry and volume.
Flash Connect points at embedded platforms
Flash Connect is the platform-facing product. The product page describes one OAuth integration that lets another platform embed Bitcoin and fiat payments, treasury visibility, labeling and settlement flows without holding customer funds. The documented flow is: register the platform, get API keys, redirect users to Flash to create accounts and connect wallets, then create payments through the API and receive webhooks on completion.
That matters for marketplaces, creator platforms, membership platforms, agencies, SaaS products and merchant-service providers that want Bitcoin payment features inside their own product. Instead of each platform building wallet connection, checkout, subscriptions, webhooks and treasury records from scratch, Flash wants to provide the payment and treasury layer while the platform owns the customer relationship.
The due diligence bar is higher for embedded use. If you expose Flash inside your own platform, your users will experience Flash failures as your failures. Check OAuth flows, account creation, wallet connection, webhook completeness, support escalation, branding, data ownership, offboarding and what happens if Flash changes pricing or API behavior. Embedded payments are sticky, so the exit path should be considered before launch.
Fees, custody and the small transaction after payment
The documentation homepage explains Flash's fee model in an unusual way: when a payment is completed, the merchant's wallet initiates a small transaction to pay Flash its fee. That is consistent with the idea that Flash does not hold the merchant's funds first and then subtract a platform fee from custody. It also means the merchant should understand what the wallet is being authorized to do.
This is exactly where NWC permissions matter. If a wallet connection can pay invoices automatically, the platform can request fee payments or other actions within whatever limits the wallet permits. That can make the experience smooth, but it must be visible enough that a business can reconcile gross sales, net receipts, network fees and Flash fees. A payment platform that feels non-custodial still needs transparent fee accounting.
Run a fee audit before production. Create a test sale, note the customer amount, inspect the wallet receipt, identify any platform fee transaction, record network fees, and compare the Flash dashboard with wallet history. If the business uses a connected wallet for many workflows, separate labels or connections can help avoid the classic operations problem: money moved correctly, but nobody can explain it three months later.
Liquid and Lightning should not be flattened
Flash Wallet's own self-custody article says the wallet is self-custodial within the Liquid Network, that users hold private keys for L-BTC, and that L-BTC is not directly Bitcoin but can be swapped into Bitcoin. It also says Flash leverages Liquid to manage Lightning transactions. That is a useful level of specificity because it avoids the loose phrase "self-custodial Bitcoin" doing too much work.
For the Flash platform article, the lesson is broader than the wallet. A merchant using Flash should know which rail is involved at each step. Customer checkout may look like Lightning. The wallet balance may involve Liquid. The treasury dashboard may show Bitcoin, L-BTC, fiat and card or ACH payment states. A business cannot manage risk well if all of those are mentally collapsed into one generic "BTC received" label.
This does not make Flash unusable. Liquid may be practical for a spending and receiving wallet, especially when the goal is fast business payments rather than long-term cold storage. It does mean meaningful balances should have a sweep policy, a tested withdrawal path, and an accounting distinction between base-chain BTC, Lightning receipts, Liquid assets and fiat rails.
Security checks before a real launch
Flash should be tested like payment infrastructure because it touches revenue, wallet permissions, customer access and accounting records. Start with a dedicated wallet, not the owner's long-term savings wallet. Give Flash the minimum permissions and budget that your wallet supports. Use a small test balance. Confirm that you can revoke the NWC connection and that new payment requests stop working after revocation.
Then test the customer path. Create a payment link, a POS charge, a store order and a subscription if those are part of your business. Pay each from a separate wallet, inspect the resulting Flash records, compare them with wallet history, export records, and intentionally trigger a failed or abandoned payment. If the product uses webhooks, simulate duplicate delivery and delayed delivery before customers depend on access updates.
Finally test the human process. Who receives notifications? Who can log into Flash? Who can connect wallets? Who can see accountant exports? What happens if an employee leaves? What happens if the phone with Flash Wallet is lost? A non-custodial payment tool can still create business risk through weak internal permissions, undocumented recovery steps or a dashboard only one person understands.
What Flash is good for
Flash is most compelling for businesses that want to accept Bitcoin without running a full custom payment stack. A freelancer can use a link. A small shop can test POS. A creator can test donations, paywalls or subscriptions. A WooCommerce store can test a plugin. A platform can consider Flash Connect if it wants embedded wallet-connected payments and webhooks without custodying customer funds.
It is also interesting for businesses that already own or receive Bitcoin and are starting to feel the operational pain. Payment acceptance is only the first week of the problem. After that come labels, exports, cost basis, accountant access, treasury policy, team roles and wallet separation. Flash's current product direction recognizes that Bitcoin businesses need operations software, not only QR codes.
The best fit is active operating money, not cold treasury savings. A business can use Flash for payment collection, records and workflow while sweeping larger balances to a separate custody policy. That separation keeps the convenient receiving layer from becoming the only place the business holds funds.
Where Flash has limits
Flash has several public limits a reader should not ignore. The platform is not presented as open-source infrastructure. Some integrations are not fully self-service. Fiat rails are regional and partner-dependent. The mobile wallet's Liquid-based custody model carries different assumptions from base-chain self-custody. NWC convenience can become a wallet-permission risk if budgets and revocation are not handled carefully.
The docs are useful, but they are also product docs. They do not answer every question a finance team will have about settlement timing, dispute handling, tax treatment, exports, data retention, user roles, incident response or API stability. Those questions become more important as volume rises. A merchant doing occasional small payments can tolerate more uncertainty than a business routing payroll, subscriptions or large invoices.
You should also be careful with naming collisions. There are other companies called Flash Payments in traditional finance and cross-border payments. The Nostr and NWC ecosystem entry here is the paywithflash.com Bitcoin payment and treasury platform, not the Australian Flash Payments cross-border infrastructure company. Always verify the domain, docs and app developer before connecting a wallet or entering business data.
How to evaluate Flash responsibly
Begin with the narrowest workflow you actually need. If you only need one-off payments, test payment links before stores and subscriptions. If you run a physical shop, test POS at the counter before publishing online store pages. If you run memberships, test subscription webhooks before inviting paying users. A focused test reveals more than clicking through every product page once.
Keep a written acceptance checklist. It should include wallet connected, first payment received, fee transaction understood, export reviewed, refund or support policy drafted, webhook verified, NWC revocation tested, backup path documented and employee roles set. The checklist sounds boring until it prevents a paid customer from being locked out or a sale from becoming impossible to reconcile.
The healthy verdict is neither hype nor dismissal. Flash is a real Bitcoin business payment and treasury platform with a meaningful NWC connection. It can reduce checkout friction and help a business see its Bitcoin operations in one place. It still asks the reader to understand NWC credentials, Liquid and Lightning tradeoffs, integration maturity, fee flows and the difference between a nice checkout demo and production money operations.
Sources worth opening
Open the Flash homepage, Flash product pages, Flash documentation, wallet connection docs, payment-link and point-of-sale docs, subscription API pages, NIP-47/NWC references, app-store listings, and public company announcements before depending on Flash for business revenue.
- Flash official website
- Flash Treasury product page
- Flash Payments product page
- Flash Connect product page
- Flash documentation index
- Flash Connect Your Wallet documentation
- Flash payment links documentation
- Flash donation widget documentation
- Flash subscriptions documentation
- Flash point-of-sale documentation
- Flash hosted store documentation
- Flash WooCommerce documentation
- Flash Shopify documentation
- Flash Wix documentation
- Flash API authentication documentation
- Flash subscription webhooks documentation
- Flash Wallet beta announcement
- Flash Wallet self-custody explanation
- Flash Nostr Wallet Connect article
- Flash guide to integrating NWC into an app
- Flash guide to integrating NWC into a wallet
- Flash Wallet Apple App Store listing
- Flash Wallet Google Play listing
- Nostr Wallet Connect official site
- NIP-47 Nostr Wallet Connect specification
- Alby developer guide to NWC
- OpenSats Nostr Wallet Connect topic
- getAlby awesome-nwc project list
- Flash seed round announcement
- Flash Parallel Economy partnership announcement
- Bitcoin News coverage of Flash and Bitcoin Only Brewery
- Newswire funding coverage for Flash
- citybiz Flash funding coverage
- The Bitcoin Manual NWC risk analysis
- Flash NWC relay endpoint
