I run a small paid newsletter hosted on a .onion address. Getting paid anonymously on Tor sounds simple in theory - Bitcoin is pseudonymous, Tor provides network anonymity, done. In practice, building the infrastructure to accept payments, confirm transactions, and deliver content automatically is a real engineering project. BRO PAY handles all of that as a service. Here's what it looks like from the inside after two months of real usage.
What BRO PAY Actually Does
BRO PAY is a Bitcoin payment gateway built for Tor-hosted services. It runs a full Bitcoin Core node, generates unique receiving addresses per payment, monitors confirmations, and triggers webhooks when a payment completes. It also offers an embeddable payment widget (iframe) so users can pay without leaving your .onion site.
You interact with it through a REST API or through the embed widget. The API approach gives you full control. The embed widget requires almost no backend code.
Getting Started
Registration at bro-pay.xyz is the same minimal process as the rest of BRO NETWORK - username and password, no other information required. Once in, you create a wallet (links to a Bitcoin Core receiving address), generate an API key, and you're ready to integrate.
The dashboard shows your wallet balance, recent transactions, and API keys. It's straightforward - no unnecessary complexity for a payments interface.
The Embed Widget
For projects where you don't want to write backend payment code, the embed widget is the path of least resistance. You get a URL like:
https://bro-pay.xyz/embed/pay?api_key=YOUR_KEY&wallet_id=YOUR_WALLET&amount=0.001
Drop that in an iframe on your page. The widget shows a QR code and Bitcoin address, polls for payment confirmation, and when confirmed - shows a success state. You configure a webhook URL where BRO PAY sends a POST request with payment details when confirmation happens.
For my newsletter, the flow is: user clicks "Subscribe," iframe loads, user pays, webhook fires, my server sends them the confirmation and access link. The whole thing took about 4 hours to build, mostly because I spent time reading the webhook documentation carefully.
The REST API
The API is clean and does what you expect:
| Endpoint | Purpose |
|---|---|
| POST /api/v1/payments | Create a payment request, get a Bitcoin address and amount |
| GET /api/v1/payments/{uuid}/check | Poll payment status manually |
| Webhook POST | Receive notification when payment confirms |
Creating a payment:
POST /api/v1/payments
{
"wallet_id": 3,
"amount_usd": 5.00,
"callback_url": "https://myonionsite.onion/payment-confirmed"
}
Response includes the BTC amount calculated at current rate, the receiving address, and a payment UUID for tracking.
Webhook payloads are signed with HMAC-SHA256 using your API key. Verifying the signature is a few lines of code and prevents fake payment notifications.
Gift Cards
BRO PAY has a gift card feature - pre-funded cards that users can redeem for credit. This is useful for services that want to let users buy anonymously in advance without a per-transaction flow. I haven't used this feature extensively but the interface for it works correctly in testing.
Payment Reliability
Over two months, I processed payments through the service and had no cases of confirmed payments not triggering webhooks. The Bitcoin node stays synced and confirmation times are what you'd expect from mainnet Bitcoin (10-60 minutes depending on mempool conditions and how many confirmations you require).
One thing to note: BRO PAY generates a unique address per payment, not a shared address. This matters for privacy - different payers can't correlate payments to the same destination.
What I Would Change
- No Lightning Network support - on-chain Bitcoin means fees and delays during congested periods
- No Monero support - for truly fungible anonymous payments, XMR would be ideal
- The dashboard doesn't show webhook delivery status - I had to log it myself to confirm webhooks were firing
- Documentation could have more code examples in different languages (currently mostly pseudocode)
The Security Model
BRO PAY holds your funds in a wallet managed by the service. This is custodial - the service controls the private keys. You withdraw to your own wallet when you want to access funds.
This is the standard model for hosted payment processors and is worth being clear-eyed about. If you need non-custodial, you'd have to run your own Bitcoin node and payment infrastructure. BRO PAY trades custody for simplicity and convenience. For the transaction volumes I was handling, that tradeoff made sense.
Final Verdict
BRO PAY solves a real problem: accepting Bitcoin payments on a Tor hidden service without running your own node infrastructure. The API is well-designed, the embed widget works without backend complexity, and webhook reliability has been solid in two months of production use. The custodial model and Bitcoin-only support are genuine limitations that matter depending on your requirements. For Tor-native projects that need a payment layer without heavy infrastructure investment, it's currently the most practical option in the BRO NETWORK ecosystem.
The integration I built is still running. Payment works, webhooks fire, subscribers get their content. That's the outcome I needed.
BRO PAY is at bro-pay.xyz and accessible through Tor.
Top comments (0)