A payment business is judged on the company it keeps. The URL an applicant types into the onboarding form, the descriptor that appears on a statement, the hosted link a merchant sends to a cardholder, the page that renders during a step-up challenge — each is a hostname somebody else chose, and each can be checked against a DNS-verified list of live phishing infrastructure before it becomes your problem.
Almost nothing in this threat model requires your own systems to be breached. It requires a merchant, a cardholder or an integrator to be deceived, and the settlement chain to carry the consequence upward.
A processor's security posture is usually described in terms of its own perimeter: how the vault is protected, how keys are managed, how the authorisation path is segmented. That framing is necessary and it is also where the least of the actual loss originates. The transactions that end up as fraud, dispute and scheme scrutiny mostly begin outside your estate — on a merchant's compromised storefront, on a look-alike checkout that never touched your gateway, on a step-up page a cardholder believed was yours, or in a portal session where a merchant's own credentials had already been taken.
Follow one case to its conclusion and the mechanics are clear. A merchant is onboarded whose stated website is, or later becomes, a credential-harvesting page. Card data collected there is tested elsewhere, and disputes arrive against the merchant identifier you underwrote. If the merchant is thin on capital — the normal condition for the accounts most likely to be problematic — the chargebacks pass through to you as the acquiring party. Excess dispute ratios then invite scheme monitoring, and the associated fines and remediation costs are levied against the acquirer regardless of who wrote the page.
Cardholders do not distinguish between the gateway, the acquirer and the merchant when their card is misused after a checkout that carried your brand at the bottom of the page. Issuers, on the other hand, distinguish very precisely: they track which acquirers and which descriptors generate disproportionate fraud, and they respond by declining more aggressively against those identifiers. That is a slow, quiet cost that shows up as approval rates rather than as an incident, and it is felt by every honest merchant in the portfolio.
A large share of the relevant infrastructure is identifiable by hostname, and hostname is something you already collect at several points. The applicant's website URL is captured at onboarding. The descriptor and the merchant's live storefront are known throughout the relationship. Hosted payment links carry return and callback URLs. Portal sessions record where a session came from and where webhooks send. Each is a string testable in under fifty milliseconds against a database of hosts confirmed to be resolving and confirmed hostile.
This determines how you build policy on top, so it belongs at the start rather than in a footnote. This is a known-bad lookup: a confidence of 0.98 for a confirmed match and 0.0 for everything else, with no intermediate score and no assessment of pages the database has never observed. A domain registered and used inside the same hour will not be present. It is a high-precision negative-list control that removes the proven cases, and it belongs alongside your underwriting judgement, your monitoring models and your dispute analytics — not in place of any of them.
Three distinct problems with three distinct owners — underwriting, product, and account security — connected by the fact that all three turn on a hostname.
Every merchant application collects a URL. It is used to confirm the business exists, to check the goods sold match the declared category code, and to verify that terms, refund policy and contact details are present. In most onboarding stacks a human opens it, forms an impression in about forty seconds, and moves on. That is a weak use of a strong signal, and it degrades further as volume grows and the review gets compressed.
Primary site, checkout path, terms page, privacy policy, support page and any marketplace storefront. Batched, that is one request at one credit per distinct domain — trivial against the cost of a bad approval.
A confirmed match should escalate to manual underwriting with the verdict attached, not reject silently. You want the case reviewed and recorded, because it is also a signal about the introducer or ISO who brought it.
A non-match means only that the host is not on the list. Brand-new infrastructure stood up for a brand-new application is exactly the case the database has not seen yet, so it must not relax any other check.
A site clean at approval can be compromised, sold or repurposed months later. A periodic sweep of the whole portfolio's stored URLs is the control that catches the drift, and it batches efficiently.
Hosted checkout, payment links and invoice-by-email exist because they remove compliance burden from small merchants, and they do that well. They also create a facility where a merchant can generate a page on your domain, with your certificate and your branding, containing text and destinations the merchant controls. Somebody who obtains a merchant account — through a fraudulent application or through taking over a legitimate one — gets a credible page on infrastructure that is not theirs.
Return, cancel and webhook URLs are set through your API or portal, so screen them at write time rather than at redemption time. A rejected configuration is a far cheaper event than a redirect that already fired.
Line-item descriptions, custom messages and receipt footers accept text and therefore accept hostnames. Extract and check them on the same pass that sanitises the markup.
A merchant who has issued eleven links in a year and issues four hundred this afternoon is worth a look, particularly when the linked destinations are new. Volume anomaly plus a domain verdict is a much stronger signal than either alone.
Invoice links can stay open for weeks. A destination that was clean at creation may not be clean at payment, so re-screening open links on a schedule closes a gap that creation-time checking alone leaves.
Merchant portal access is the single most consequential credential in the relationship, because it is where settlement instructions live. The lure written against it is well-worn and effective: a notice that a payout is on hold pending verification, a warning that the account will be suspended for a compliance reason, a message about a batch that failed to settle. Each drives the merchant to a login page that is not yours, and each is plausible because those things genuinely do happen.
Where you operate shared support or relationship mailboxes, checking hostnames in inbound links catches replies that quote a fake portal address back at you and gives support a definite answer to give.
Impose a deliberate hold and an out-of-band confirmation on bank-detail changes, to a number already on file. No domain check substitutes for this; it is the control that catches the cases nothing else sees.
A changed callback destination can quietly exfiltrate transaction metadata without touching settlement at all. Screen the hostname at save time and notify the merchant through a channel the session cannot alter.
Use a single hostname for merchant login, never a campaign variant, and say so in onboarding material. Every alternative address you legitimately use makes the fraudulent one easier to accept.
A challenge that interrupts a checkout, renders in a frame or a redirect, comes from a domain the cardholder has never seen, and asks for a code. That is the phishing template, and it is also the genuine flow.
Strong customer authentication improved a great deal when it moved away from static passwords, but the step-up experience left a structural weakness behind: it normalised the very interaction pattern that security advice tells people to distrust. A cardholder completing a purchase is interrupted by a page that does not look like the merchant, does not look like their bank's main site, is served from a domain belonging to an access control server they have never heard of, and requests a one-time code. Cardholders were trained by the flow itself to accept exactly this, and to accept it quickly, because they are mid-purchase and want to finish.
The attack is live rather than store-and-forward, which is what makes it effective against one-time codes. The victim is on a look-alike merchant checkout; the attacker relays details into a genuine transaction; the genuine challenge fires and the victim is shown a convincing copy of it; the code they enter is relayed in seconds. Nothing about the code is weak — it is used exactly once, for exactly the transaction it was issued against, just not the transaction the cardholder believed they were completing. Any defence reasoning only about code entropy misses this entirely.
A processor cannot fix this alone, and it would be dishonest to suggest a domain list does. What a processor can do is reduce the number of distinct hostnames a legitimate flow presents, resist the temptation to introduce new challenge domains for campaigns or partners, and make the delegated-authentication path consistent enough that anomalies read as anomalies. On the detection side, hostnames from merchant configurations, referrer data and abuse reports can be checked, and confirmed matches become resolver entries and takedown evidence.
Wherever the challenge can be removed entirely, it should be: every transaction pushed to a frictionless exemption through risk-based analysis is a transaction with no step-up screen to imitate. That case is usually made on conversion grounds, but it is equally a security case, and it is worth making in those terms when the audience is a risk committee rather than a product team. Teams building the surrounding detection usually pair this with the patterns on our fintech and banking and finance pages.
Four numbers that determine whether this fits an authorisation-adjacent pipeline, and three properties that determine how you operate it.
Inclusion requires an active A record confirmed through rotating proxy infrastructure. Hosts that stop resolving fall out, so the file stays a picture of what is live rather than an archive that grows forever and drags your false-positive rate up with it.
The full database downloads as CSV with domain,category,dns_status, or as JSON, and downloads are unlimited on a subscription. High-volume screening runs locally; onboarding decisions and investigations use /check and /batch.
The /stats endpoint reports database size and last update with no API key, no credits and no authentication, which makes it a clean external probe for confirming the upstream build advanced independently of your own ingestion.
The operational shape that suits a payments environment is local-first. Hold the database in memory behind your risk service, refresh it shortly after the daily build, and apply the shipped changelog of additions and removals rather than reimporting the whole file. Screening then adds no network hop to any path that sits near authorisation, and the failure mode of a missed pull is a slightly stale list rather than an unavailable dependency — which is the right trade when the alternative is deciding in advance whether a timeout fails open or fails closed on live traffic.
Keep API calls for the low-volume, high-consequence work where currency matters more than throughput: an onboarding decision a human is about to record, an investigation into a suspected merchant ring, a dispute case where a dated verdict will be quoted in evidence. At one credit per domain those checks are immaterial against the outcomes they inform, and the response gives you checked, phishing_found and credits_used for the audit line.
Card-scheme and acquirer obligations are written as outcomes. The left column is the obligation as an assessor states it; the right is the operational consequence for the screening pipeline.
last_checked date.Two cautions about how this is presented internally. The first is that no external service makes an organisation compliant with anything, and a screening control should never be written into an attestation as though it discharged a requirement on its own. What it does is produce specific, dated, reproducible evidence that a named control operated — which is what an assessor actually wants, and which is much easier to hand over than a narrative description of intent.
The second caution is that evidentiary value depends on what you keep. A merchant record that says "approved" tells a later reviewer nothing. A merchant record that says the stated website was checked on a given date, returned is_phishing false with a dns_status of resolves, and was re-screened on a defined cycle, answers the question directly — including in the awkward case where the site was compromised afterwards and you need to show when it was and was not clean.
Assessors, scheme reviewers and sponsor banks all converge on similar questions. These are the outputs worth designing for from the start rather than reconstructing later.
For every merchant application, the set of hostnames submitted, the verdict returned for each, and the timestamp. This is the artefact that answers "how do you know what the applicant was selling", and it costs one credit per distinct domain to produce.
is_phishing, category, dns_status, last_checked and the confidence value together reconstruct the decision context; a stored "pass" does not.A scheduled sweep of stored merchant URLs, run at whatever cadence your risk appetite justifies, with the run date, the number of domains checked and the matches found. The batch endpoint takes a hundred domains per request and returns checked, phishing_found and credits_used, which is a complete run summary in one object.
For network-level blocking, the artefact is the age of the loaded file. A daily pull shortly after the 04:30 UTC build, the applied changelog of additions and removals, a recorded file timestamp, and an alert at forty-eight hours covers what a reviewer will ask about a blocklist control.
/stats endpoint is useful here as an independent check on the source, letting you distinguish an upstream that has not advanced from an ingestion job of your own that has stopped.Counter-intuitively, the document that makes a control credible is the one describing what it does not do. Write down that this is a known-bad lookup, that a clean result means "not on the list" rather than "safe", that newly registered infrastructure will not be present, and that the control is one layer among several.
Three placements with different latency budgets and different economics, plus the arithmetic for sizing a portfolio re-screen.
The first placement is the onboarding gate, and it belongs after the application is complete but before any underwriting decision is recorded. Latency is irrelevant here — a human is going to look at this case within hours — so the API is the right mechanism and currency is the priority. Submit every distinct hostname from the form in one batched call, attach the verdicts to the case, and route confirmed matches into manual review with the evidence already present rather than leaving an underwriter to discover it.
This is where the portfolio arithmetic applies. A book of fifty thousand active merchants with an average of two stored URLs each is a hundred thousand domains, typically rather fewer after deduplication. Sent through the batch endpoint at a hundred per request, that is a thousand requests — a couple of minutes of wall time inside the ten-per-second limit — and a hundred thousand credits at most, which is the $249 Professional package at $0.0025 each. Run monthly it is a modest, predictable line; run weekly with a local pre-filter and the incremental cost falls further.
Transaction-adjacent screening, hosted-link configuration checks and in-scope network blocking are where the feed belongs rather than the API. The Daily Threat Feed is $499 per month or $499/month and adding historical archive access, priority support, custom format options, a dedicated account manager and 100,000 API credits — which in practice funds the onboarding and re-screen work above without a separate purchase. Downloads are unlimited, so cost does not track transaction volume.
Credits are monthly subscriptions via PayPal and billed monthly, with unused credits expiring at that point and a fourteen-day refund where under ten percent has been used. Above $4,000 bank transfer is available, which for most processors is the operative route. Larger tiers — Enterprise at $999/month for 750,000 lookups, Enterprise at $999/month for 750,000 lookups at $0.0010, Enterprise at $999/month for 750,000 lookups on the Enterprise plan with an SLA — exist for screening at scale. The full table is on the pricing page, delivery options are under daily feed, and teams pushing verdicts into detection tooling will want the SIEM integration notes.
Including the questions that expose the limits of the control, since those are the ones that decide whether it gets built correctly.
You can — responses come back in under 50 ms — but you should not want a synchronous external dependency anywhere near authorisation. The right pattern is to hold the database locally from the daily feed and match in process, so the check contributes no network latency and no availability risk to a path where a timeout forces you to choose between declining good transactions and silently skipping the control. Reserve API calls for decisions where a human is already in the loop and currency matters more than throughput: onboarding, investigations, dispute evidence.
No, and it is important not to buy it expecting that. Transaction laundering, prohibited goods sold behind a compliant-looking front page, and category-code misrepresentation are content and behaviour problems. This answers one factual question about a hostname: is it confirmed live phishing infrastructure. The overlap is real but partial — fraudulent merchant operations frequently reuse infrastructure that has already been used for credential harvesting, and that is where you get a hit. Everything else needs content classification, transaction pattern analysis and the underwriting judgement you already apply.
Liability turns on your rules and your sponsor's, not on this control, but the evidentiary position is what you can influence. If you can show the site was screened at approval with a dated verdict, re-screened on a defined cycle, and actioned within a defined window once the verdict changed, you are describing a control that operated as designed against an event outside your knowledge. That is a materially stronger position than "we looked at the website during underwriting", which is what most onboarding processes can actually evidence. The re-screen cadence is therefore the part worth arguing about internally — it is what converts a point-in-time check into an ongoing one.
Hostname-level blocking cannot address a credential-harvesting page served under a mainstream site-builder, form or file-sharing domain, because blocking that hostname would take down enormous amounts of legitimate traffic. That is a real gap in the whole category, not a quirk of one database. It is handled elsewhere in the stack — content inspection, sender reputation, merchant behavioural signals, and the abuse-reporting channels those providers operate. What domain screening removes is the dedicated hostile infrastructure, which is a large share of the volume and the share that is cheapest to eliminate automatically.
Do not wire a verdict directly to a decline. Route confirmed matches to manual underwriting with the verdict attached, and let a human decide with the full picture. Verification through an active DNS check keeps the false-positive rate low, but a rejected merchant is an expensive and public error, and the value here is in directing attention rather than in automating rejection. The one genuinely awkward case is shared hosting, where an applicant's site sits on infrastructure that also serves something hostile. Check the specific hostname rather than the address it resolves to, and treat a match as a question for the applicant rather than a verdict on them.
Partially, and only from the outside. You cannot block a page for a cardholder browsing on their own device and network. What you can do is verify candidate hostnames reported through fraud operations, use confirmed verdicts as the basis for takedown requests, and block them at your own resolver so staff, contractors and support terminals are covered. The structural mitigation is different and more effective: minimise the number of distinct challenge hostnames a genuine flow presents, avoid campaign-specific variants, and push as much traffic as your risk models allow into frictionless exemptions, so there is less challenge surface to imitate in the first place.
Mostly precision and price shape. Broad intelligence feeds carry many indicator types at varying confidence, which is valuable for investigation and noisy for automated gating. This is a single indicator type with a binary verdict, DNS-verified as currently resolving, priced either per lookup or as a flat unlimited feed. In practice processors run both: the broad feed informs analysts, and the narrow verified list drives automation at gates where a false positive is costly and an unexplained score is unusable. If your evaluation is "which single product covers the most ground", this is not that product.
The key is the username chosen at registration, so treat it as a credential with the same handling as any other service secret: held in your secret manager, injected at runtime, rotated on the same schedule as comparable credentials, and never present in a mobile bundle, front-end bundle, merchant-facing widget or page source. If merchants need a self-service link checker in your portal, front it with your own endpoint, rate-limit per merchant account, and log the queries — both to protect the key and because those queries are themselves a useful signal about which merchants are receiving suspicious mail.
Put the API at the onboarding gate where a human is already deciding, and the daily feed everywhere the volume is high and the latency budget is tight. Both produce dated, reproducible evidence an assessor can read.
