Research Methodology

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.

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.