Editorial standards

Research Methodology

How a merchant record gets made, in enough detail that you could audit one yourself.

Last updated

Every acceptance claim on this site carries a URL you can open. This page explains how those URLs are chosen, which ones we consider strong enough to publish on, and what we do when the evidence is ambiguous — which is more often than you might expect.

The verification methodology covers what each status means. This covers how we get there.

The source hierarchy

Ranked. We work down it and stop at the strongest thing we can actually reach.

1. A real checkout. Reaching the payment step of a genuine order and seeing what is offered. This is the strongest evidence available and the hardest to obtain, because it usually requires an account and sometimes a real purchase.

2. The merchant’s own payment documentation. A page on the merchant’s domain stating what it accepts. This is the workhorse. The best of them publish an exact token-and-network matrix — Hostwinds and Time4VPS are the standard here, and a small minority of merchants overall.

3. The merchant’s own announcement. A blog post or press release from the company. Weaker than current documentation because it describes a launch state that may have moved on. We date it and say so.

4. The payment processor’s documentation. Where a merchant defers its asset list to a gateway, the gateway’s own published list is the next best thing — and where the processor names the merchant specifically, better still. HostSailor rests on exactly this: its own page names CoinGate and stops, and CoinGate’s documentation names HostSailor as accepting USDC.

5. Stablecoin or network issuer documentation. Useful for questions about the asset rather than the merchant.

6. Independent reporting. Used only where the merchant’s own pages could not be reached, and recorded with the third-party-report method so it is visible in the record. It cannot support a “verified” status — that rule is enforced by the content schema, so the build fails if anyone tries, rather than depending on an editor remembering.

What we record

For each source: the URL, a title, the date we accessed it, and — the field that does the real work — what specifically it establishes. Not “confirms crypto acceptance”, but “the exact token and network matrix, and the recurring-billing limitation”.

That last field is the difference between a citation and a decoration. It forces the person doing the research to state what they actually learned, and it lets a reader check the specific claim rather than the general vibe.

When the merchant contradicts itself

More common than it should be, and we do not paper over it.

AlexHost is the clearest current example. Its payment FAQ names USDT among the selectable coins. Its VPS-with-cryptocurrency landing page lists five assets, none of them a stablecoin. Both are on the merchant’s own domain. We cannot reconcile them from outside.

So the record carries USDT, because a merchant page names it; the status is “payment availability may vary”, because another merchant page contradicts it; the note explains the conflict; and both pages are cited. A reader can see exactly what we saw.

The alternative — picking the more favourable page and presenting it as settled — would produce a tidier directory and a less honest one.

When we claim nothing

Some records list no stablecoin at all despite the merchant certainly accepting crypto. That is deliberate.

Trip.com was widely reported to have launched USDT and USDC payments. Its own payment FAQ lists no cryptocurrency whatsoever. We list the record, claim no coins, and explain the gap — because a cluster of consistent news articles is not the merchant, its processor, or a checkout test.

Emirates went live with Crypto.com Pay in July 2026, confirmed by both parties. Neither names a single asset. So neither do we.

BitDials is crypto-only, so acceptance is certain, but its site refused every request we made. No coin claimed.

An empty stablecoins field is a publishable answer. It says: this merchant takes crypto, and nobody will tell you which.

What we reject

Research is not only additive, and the rejections outnumber the additions. Candidates fail for reasons including:

  • Bitcoin only. A merchant accepting BTC and LTC is out of scope. We catalogue stablecoin spending.
  • Direction reversed. A payroll service that pays out in USDC is where you receive stablecoins, not where you spend them. One such record was withdrawn on exactly this ground.
  • Circular sourcing. Every trail leading back to one directory copying another. If nobody can point at the merchant, there is nothing to publish.
  • Acceptance that has quietly ended. Several candidates turned out to have removed the option years ago while the press coverage stayed online.
  • Unreachable and unattested. No merchant page, no processor confirmation, no credible report.

Rejections are not visible on the site, which is the point of them. They are counted in our quarterly reports.

Freshness

A verified status degrades automatically to “recently confirmed” once the check passes 180 days. No editor has to remember; the badge ages itself. That is a deliberate architectural choice — the most common failure mode for a directory is not being wrong on day one, it is being right on day one and never looking again.

Aggregate statistics

