Prepared by the Token Metrics Editorial Team using the official sources listed below. Product terms, eligibility, limits, fees, and protocol rules can change; confirm current details before acting.
Scope: This method covers crypto onramps, offramps, exchange market-data APIs, and exchange trading APIs. It helps a reader test workflow fit. It does not rate token value, promise service safety, or give legal advice.
Why we do not use one score
A single score would hide key facts. A ramp can work well for one country and payment rail but not another. A trading API can suit market data but not order entry. Costs and access can change. We therefore use a non-scoring policy. Each page states the user job, evidence, limits, and checks. A conclusion must name the workflow it fits.
Evidence hierarchy
- Official API and product documentation for current functions and setup.
- Official legal, security, status, fee, and coverage pages for current limits.
- Regulator and standards material for public risk and control context.
- Hands-on tests for behavior, errors, accessibility, and output.
- Vendor marketing only as a lead to verify, never as sole proof of a broad claim.
Criteria definitions
Job fit
Does the product perform the exact ramp, data, or account action the reader needs? We look for direct evidence and record the date checked. Missing evidence is a limit, not a zero that can be hidden inside an average.
Coverage
Are the needed country, user, currency, payment rail, asset, network, and product available? We look for direct evidence and record the date checked. Missing evidence is a limit, not a zero that can be hidden inside an average.
Developer quality
Do docs cover auth, errors, limits, events, examples, and change notes? We look for direct evidence and record the date checked. Missing evidence is a limit, not a zero that can be hidden inside an average.
Security and privacy
Can a team limit access, protect secrets, verify events, and reduce data collection? We look for direct evidence and record the date checked. Missing evidence is a limit, not a zero that can be hidden inside an average.
Cost clarity
Can the user see all fees, spread, network cost, and quote expiry before approval? We look for direct evidence and record the date checked. Missing evidence is a limit, not a zero that can be hidden inside an average.
Reliability
Can the team detect failure, retry safely, reconcile state, and reach support? We look for direct evidence and record the date checked. Missing evidence is a limit, not a zero that can be hidden inside an average.
Compliance fit
Can the business map its duties, provider duties, identity process, and records with counsel? We look for direct evidence and record the date checked. Missing evidence is a limit, not a zero that can be hidden inside an average.
Research process
- Define the page role and user job before reading vendors.
- List every claim that could affect money, access, custody, or security.
- Map each claim to a current primary source or remove it.
- Test tools at desktop and mobile sizes with keyboard use and visible output.
- Compare choices on the same criteria. Do not mix ramps and trading APIs as if they were the same product.
- Run a plain-language edit and a source, disclosure, CTA, schema, and internal-link check.
Freshness and update policy
We show the check date in the source section. Dynamic facts must be checked again before publication and during a scheduled review. A material product, region, fee, security, or API change triggers an earlier review. We remove future dates. We also strip research tags such as chat tool tracking from public links.
Limits and conflicts
Official docs can be incomplete or change after review. A docs review cannot prove uptime, support quality, approval rates, or security. Hands-on tests cover only the tested path. Token Metrics may earn compensation from some links, but payment does not decide inclusion. When evidence cannot support a rank, we say so and do not invent a score.
Worked examples
Example: a wallet onramp
The job is to let an eligible user buy one asset on one network with one payment rail. We check current provider docs, show region and route caveats, test success and failure, verify total cost display, and review destination controls. We do not turn that test into a global availability claim.
Example: a read-only market dashboard
The job needs public prices and perhaps a stream. It does not need account or transfer rights. We check symbols, timestamps, limits, errors, and reconnect behavior. The security decision is simple: do not issue a powerful key for a read-only job.
Frequently asked questions
Do you score providers?
No. This method uses workflow findings because a stable overall score is not supported across regions and jobs.
How often are pages updated?
They receive a scheduled review and an earlier review after a material change. Readers should still confirm current terms.
Does an official source prove quality?
No. It proves what the provider states. Tests and user operations add other evidence, but they also have limits.
How are affiliate links handled?
A disclosure appears on the page. Compensation does not set coverage or conclusions.
Reproducible evaluation runbook
Freeze the test case before comparing products
Write one test brief with the date, region, user type, asset, network, payment rail or API job, and expected outcome. Record the provider document versions or page access dates. For an onramp, define the quoted purchase, identity state, destination wallet, cancellation path, and the total amount the user should see before approval. For an API, define the endpoint, authentication scope, sample request, expected response fields, rate-limit behavior, and failure cases. Use the same brief for every candidate so a wider feature list cannot hide a failed core task.
Capture evidence that another reviewer can inspect
Keep a dated evidence packet for each run. Save the official URL, relevant excerpt, request and response with secrets removed, timestamps in UTC, displayed fees, error messages, and the reviewer’s pass or fail note. Label observations separately from provider claims. A claim such as “the documentation lists this endpoint” is not the same as an observed successful request. Record the environment and test account state, because eligibility, permissions, network conditions, and account history can change the result. A second reviewer should be able to repeat the steps without relying on memory.
Monitor changes and reopen affected findings
Create a change log keyed to each material finding. Recheck official release notes, terms, coverage, fee pages, authentication guidance, and API schemas on the scheduled review date. Review sooner when a provider changes a route, supported region, payment rail, permission model, endpoint, version, or deprecation notice. Compare the new evidence packet with the prior one, mark which conclusion changed, and update only the affected comparison. If a source disappears or conflicts with observed behavior, return the finding to “unverified” until it is tested again.
State what the run cannot establish
A reproducible test supports only the defined region, account, route, time, and environment. It does not prove global availability, future uptime, approval probability, support quality, regulatory status, security, or the outcome for another user. Sandbox success does not establish production success. One completed transaction does not establish typical cost or reliability. Publish those boundaries with the finding, and avoid ranking products when the evidence does not support a fair comparison.
Sources
These primary and public-interest sources were checked on July 13, 2026. Product terms can change, so confirm the current page before you build or move assets.
- Coinbase Onramp docs
- Stripe Crypto Onramp docs
- Kraken API docs
- OWASP API Security Top 10
- FinCEN guidance
Disclosure: Token Metrics may earn compensation from some partner links. Compensation does not decide coverage or conclusions. This page is for education. It is not investment, legal, tax, custody, compliance, or engineering advice.
Continue: ramp provider guide · exchange API comparison · methodology · workflow selector
