Loading...
Loading...
Not marketing claims. Specific, technical, verifiable differences between Payvra and the payment gateways you are evaluating. Fee structures, webhook security, API design, settlement speed.
Every competitor advertises a headline rate. The effective cost after conversion spreads, network markups, and withdrawal fees is always higher.
0.5% flat, no conversion spread, no hidden markup
Type your monthly crypto volume and see exactly how much each competitor is taking after their hidden conversion spreads, network markups, and withdrawal fees clear.
USD per month · $50.0K
Per-asset withdrawal schedule plus an undisclosed quoted-vs-executed spread at payout time.
Network gas only, no provider markup on outbound transactions.
ERC-20 settlement gas billed at a provider-set tier rather than the metered network cost.
ERC-20 gas billed at the metered network rate, not a vendor tier.
TRC-20 USDT withdrawals carry a per-transaction markup over the standard ~$1 network fee.
TRC-20 transfers cost ~$1 in network energy, no provider markup.
Per-asset withdrawal fee plus a chain-congestion markup that is not surfaced at quote time.
Network gas only, no provider markup on outbound transactions.
ERC-20 gas markup absorbed into a vendor-set settlement rate rather than a passed-through network fee.
ERC-20 gas billed at the metered network rate, not a vendor tier.
TRC-20 withdrawals add a fixed asset fee on top of TRON network energy and bandwidth.
TRC-20 transfers cost ~$1 in network energy, no provider markup.
Network fee plus a per-asset markup; legacy invoice flow gates withdrawals to bank settlement cycles.
Network gas only, no provider markup on outbound transactions.
Same per-asset withdrawal markup applied even on cheap-gas chains where the fee floor is far below cost.
Network gas only, pass-through, no settlement spread.
Pre-modern-stablecoin fee model; ERC-20 gas markup baked into the settlement spread rather than itemized.
ERC-20 gas billed at the metered network rate, not a vendor tier.
Outbound moves out of Coinbase are billed by the Coinbase platform fee schedule, not the BTC network rate.
Network gas only, no provider markup on outbound transactions.
ERC-20 transfers tied to the Coinbase exchange fee schedule when funds leave the Coinbase ecosystem.
ERC-20 gas billed at the metered network rate, not a vendor tier.
Native to Coinbase, but moving USDC out hits Coinbase retail spreads on top of the network gas cost.
Settlement at network gas; no vendor spread on USDC outbound.
Network fee plus a marketplace surcharge added at settlement, with the markup hidden inside the executed rate.
Network gas only, no provider markup on outbound transactions.
Layered marketplace fee compounds with the currency-conversion step at withdrawal, beyond network gas.
Network gas only, same metered pass-through as Bitcoin.
ERC-20 settlement gas pulled at marketplace rate rather than the live network rate visible on chain.
ERC-20 gas billed at the metered network rate, not a vendor tier.
Network gas only, but channel rebalancing and full-node uptime are operator-borne costs.
Network gas only, no provider markup on outbound transactions.
Network gas only, same operator-managed infrastructure caveats as Bitcoin.
Network gas only, same metered pass-through as Bitcoin.
Lightning channel funding and rebalancing routing fees fall on the merchant operator.
First-party Lightning support, Payvra absorbs channel rebalancing.
Computed from each competitor's effective fee, advertised rate plus documented hidden markup. No support contract, no rate negotiation, no surprise spreads on Payvra.
Webhook security, API architecture, error handling. The implementation details that determine whether your integration survives production.
Every webhook is signed with HMAC-SHA256 using a per-merchant secret. Replay protection via timestamp validation.
RESTful with OpenAPI spec. Typed SDKs for TypeScript, Python. Cursor-based pagination. Consistent error schema.
REST endpoints with inconsistent naming. No OpenAPI specification. Limited filtering and no cursor pagination.
Machine-readable error codes with human descriptions, docs links, and suggested remediation.
Generic HTTP status codes with minimal error detail. No machine-readable error codes. Debugging requires support contact.
Every webhook is signed with HMAC-SHA256 using a per-merchant secret. Replay protection via timestamp validation.
RESTful with OpenAPI spec. Typed SDKs for TypeScript, Python. Cursor-based pagination. Consistent error schema.
REST with form-style payloads in places. No OpenAPI spec. Inconsistent casing across resources. No first-party typed SDKs.
Machine-readable error codes with human descriptions, docs links, and suggested remediation.
HTTP status with string `message` fields. No structured error code taxonomy and limited remediation guidance in docs.
Every webhook is signed with HMAC-SHA256 using a per-merchant secret. Replay protection via timestamp validation.
RESTful with OpenAPI spec. Typed SDKs for TypeScript, Python. Cursor-based pagination. Consistent error schema.
Invoice-based model from 2013 era. REST with non-standard patterns. Heavy use of server-rendered redirects instead of API-first flows.
Machine-readable error codes with human descriptions, docs links, and suggested remediation.
HTTP status codes with string messages. No structured error codes. Exception handling documented in scattered knowledge base articles.
Every webhook is signed with HMAC-SHA256 using a per-merchant secret. Replay protection via timestamp validation.
RESTful with OpenAPI spec. Typed SDKs for TypeScript, Python. Cursor-based pagination. Consistent error schema.
REST API with adequate documentation. Order-based model. No typed SDKs. Limited real-time capabilities.
Machine-readable error codes with human descriptions, docs links, and suggested remediation.
Standard HTTP status codes with reason messages. No structured error taxonomy. Basic but functional.
Every webhook is signed with HMAC-SHA256 using a per-merchant secret. Replay protection via timestamp validation.
RESTful with OpenAPI spec. Typed SDKs for TypeScript, Python. Cursor-based pagination. Consistent error schema.
Charge-based model with `pricing_type` and `local_price` shapes that predate modern stablecoin-first checkouts. Long-tail features (refunds, withdrawals) live in the dashboard, not the API.
Machine-readable error codes with human descriptions, docs links, and suggested remediation.
Errors return high-level type + message. Limited remediation context, no structured codes, and no documented retry guidance for charge state transitions.
Every webhook is signed with HMAC-SHA256 using a per-merchant secret. Replay protection via timestamp validation.
RESTful with OpenAPI spec. Typed SDKs for TypeScript, Python. Cursor-based pagination. Consistent error schema.
Greenfield REST surface that has matured over time. Adequate for invoicing flows but missing typed SDKs, hosted dashboards for failure analytics, and managed retry guarantees.
Machine-readable error codes with human descriptions, docs links, and suggested remediation.
Errors are functional but tied to the operator's running version. Behavior shifts between releases and there is no managed support contract for incident triage.
We score each processor against six durable trust signals every integrator can verify themselves. No subjective rating averages, no cherry-picked logos, just the public surface area of operational maturity.
HMAC-SHA256 + replay defense
Modern webhook signing with timestamp binding so replays cannot be quietly accepted.
HMAC-SHA256 with timestamp-bound payloads and built-in replay protection on every webhook.
First-party typed SDK
Vendor-maintained, strict-typed SDK so integration code stays in step with the API.
First-party typed SDKs for TypeScript and Python, generated from the same OpenAPI spec the docs are rendered from.
No vendor-maintained typed SDK. Integrators ship their own thin client or rely on community packages of varying maintenance quality.
Public status page
Vendor-hosted operator dashboard with real telemetry on uptime and webhook delivery.
Live status page with per-chain RPC latency, confirmation times, webhook delivery p50/p95/p99, and 90-day incident history.
A status surface exists but tends to lag real incident detection by minutes; merchants commonly find out from failed callbacks first.
Responsible disclosure policy
Published vulnerability disclosure channel with a documented response window.
Published security disclosure policy with a dedicated security contact and a coordinated-disclosure SLA.
Security contact lives behind general support intake rather than a dedicated security policy with disclosure SLAs.
Built-in auto-conversion
First-party cross-chain conversion without forcing a manual exchange dance per payout.
First-party DEX and CEX auto-conversion with a transparent execution path and ledger entry per leg.
Auto-conversion is offered but the executed rate is determined at settlement, with the spread to the quoted rate left undisclosed.
Public changelog / roadmap
Continuously-updated, subscribable changelog so platform changes do not surprise you.
Public, RSS-friendly changelog and roadmap so merchants can subscribe to platform changes that affect their integration.
No durable, publicly-subscribable changelog for processor changes; behavior shifts surface in support tickets and forum posts.
HMAC-SHA256 + replay defense
Modern webhook signing with timestamp binding so replays cannot be quietly accepted.
HMAC-SHA256 with timestamp-bound payloads and built-in replay protection on every webhook.
First-party typed SDK
Vendor-maintained, strict-typed SDK so integration code stays in step with the API.
First-party typed SDKs for TypeScript and Python, generated from the same OpenAPI spec the docs are rendered from.
No first-party typed SDK across the major server-side languages; clients are hand-written against a sometimes-inconsistent REST surface.
Public status page
Vendor-hosted operator dashboard with real telemetry on uptime and webhook delivery.
Live status page with per-chain RPC latency, confirmation times, webhook delivery p50/p95/p99, and 90-day incident history.
Status communications happen but are not consolidated into a continuously-updated metrics page that operators can subscribe to.
Responsible disclosure policy
Published vulnerability disclosure channel with a documented response window.
Published security disclosure policy with a dedicated security contact and a coordinated-disclosure SLA.
Vulnerability reporting goes through general support intake rather than a published policy with disclosure-window commitments.
Built-in auto-conversion
First-party cross-chain conversion without forcing a manual exchange dance per payout.
First-party DEX and CEX auto-conversion with a transparent execution path and ledger entry per leg.
Conversion exists but executes at the vendor's settlement rate, and the merchant has limited visibility into the executed spread.
Public changelog / roadmap
Continuously-updated, subscribable changelog so platform changes do not surprise you.
Public, RSS-friendly changelog and roadmap so merchants can subscribe to platform changes that affect their integration.
No durable, machine-friendly changelog tracking processor-level changes; release behavior is communicated through ad-hoc support announcements.
HMAC-SHA256 + replay defense
Modern webhook signing with timestamp binding so replays cannot be quietly accepted.
HMAC-SHA256 with timestamp-bound payloads and built-in replay protection on every webhook.
First-party typed SDK
Vendor-maintained, strict-typed SDK so integration code stays in step with the API.
First-party typed SDKs for TypeScript and Python, generated from the same OpenAPI spec the docs are rendered from.
First-party SDKs exist but their breadth and freshness vary by language; modern strict-typed clients are not the maintained default.
Public status page
Vendor-hosted operator dashboard with real telemetry on uptime and webhook delivery.
Live status page with per-chain RPC latency, confirmation times, webhook delivery p50/p95/p99, and 90-day incident history.
A vendor-hosted status surface exists, focused on platform availability rather than per-chain confirmation telemetry.
Responsible disclosure policy
Published vulnerability disclosure channel with a documented response window.
Published security disclosure policy with a dedicated security contact and a coordinated-disclosure SLA.
Security questions route through general support; no published vulnerability-disclosure SLA aimed at security researchers.
Built-in auto-conversion
First-party cross-chain conversion without forcing a manual exchange dance per payout.
First-party DEX and CEX auto-conversion with a transparent execution path and ledger entry per leg.
Auto-conversion to fiat is built in, but settlement timing (next business day) and conversion spreads have to be modeled by the merchant.
Public changelog / roadmap
Continuously-updated, subscribable changelog so platform changes do not surprise you.
Public, RSS-friendly changelog and roadmap so merchants can subscribe to platform changes that affect their integration.
Release notes appear in marketing channels rather than a dedicated, RSS-style changelog focused on processor-level behavior.
HMAC-SHA256 + replay defense
Modern webhook signing with timestamp binding so replays cannot be quietly accepted.
HMAC-SHA256 with timestamp-bound payloads and built-in replay protection on every webhook.
First-party typed SDK
Vendor-maintained, strict-typed SDK so integration code stays in step with the API.
First-party typed SDKs for TypeScript and Python, generated from the same OpenAPI spec the docs are rendered from.
Vendor SDKs exist but coverage across modern stacks is uneven; strict-typed clients are not the default integration path.
Public status page
Vendor-hosted operator dashboard with real telemetry on uptime and webhook delivery.
Live status page with per-chain RPC latency, confirmation times, webhook delivery p50/p95/p99, and 90-day incident history.
Public status surface focused on overall platform availability rather than per-chain confirmation latency or webhook delivery percentiles.
Responsible disclosure policy
Published vulnerability disclosure channel with a documented response window.
Published security disclosure policy with a dedicated security contact and a coordinated-disclosure SLA.
Security questions are accepted through general support and an EU compliance contact rather than a published policy with disclosure-window SLAs.
Built-in auto-conversion
First-party cross-chain conversion without forcing a manual exchange dance per payout.
First-party DEX and CEX auto-conversion with a transparent execution path and ledger entry per leg.
Conversion to fiat or stablecoin is offered, with the executed rate and any per-currency markup determined inside the marketplace at settlement time.
Public changelog / roadmap
Continuously-updated, subscribable changelog so platform changes do not surprise you.
Public, RSS-friendly changelog and roadmap so merchants can subscribe to platform changes that affect their integration.
Product updates surface in blog and email but not in a continuously-versioned, machine-friendly changelog feed for processor changes.
HMAC-SHA256 + replay defense
Modern webhook signing with timestamp binding so replays cannot be quietly accepted.
HMAC-SHA256 with timestamp-bound payloads and built-in replay protection on every webhook.
First-party typed SDK
Vendor-maintained, strict-typed SDK so integration code stays in step with the API.
First-party typed SDKs for TypeScript and Python, generated from the same OpenAPI spec the docs are rendered from.
Older first-party SDKs exist across multiple languages but receive limited maintenance and lag the live API surface.
Public status page
Vendor-hosted operator dashboard with real telemetry on uptime and webhook delivery.
Live status page with per-chain RPC latency, confirmation times, webhook delivery p50/p95/p99, and 90-day incident history.
Status is communicated as part of the broader Coinbase platform surface rather than a Commerce-specific operator dashboard.
Responsible disclosure policy
Published vulnerability disclosure channel with a documented response window.
Published security disclosure policy with a dedicated security contact and a coordinated-disclosure SLA.
Security disclosure is funneled through Coinbase's published vulnerability program with documented response expectations.
Built-in auto-conversion
First-party cross-chain conversion without forcing a manual exchange dance per payout.
First-party DEX and CEX auto-conversion with a transparent execution path and ledger entry per leg.
There is no first-party cross-chain auto-conversion. Merchants are settled into Coinbase and convert manually at retail spreads.
Public changelog / roadmap
Continuously-updated, subscribable changelog so platform changes do not surprise you.
Public, RSS-friendly changelog and roadmap so merchants can subscribe to platform changes that affect their integration.
No dedicated processor changelog. Behavior changes appear in support advisories and broader Coinbase communications.
HMAC-SHA256 + replay defense
Modern webhook signing with timestamp binding so replays cannot be quietly accepted.
HMAC-SHA256 with timestamp-bound payloads and built-in replay protection on every webhook.
First-party typed SDK
Vendor-maintained, strict-typed SDK so integration code stays in step with the API.
First-party typed SDKs for TypeScript and Python, generated from the same OpenAPI spec the docs are rendered from.
Open-source SDKs exist for invoice flows, but typed-client coverage and ergonomics are not on par with managed processors.
Public status page
Vendor-hosted operator dashboard with real telemetry on uptime and webhook delivery.
Live status page with per-chain RPC latency, confirmation times, webhook delivery p50/p95/p99, and 90-day incident history.
BTCPay is self-hosted by design, there is no vendor-hosted public status page because the merchant is the operator.
Responsible disclosure policy
Published vulnerability disclosure channel with a documented response window.
Published security disclosure policy with a dedicated security contact and a coordinated-disclosure SLA.
Security disclosure flows through the open-source project's documented channels and tracked GitHub advisories.
Built-in auto-conversion
First-party cross-chain conversion without forcing a manual exchange dance per payout.
First-party DEX and CEX auto-conversion with a transparent execution path and ledger entry per leg.
No first-party cross-chain auto-conversion. Merchants integrate exchange APIs themselves to land in stablecoin or fiat.
Public changelog / roadmap
Continuously-updated, subscribable changelog so platform changes do not surprise you.
Public, RSS-friendly changelog and roadmap so merchants can subscribe to platform changes that affect their integration.
Per-release notes exist in the open-source repository, though every upgrade is also a maintenance event the merchant has to plan around.
Sourced from public developer forums, support communities, and merchant reviews. These are the operational realities that headline marketing omits.
High-volume crypto processor with opaque conversion pricing
Exchange rate opacity: the rate you see at payment creation differs from the rate applied at settlement, the spread is undisclosed and variable
Withdrawal friction: merchants report needing to contact support for withdrawals above certain thresholds or when settlement currency changes
IPN reliability: callback delivery can be delayed or missed with no built-in retry dashboard visible to merchants
API documentation gaps: outdated examples, missing edge-case documentation, community reports of undocumented behavior changes
To their credit
200+ supported cryptocurrencies (widest coin selection in the market)
Simple onboarding flow with minimal KYC for small volumes
Volume-discount processor with conversion-spread economics
Conversion spread opacity: the in-app quoted rate is rarely the rate captured at settlement, and the variance is not surfaced in the dashboard
Withdrawal friction: first withdrawal often triggers manual review, slowing legitimate merchants without a clear SLA
API rough edges: form-encoded payloads, mixed-case fields, and absent typed SDKs mean every integration writes its own thin client
Documentation gaps: webhook retry behavior, refund eligibility windows, and chain-specific quirks live in support replies rather than docs
To their credit
Aggressive headline fee for high-volume merchants who can negotiate a tier
Broad altcoin coverage across mid- and long-tail chains
Legacy enterprise gateway with invoice-era architecture
KYC overhead: extensive identity verification required before accepting any payments, with multi-week review times for some merchant categories
Invoice-era API: the API surface is modeled around "invoices" from 2013, requiring adaptation for modern checkout flows and SPA integrations
Limited chain support: only Bitcoin, Bitcoin Cash, Ethereum, and a handful of stablecoins, no Solana, no L2s, no TRON
Settlement rigidity: bank settlement on next business day only, crypto settlement takes 2-3 days with limited scheduling control
To their credit
Brand recognition and enterprise trust from being the oldest crypto payment processor
Strong compliance and regulatory standing for merchants in regulated industries
Marketplace-model gateway with layered fee complexity
Fee complexity: the advertised 1% is a starting point, settlement method, volume tier, and conversion path each add incremental costs that are hard to predict
Limited developer tooling: no typed SDKs, no OpenAPI spec, no interactive API playground, integration requires more manual work
Settlement delays: EUR/USD bank transfers take 1-2 business days; crypto settlement is faster but still not on-demand
Marketplace model: the platform operates as an intermediary marketplace rather than direct infrastructure, adding abstraction between merchant and payment
To their credit
Strong webhook security with proper HMAC-SHA256 signing
Lightning Network support for Bitcoin payments
EU-focused with good EUR settlement options and Lithuanian banking rails
Coinbase-tethered processor with limited settlement freedom
Coinbase ecosystem lock-in: settlement requires a linked Coinbase account, so every merchant inherits the Coinbase support queue and policy surface
No auto-conversion: merchants are left holding whatever coin was sent, then have to sell on Coinbase retail at retail spreads to realize fiat
Refunds and withdrawals split between API and dashboard, making reconciliation painful and the operator runbook incomplete
Product velocity: Coinbase Commerce is a low-priority surface inside Coinbase, with long stretches between feature shipments and frequent unannounced limits
To their credit
Trusted brand association with Coinbase that some compliance teams accept without further review
HMAC-SHA256 webhook signing puts it ahead of other legacy IPN-style processors
Self-hosted open source processor that you run, monitor, and patch
Operational burden: every merchant becomes a payment-infrastructure team, node sync, Lightning channel management, security patches, backups, and on-call
Limited stablecoin coverage: deeply Bitcoin- and Lightning-first, with no first-party auto-conversion across chains and weak coverage of multi-chain stablecoin flows
Compliance surface: regulator and auditor attention shifts from the processor to the merchant because the merchant is now the processor
Upgrade risk: every release introduces a maintenance window where checkout availability depends on the merchant's operational rigor
To their credit
Open source and self-custodial, funds never touch a third party between buyer and merchant
Strong Bitcoin and Lightning roadmap with an active community of operators and contributors
No platform fees on the processor itself, which can be attractive for high-volume Bitcoin-only merchants
Create a free sandbox. Run a test payment on Solana for under a penny. Compare the developer experience, settlement speed, and fee transparency against your current provider. No credit card, no commitment.