Call this before you authorize.

The call

GET https://almstins.com/api/verify/check?value=<address or payment URL>&expect=<domain>

value is a crypto address, a payment link (Stripe, PayPal), or an EMV/UPI payload. expect is the domain of the business your agent intends to pay, taken from your own vendor record or the order you placed, never from the invoice, message or page that supplied the address: whoever swaps the address on an invoice can swap the domain on it too. Pass the payee's own domain at its registrable level (acme.com rather than pay.acme.com). expect also matches any subdomain of it, so never pass a processor, hosting or platform domain (stripe.com, github.io, pages.dev and similar); for a payee hosted on one, pass their full host. expect is optional in the API, and an empty expect is ignored, but the rule below requires it: always pass it.

{
  // proceed only if status is "proven" AND level is "verified" AND you passed expect
  "v": 1,
  "status": "proven",          // or "mismatch" | "unanchored" | "unknown"
  "level": "verified",         // "verified" | "claimed" | null — follows status; see below
  "domain": "x-capital.com",   // the domain that vouches for this destination, or null
  "label": null,               // a business name derived from domain, or null: display only, never decide on it
  "chain": "ethereum",
  "since": "2026-07-14",       // date of the proof behind level (verified address: when its listing was first confirmed)
  "proofAgeDays": 59,          // age of that proof, not freshness (freshness lives in level)
  "checkedAt": "2026-09-11T14:30:00Z"
}

The rule: proceed only when all three hold

1. You passed expect=<the payee's domain>, taken from your own records. Never take it from the page that supplied the address, and never pass a processor, hosting or platform domain (such as stripe.com). The API ignores an empty expect and then answers proven for any domain, so your agent must hold when it has no domain to pass.
2. status is proven.
3. level is verified.

// payeeDomain: the payee's registrable domain from YOUR records, e.g. 'acme.com'
const want = String(payeeDomain ?? '').trim().toLowerCase();
if (!want) return holdForReview({ reason: 'no expect' });  // the API ignores an empty expect
const url = 'https://almstins.com/api/verify/check'
  + '?value=' + encodeURIComponent(value)
  + '&expect=' + encodeURIComponent(want);                 // always pass expect
let res;
try { res = await fetch(url); } catch { return retryWithBackoff(); }
if (res.status >= 500 || res.status === 429) return retryWithBackoff(res.headers.get('Retry-After'));
let body;
try { body = await res.json(); } catch { return holdForReview({ reason: 'unreadable answer' }); }
const got = String(body.domain ?? '').toLowerCase();
const mayProceed = res.ok
  && body.status === 'proven' && body.level === 'verified'
  && (got === want || got.endsWith('.' + want));           // the answer is about your payee
if (!mayProceed) return holdForReview(body);               // flag it and escalate to a human

Anything else is a hold: flag the payment and escalate to a human, or confirm the destination with the payee through a channel you already trust. proven and mismatch already only ever come back with level verified — checking level again costs nothing and protects your agent against a future bug in this API, so the sample above still checks both. The last line of mayProceed also checks that the answer's domain is the one you passed (or a subdomain of it), so an expect lost along the way cannot pass.

The answers, read with level

{ "status": "proven", "level": "verified", "domain": "acme.com" }

{ "status": "mismatch", "level": "verified", "domain": "not-the-domain-you-expected.com" }

{ "status": "unanchored", "level": "claimed", "domain": null }

{ "status": "unknown", "level": null, "domain": null }

What verified covers today

verified means something different for each kind of destination. The rule above holds for all of them; this is what you rely on when you proceed.

