How we evaluate

How we evaluate crypto payment solutions

How we decide what a crypto payment solution really is, what we will and will not claim, and why we would rather say "we do not know yet" than guess. No vendor pays for placement, and no affiliate arrangement changes a rating.

Categories: what you are committing to

Vendors call almost everything a "processor" or "gateway." That hides the thing that matters most: how much you have to operate and trust. We sort every solution into one of six kinds by what a typical small merchant is actually signing up to run and rely on, not by the vendor's label. If a "gateway" actually makes you run a node, we classify it as self-hosted infrastructure with a gateway-like tag, not a custodial gateway.

Custodial gateway

A hosted service that takes the cryptocurrency on your behalf, optionally converts it, and settles to your bank or account. The lowest operational burden and the highest third-party dependence: you never hold the keys, and the provider holds funds between sale and settlement.

Self-hosted acceptance platform

Software the merchant, or their host, runs to accept cryptocurrency directly to their own wallet, with no third party in the payment path. Full self-custody and independence in exchange for running and maintaining software. The merchant becomes the operator.

Lightning infrastructure or provider

A service or node stack whose core job is Lightning acceptance, handling liquidity, channels, and node management, sometimes as infrastructure other tools build on. Lightning has operational realities that do not map cleanly onto the gateway or self-hosted shapes.

Wallet-based acceptance

Accepting payments directly into a merchant wallet app, via a static address, an in-wallet request, or a point-of-sale mode, with no dedicated acceptance platform. The simplest possible path, and the one most merchants actually start with.

Settlement or off-ramp provider

A service whose primary role is converting cryptocurrency to fiat and settling to a bank, layered on top of another acceptance method. Settlement is a separable concern; treating it as its own category prevents conflating accepts with settles.

Infrastructure or developer platform

An SDK or API-first platform meant to be embedded into another product, not used directly by a typical merchant. Distinguishes a merchant can use this today from a developer builds a merchant product on this.

Readiness Levels (R1–R5): is it ready for a merchant?

The headline badge is a Readiness Level: how ready is this solution for a typical small merchant to adopt and rely on today? We assign the deepest level the evidence substantiates, never the most ambitious level the vendor markets, and never by averaging. Readiness is a kind of readiness, not a quality score: an R5 "Turnkey" solution can still be rated Poor on privacy or fees.

R5: Turnkey

A merchant can sign up and reliably accept and settle cryptocurrency today, and CryptoLic has verified the full path end to end (documentation plus hands-on lab validation). Nothing merchant-critical is missing or unconfirmed. Minimum evidence: Direct lab validation of acceptance AND settlement, plus current primary documentation.

R4: Merchant-ready

A finished merchant product exists and is documented by current primary sources to accept and settle payments for a typical business. CryptoLic has not yet validated the full path hands-on, so some conclusions remain documentation-only. Minimum evidence: Current primary documentation of a self-serve merchant acceptance and settlement product.

R3: Workable with effort

A merchant can use it, but only by taking on real operational burden, self-hosting, node management, integration work, or by accepting notable gaps (for example no fiat settlement). Capable, but not something a typical merchant adopts casually. Minimum evidence: Documentation of a usable merchant path plus a clearly substantiated operational burden or gap.

R2: Early or narrow

A real offering, but immature, narrow in scope, or missing pieces most merchants need (for example acceptance without any settlement path, or availability gated behind partner onboarding). Promising, not yet broadly dependable. Minimum evidence: Documentation of a real offering together with a substantiated, merchant-critical gap.

R1: Not merchant-ready

An SDK, infrastructure component, or project not usable by a typical merchant as-is today. It requires a developer to build a merchant product on top of it. CryptoLic will not present it as a finished solution. Minimum evidence: Documentation showing the offering is an SDK/infrastructure requiring engineering to use.

Commitment Levels (C1–C5): how much must you operate?

Readiness and commitment are different questions, so we keep them on separate axes. Commitment measures how much you must set up, maintain, or engineer. A solution can be highly ready yet high-commitment (a polished self-hosted platform), or low-commitment yet not merchant-ready (a slick SDK that still needs a developer). Keeping them separate is the whole point: it stops "easy to sign up for" from being confused with "ready," and stops "powerful" from being confused with "usable by you."

Readiness vs Commitment. Readiness asks whether a solution is ready for a typical merchant; commitment asks how much you must operate and maintain. They are independent: a hosted gateway can be high readiness and low commitment, a self-hosted platform can be usable yet high commitment, and an SDK stays low readiness no matter how it is marketed. Points are illustrative categories, not vendor verdicts.

Create an account and configure settings. No infrastructure, no code. Setup: Create an account, verify the business, configure payout and checkout settings. Ongoing: Minimal: occasional settings and reconciliation. Skill: No technical skill required. Engineering help: Not normally required.

C2: Light operational setup

Some hands-on setup: a plugin, a device, or a wallet to manage. Setup: Install a plugin or app, connect a wallet or bank, or set up a device. Ongoing: Light: manage a wallet or app, keep a plugin updated. Skill: Comfortable following setup steps; no coding. Engineering help: Not normally required.

C3: Business-process integration

Fits into your workflow: reconciliation, staff process, or a real integration. Setup: Integrate into checkout, accounting, and staff workflow; possibly connect systems. Ongoing: Moderate: reconciliation, staff training, monitoring. Skill: Operational capacity; may need help for integration. Engineering help: Sometimes required for integration.

