Get paid the way your customers build
Let customers pay in USDC from the same wallet they ship contracts with — no card form to fill — and the moment the payment clears it credits your Paymos balance, safe from any freeze.
Where web3 infrastructure billing forces crypto-native customers onto card rails
Why are you charging crypto-native customers a card fee to use crypto tools?
Four ways card-rail billing fights the wallet-native nature of your customers.
Your customer lives in a wallet — and you make them pay with a card
The dev hitting your RPC endpoint already pays in stablecoins, swaps tokens, and signs from a hardware wallet every week. Then your billing page demands a card with a home-country ZIP, and the processor takes its cut on top of the conversion fee the customer already paid to fund that card. You're charging crypto-native customers to use crypto tools, then taxing them again for the privilege of paying you in fiat.
A US-entity requirement locks you in before your first paying customer
To take card payments seriously you typically need a US entity — incorporation costs, a registered agent, and state filings, before the first paying customer. For a founder in Lisbon, Dubai, Singapore, or Tbilisi building a side-project node, that's real compliance overhead up front. Meanwhile the funded incumbents absorb that same fiat dependency as a line item — you're competing against them while carrying it as pure overhead.
Per-request metering on a card stack breaks when free-tier abusers churn
The usual model — a free request tier, then a paid tier — lives inside a card processor's metered billing. Every metered usage record posts to the processor's API, gets aggregated, then billed. When a customer abuses the free tier and walks, you've already paid for the metering calls and there's no rebate. Worse, you can't rate-limit at the billing layer, so abuse propagates into your node fleet before your meter notices.
Token credits and card billing are two ledgers you reconcile by hand
If you also let customers pay in a token for API credits — a common web3 pattern — that flow lives in your DB while card subscriptions live in the processor's. Two ledgers, two reconciliation streams, one doc explaining how revenue is calculated. At audit time the founder spends a week proving the wallet credits and the card invoices add up to what the dashboard says.
How a wallet rail fits wallet-native customers
What changes when the invoice settles from the customer's own wallet?
Four things that go right when web3-tools billing leaves the card rail.
The same wallet that ships contracts pays your invoice — no card intermediary
The customer settles your monthly tier from the same wallet they deploy contracts with — stablecoins in, straight to your treasury. No card-detail entry, no re-authentication, no conversion from one currency to another and back. You receive the asset you wanted in the first place, and the payment credits your Paymos balance the moment it clears, safe from any processor freeze.
Wallet-native checkout — scan and send, no US entity needed
Drop the Paymos checkout into your billing page; the customer scans a QR or taps a deep-link into their wallet and sends. No incorporation, no registered agent, no state filings to take payment. Operate from Lisbon, Dubai, Singapore, or wherever your team actually lives, and accept payment from the global pool of crypto-native devs without needing a US entity to do it.
Per-request usage rolls up at period close into one signed invoice
Your meter aggregates requests in your own DB — the only place that knows what they actually cost you. At period close, Paymos generates a single invoice for the rolled-up amount and the customer pays it from their wallet. Free-tier abuse stays in your DB to handle with rate-limits and revoked keys, not propagated into a processor's metering API where you pay for every overage record. The payment is final on confirmation.
One ledger: stablecoin credits, stablecoin invoices, stablecoin treasury
Token credits, paid invoices, and treasury balance all live in the same wallet-denominated accounting view. The customer tops up in stablecoins, you draw it down per request as they query your service, and the period closes with the remainder rolled forward. One ledger, one wallet, one number — no separate doc reconciling card revenue against your credit table at audit time.
How web3 platforms wire Paymos in
Which integration fits how you bill?
Three ways to take payment on the rails your customers already live on.
Wallet-native checkout — QR and deep-link into the customer's wallet
Drop the Paymos checkout into your billing page. The customer scans the QR or taps a deep-link into MetaMask, Trust, Coinbase, or OKX and sends USDC on Base or Arbitrum. Your backend gets an HMAC-SHA256 webhook on confirmation and unlocks the tier or credits the balance. No card form, no redirect to a fiat processor.
See details
Host-to-host API — per-request rollups from your own meter
Your meter aggregates requests in Postgres or ClickHouse. The host-to-host API lets you generate an invoice for the rolled-up amount at period close, hand it to the customer's wallet, and watch settlement across networks like Base, Arbitrum, or Optimism. HMAC-SHA256 webhooks fire on confirmation, and free-tier abuse stays in your DB to handle with rate-limits, not a processor's metering API.
See details
Payment Links — enterprise RPC contracts and audits
For an enterprise RPC contract or a one-shot audit fee, generate a Payment Link with your contract reference attached as the order reference. The protocol team pays USDC from treasury in a single transfer, your receivable closes on confirmation, and the engagement can close the same day the contract is signed — no cash-out to a bank in between.
See detailsWeb3-tools billing flows on stablecoins today
Which web3 models run cleanly on a wallet rail?
Four flows from real web3-tools setups — RPC, indexers, wallet infra, audits.
RPC providers — node access for dApp devs
Selling RPC and WebSocket endpoints to dApp devs: the customer already transacts in stablecoins to use the networks you serve, so paying you in stablecoins matches their flow exactly. They fund the API the same way they fund their hot wallet — a stablecoin transfer that confirms in seconds and credits your Paymos balance, final the moment it clears. No card-to-stablecoin ramp friction in between.
Subgraph indexers and indexed-data APIs
Indexed query APIs serving dashboards, analytics, and protocol-data products. Customers are protocol teams and data devs who already query for protocol economics, so paying in stablecoins matches their workflow. Tiered pricing settles cleanly from a renewal invoice each cycle, and treasury accumulates the same stablecoin the team also uses for its own costs.
Wallet-as-a-service — per-active-wallet billing
Embedded-wallet platforms charging per active wallet to consumer apps. The customer is an app builder shipping in-app crypto, who already settles their own transactions in stablecoins, so paying for active wallets in stablecoins is the natural rail. Per-wallet usage rolls up each period, the bill arrives as a single invoice, and a renewal invoice handles settlement — final on confirmation.
Smart-contract audits — flat per-audit fee, paid from treasury
Audit shops doing contract reviews and formal verification. The protocol team commissioning the audit is already raising and spending in stablecoins — a fiat off-ramp just to pay an audit fee would add days and a wire fee. A Payment Link or embedded checkout settles the fee from treasury in seconds, the auditor receives stablecoins, and the engagement closes the same day the contract is signed.
Web3 developer tools on stablecoins
Frequently asked questions
Can the customer pay from the same wallet they use for everything else?
Do I need a US entity to start taking payments?
How does per-request metering settle without paying for every overage record?
Which networks and stablecoins do crypto-native customers prefer?
How do token credits and stablecoin invoices stay on one ledger?
How do refunds work for unused credits or a cancelled contract?
Honest disqualifier
When NOT to use Paymos for web3 developer tools
Four cases where cards or another setup are the right call.
Your customers are non-crypto enterprises that pay by card or ACH
If you've moved upmarket to enterprises whose finance teams pay by card or ACH and don't hold a wallet, the wallet rail adds a step for them. The advantage is strongest with crypto-native customers who already live in a wallet. For a book that's gone mostly traditional-enterprise, keep cards or ACH for those accounts and use Paymos for the wallet-native segment.
You want subscriptions that charge themselves
Paymos has no stored mandate and no subscription engine — it cannot pull a renewal from a wallet, and proration, trials, and plan migrations stay in your code. Crypto-native devs tolerate paying an invoice each cycle better than most audiences, but if you want renewals, dunning, and trial conversion handled for you, that's a billing platform's job. Paymos only settles what your engine issues.
You expect the payment layer to stop free-tier abuse
Paymos verifies payments, not people: there's no identity layer, no device fingerprinting, no sybil detection. A farm of throwaway keys hammering your free tier looks the same to the rail as a paying customer. Rate limits, key revocation, and abuse heuristics stay yours to build — if you were counting on a processor's fraud stack to do that work, this rail won't.
Your runway is spent in fiat and you don't want a cash-out routine
Settlement is stablecoin to your Paymos balance — Paymos has no fiat payout. If salaries, servers, and rent leave a bank account, someone on the team owns a recurring exchange step. Most web3 teams already run one for their own treasury; if yours doesn't and doesn't want to, card revenue that lands as a bank deposit may be worth its fee.
Related flows
Other SaaS & Digital Products sub-niches on Paymos
Pricing
1.0% per settled invoice. Wallet customers, wallet rail
Same rate for the hobbyist tier and the enterprise RPC contract, at any size. High-volume tier at 0.3% on request. Card billing runs about 3% all-in, and a crypto-processor's teaser headline rate climbs well past it once swap, transfer, and merchant-paid network costs are added in.
See pricing