The Stablecoin Spend Index is computed from the merchant collection at build time. No figure on it is typed by hand, and there is no separate statistics store to fall out of sync. Its limitations are stated on the page itself: it counts merchants rather than transactions, it is a sample rather than a census, and it is biased towards businesses that document their payment options in English.

We would rather publish those caveats prominently than let the numbers imply a completeness they do not have.

Cohorts

Every record sits in exactly one of five cohorts, decided by its verification status and whether it names a stablecoin:

CohortMeaningIn the adoption denominator
Confirmed named-stablecoin acceptanceVerified or recently confirmed, at least one named coinYes
Conditional acceptanceCrypto acceptance confirmed; the coin list varies by region, product or gateway setting, but at least one coin is namedYes
Crypto accepted, stablecoin support unspecifiedCrypto acceptance confirmed; no stablecoin named by the merchant or its gatewayNo
Acceptance discontinuedPreviously accepted; believed to have stoppedNo
Status unknownCompiled from public documentation, not yet checkedNo

“Documented stablecoin acceptance” — the denominator for every percentage the Index publishes — is the first two cohorts together. A merchant whose gateway “supports crypto” is not counted as accepting USDC until a source says so. Every published share carries its denominator beside it.

Cohorts describe what the evidence establishes. The evidence method (documentation checked, checkout option observed, merchant confirmed) and its freshness are recorded separately on each profile and do not move a record between cohorts.

Overlaps

A merchant naming three coins is counted under each coin, so per-coin shares sum above 100%; the same holds for networks, categories and countries. The Index states this in every chart caption rather than normalising the overlap away, because “87 of 102 merchants take USDC” is the checkable fact and a normalised share is not.

What the figures are not

The Index counts merchants that document acceptance. It is not transaction volume, market share or a census of the market, and a merchant absent from a network row is a merchant that published no network — not a merchant that declined one. We do not read intent into silence.

Dataset version

Every surface that repeats an Index figure — the page, the JSON and CSV exports, the research charts and the MCP server — carries a dataset version of the form date.records.commit. Two figures under the same version came from the same computation; under different versions they may legitimately differ.

Corrections to aggregate figures

  • 2026-09-22. The network-disclosure paragraph on the Index compared the number of merchants publishing no network to the leading network and called it larger, and described that group as “most merchants”. At the time the figures were 47 undisclosed of 107 live records against 54 on Ethereum: neither claim was true. The sentence is now generated from the counts and cannot state an ordering the numbers do not support. In the same change the adoption denominator moved from “every live record” (107) to “documented stablecoin acceptance” (102), excluding five records that confirm crypto acceptance without naming a stablecoin; per-coin and per-network shares rose by between two and four percentage points as a result, and the undisclosed-network count fell from 47 to 42 because the five excluded records were among those publishing no network. The same day’s review of twenty profiles then removed networks that rested on gateway capability rather than merchant documentation (see the correction entries on those records), which moved the count to 45 of 102 and Ethereum from 54 to 48 disclosed merchants. Both are record corrections; no merchant changed what it accepts. This is a change in how records are classified, not a change in any merchant’s acceptance. The Q3 2026 report remains bound to its frozen snapshot and is unchanged.

Auditing us

Pick any merchant record. The verification block lists the sources, what each one supports, and when we looked. Open them. If our reading differs from yours, tell us — the corrections policy sets out what happens next, and accepted corrections are published with the evidence in What’s Changed.

How the Spending Finder ranks results

The Finder’s “best matches” list is ordered by a small, fixed set of factors, each of which is shown beside the result it applies to. In order of weight:

  1. Verification. A record checked within the last six months outranks one whose check is older, which outranks one where acceptance is confirmed but the coin list varies. Unverified and discontinued records never appear in the shortlist at all.
  2. Coin match. The stablecoin you selected is on the merchant’s published list.
  3. Category. A primary-category match outranks a subcategory match.
  4. Network. The chain you selected is documented; or, with no chain selected, that the merchant documents any chain at all. Disclosure is worth something in a dataset where close to half of merchants disclose nothing.
  5. Evidence. Two or more cited sources.
  6. Recency. Checked in the last ninety days.

Ties break alphabetically, so the order is stable from one visit to the next.

Payment is not a factor. Sponsored and featured listings are not inputs to the score and cannot be. Where one matches your filters it appears in a separate, labelled slot above the organic list — its position there was bought and the label says so. The scoring code is public in shared/finder-rank.mjs, and a test asserts that the same record scores identically with and without the paid flags.