C4: Self-hosted infrastructure

You run the software or a node: hosting, uptime, backups, upgrades. Setup: Deploy and configure server software or a node (or contract a host). Ongoing: Substantial: uptime, backups, security updates, node/liquidity management. Skill: Technical operator, or budget for managed hosting. Engineering help: Often required for setup and maintenance.

C5: Engineering platform

A developer must build the merchant product on top of it. Setup: Build a merchant application against an SDK or API before any payment is accepted. Ongoing: Full software ownership: development, maintenance, infrastructure. Skill: Software engineering team. Engineering help: Required; this is a building block, not a product.

The nineteen things we rate (and why there is no overall score)

Beneath the badges, we rate up to nineteen dimensions, grouped into money and control, operations, technical capability, and cost, clarity, and privacy. Each is rated on its own ordinal band, Poor, Fair, Good, or Excellent, plus Not confirmed and Not applicable as first-class states. We never average them into one number. Averaging a self-hosted server's independence against a gateway's convenience would invent false precision and hide the exact tradeoff you need to see. The headline is the category, the plain-English verdict, the readiness and commitment badges, and a confidence signal; the ratings are the supporting detail.

Confidence: how sure we are

Separately from every rating, we mark how confident we are: high, medium, or low. Confidence reflects the strength of the evidence, direct testing at the top, then current primary documentation, down to conflicting or secondary sources at the bottom. At launch, much of our confidence is low or medium because our conclusions rest on documentation we have read, not testing we have finished. We would rather tell you that than imply certainty we do not have.

Evidence hierarchy and the never-infer rule

Every public claim traces to a real source we retrieved. We prioritize primary sources: official documentation, official pricing, official repositories and release notes, and official support pages. We use secondary sources only to corroborate. And we never infer custody, key control, settlement, refunds, reporting, accounting, KYC, or availability from marketing language or from the mere existence of an API. If a source did not load, we record that and do not cite it. If a fact is not documented, it stays unknown.

Merchant-ready versus developer-ready

One distinction we refuse to blur: a finished product a merchant can use is not the same as an SDK or API a developer must build on. We do not turn an SDK into a merchant product, an API into an integration, a wallet into a payment processor, or open-source availability into easy deployment. When a solution is really infrastructure, we assign R1 and say so, even if it is technically impressive.

Custody, key control, and provider dependency

For every solution we state, from primary sources, who holds the funds between sale and settlement, who controls the keys, and, using documented facts only, what continues to work and what funds remain accessible if the provider or hosted service becomes unavailable. We use a controlled set of outcomes for that last question and we do not speculate about a company's solvency or make legal predictions.

Custodial vs self-custodial. In a custodial solution (top), a provider holds your funds between the sale and settlement, so your access depends on that provider. In a self-custodial solution (bottom), payment lands directly in a wallet you control, with no third party in the path. This single distinction separates the solutions more than any feature does.

How we verify and date facts

Every solution page carries dated verification fields and a change log. Documentation-verified comes first; lab-verified comes later, once we have set the solution up and run real transactions, refunds, and settlements ourselves. We never label something "directly tested" unless we actually tested it. Pricing and availability are the fastest-moving facts, so when they age past our review window we suppress the stale value rather than show it as current.

Independence, no pay-to-play, and affiliates

We take no money from the vendors we evaluate, and no placement is for sale. We earn from the guides and toolkits we sell, which keeps us independent of the solutions we review. A vendor can correct a fact, verified against primary sources, but cannot buy a better rating or change our judgment. We do not use self-serving review markup to manufacture stars, because we do not issue stars.

Sometimes the honest answer is "not this one," "not yet," or "wait until we finish testing." If a solution is really infrastructure, if a critical piece like settlement or refunds is missing or unverified, or if the burden is not justified for a typical merchant, we say so. The willingness to conclude "run this," "accept the custody tradeoff," or "none of these fits your business yet" is the entire point of this resource.

Questions

Do you take money from the payment solutions you cover?

No. We take no money from any vendor we evaluate, and no placement is for sale. We earn from the guides and toolkits we sell, which keeps us independent of the solutions we review. A vendor can correct a fact, but cannot buy a better rating.

Have you actually tested these solutions?

At launch, most conclusions are documentation-verified: confirmed against current primary sources but not run hands-on. Where we have directly tested something, we label it clearly. We never claim to have tested a solution unless we did.

Why don't you rank the solutions or give an overall score?

Because averaging things as different as a self-hosted server's independence and a gateway's convenience invents false precision and hides the tradeoff you need to see. We give a category, readiness and commitment levels, per-dimension ratings, and a confidence level instead of one misleading number.

What is the difference between readiness and commitment?

Readiness is whether a solution is ready for a typical merchant to rely on. Commitment is how much you have to operate and maintain. A solution can be very ready but high-commitment (a self-hosted platform), or low-commitment but not merchant-ready (a developer SDK). Keeping them separate stops one from being mistaken for the other.

Why do some pages say custody or fees are unknown?

Because we could not confirm them from a primary source, and we will not guess. We never infer custody, settlement, fees, or refunds from marketing or from the existence of an API. An honest unknown is more useful than a confident guess that turns out wrong.

Would you ever tell me not to use any of these?

Yes. Sometimes the honest answer is that a solution is really developer infrastructure, that a critical piece is missing or unverified, or that a merchant should wait. Telling you that is the whole point of this resource.