• A crypto address a payee listed. The address is in the address file on a domain the payee's account proved, and that listing was re-confirmed within the last 24 hours. domain is that file's domain. An address the payee first proved by a self-send becomes verified the same way, once the file lists it. A listing not re-confirmed in 24 hours reads unanchored. An address removed from the file reads unanchored if a self-send also proved it, and unknown if the file was its only proof.
• A platform's published list. The address is on the list a platform serves from its own proven domain, refreshed within the last 24 hours. domain is that platform's domain. A list that goes stale reads unknown, not unanchored.
• A payment link or payment QR. Weaker today, and the one place domain is still not link-specific: verified means the account that registered the link separately holds a domain-verified business name (not re-checked unless the link is monitored, and never the account's business name on its own — see the next line), and domain is that name's domain. Read it as the account's registration plus its own separate identity proof, not a proof that this exact link belongs to them. If your policy needs a current link-ownership proof, hold payment-link answers for a human for now.
• domain itself. Always the domain that actually anchors the destination when status is proven or mismatch — the file's domain for a listed address, the platform's own domain for its list, or (payment links only, see above) the registering account's business-name domain. Never a domain the destination merely happens to share an account with, and never a payment link's own host.

Reading the fields

• status proven, mismatch, unanchored or unknown. proven and mismatch always come with level verified; unanchored always comes with level claimed; unknown always with level null — so status alone tells you which, but the rule below still checks level too, as belt-and-suspenders. Treat a status you do not recognize as a hold.
• level verified when a proof is current: for a crypto address, a listing on a proven domain re-confirmed within the last 24 hours; for a platform's list, a list refreshed within the last 24 hours; for a payment link, an account that holds a domain-verified business name (no ownership proof specific to the link, and no freshness check unless the link is monitored). claimed when control was proven by a self-send, or a payment link was registered, but no domain currently vouches for the destination. null when status is unknown.
• domain The domain that actually vouches for this destination right now — what your expect was matched against — or null when status is unanchored or unknown. Never the payee's business name on its own if it isn't also what anchors this destination, and never a payment link's own host (stripe.com, buy.stripe.com — that names the processor, not the payee).
• label A business name, shown only alongside a proven or mismatch answer, and only when it derives from domain — never the payee's raw freeform text, which we never treat as an identity. null otherwise, including whenever status is unanchored or unknown. Display it if you like, but never decide on it.
• chain The rail the destination is on: usually ethereum, polygon, avalanche, bitcoin, solana or litecoin, though a platform's published list may use its own chain names. url for any payment link or payment QR (EMV and UPI payloads included), or null.
• since The date of the proof behind level (YYYY-MM-DD). For a verified crypto address, the date its listing on a proven domain was first confirmed, never an older self-send date; for a claimed one, the date control was proven. For a payment link, the date it was registered; for a platform's list, the date the platform proved its domain. Or null. It follows level: when an address drops from verified to claimed, since moves to the date control was proven, which can be earlier.
• proofAgeDays Whole days since since. This is not freshness: an old proof can still be verified, and a lapsed listing reads claimed or unknown. Freshness lives in level. Because since follows level, proofAgeDays can jump when level changes.
• checkedAt When this answer was computed (ISO 8601, UTC).

Technical specs

Quick reference — the sections around this one carry the full explanation and the nuance a table can't.

Principles the contract keeps

• Proof, never reputation. We answer "is there a current proof tying this destination to a domain," never "is this party good." No risk scores, no success counts, no endorsements. A verified answer means a domain stands behind the destination, not that the deal is wise. The check is proof-only: it does not screen for sanctions or scams, so a verified destination has not been screened. Run your own screening, or the free wallet checker at almstins.com/wallet-checker, separately.
• Always pass expect. Without it you only learn that some proof exists for this destination. With it you learn whether it is tied to the party you intend to pay. The second is the product, and the rule above requires it. Take expect from your own records, never from the page that supplied the address.
• 503 is not unknown. A 200 with status unknown means the registry has no current proof: act on your fail-closed policy and hold. A 503 means the check itself is unavailable: retry with backoff, honoring Retry-After. Treat any other 5xx the same way. We will never disguise an outage as an absence of proof.
• Nobody approves anybody. Payees prove their own destinations (a self-send, a file on their own domain) or register payment links to their own accounts. We maintain no list of legitimate businesses and decide nothing. We check proofs the way a browser checks certificates.
• The contract is additive-only. Fields are added, never removed or repurposed. New status values may be added: treat any status you do not recognize as a hold. The v field bumps only on a breaking change, which we intend never to ship.

Limits and keys

Anonymous calls are free and stay free: 30 requests per minute per IP, enough for a human-paced agent. For fleets, a key raises that to 300 per minute, and you issue it yourself: claim your domain from a free account, publish one DNS TXT record carrying the challenge, and the key mints. Nobody reviews an application, because there is no application. Send it as Authorization: Bearer <key>. A revoked or malformed key gets 401, never a silent downgrade, so your fleet knows the moment a key stops working.

Rate-limited calls return 429 with Retry-After. The check makes no outbound requests and reads only proof state that is already public — which is why keys can be self-served: a leaked key is a quota nuisance, not a breach.

Cache your results. Proof state changes slowly, so a proven answer with level verified is safe to cache for a few minutes (we suggest 5 to 15, keyed by value plus expect) rather than re-checking the same destination on every invoice in a batch. On a 503, retry with backoff, and your policy may reasonably honor a recently cached proven answer while the check is unavailable. Never cache your way past a mismatch or an unanchored, and never treat a 503 as unknown: an outage is not an absence of proof, which is exactly why the two are different signals.

FAQ

If you are the one being paid

Agents that follow this page proceed only on a verified answer. A self-send (Level 1) proves you control an address, and it answers unanchored, which careful agents hold for a human. To be paid by agents without a hold, reach Level 2, domain-verified: publish the small file on your site that proves your domain, and list your receiving addresses in it. The file is what makes an address verified. A DNS record also proves your domain and attaches your business name, but it lists no addresses, so on its own it leaves your addresses claimed. An address you already proved by a self-send becomes verified once you list it in the file and verify the domain, and goes back to claimed if the file stops listing it. If your dashboard asks you to prove a wallet again first, do that, then verify the domain again. A listed address stays verified only while your listing has been re-confirmed within the last 24 hours, and its since date is when the listing was first confirmed, not your older self-send. Neither level touches a wallet connection or a key: prove your domain and list your receiving addresses. An unproven destination is not accused of anything. It is simply invisible to an agent that checks, the way an unencrypted store is invisible to a careful customer.

More than a couple of addresses to list? Publish an encrypted roster instead of maintaining the plain file by hand: your browser encrypts the list to our public key before it ever leaves your computer, so the published file is unreadable to anyone but us, with nothing for your own hosting to check or protect. Adding or removing an address from the roster takes effect the next time it's checked, not on a delay. See the roster tool in your dashboard.

Platforms publishing many addresses serve a live list from their own domain at /.well-known/payment-addresses and connect it from a proven entity. The path carries no vendor's name on purpose: the format is meant to be boring, and anyone is free to serve or consume it. During early access, publishing a platform list is by approval: email support@almstins.com to request access.