Online stores, marketplaces and omnichannel retailers are impersonated more aggressively than almost any other sector, because the payoff is immediate: a working card form on a page that looks exactly like your checkout. The Phishing Detection API gives your platform team, your fraud manager and your edge a fast domain verdict they can act on.
390,000+ DNS-verified active phishing domains, rebuilt every 24 hours
A cloned shop is not a crude imitation any more. It is your catalogue, your photography and your checkout flow, served from a domain that resolves.
The mechanics of a counterfeit storefront are almost boring in their simplicity. To a shopper arriving from an advertisement, the site looks like a normal seasonal promotion from a brand they already know — because almost all of it genuinely is that brand's own material.
An operator lifts the retailer's catalogue, often straight from the public sitemap or the same structured-data markup the retailer publishes for search engines.
Product titles, descriptions, size charts, review counts and hero photography all come across intact onto a cheap stack, so the clone renders like the original on every page but one.
The payment step no longer posts to a gateway. It posts to a form that captures the primary account number, expiry, security code and billing address in plain text.
Keyword placements against the brand's own product terms, plus short-lived video and carousel creatives on social platforms, paid for exactly as long as the ad account survives.
Domain registrations that later resolve as retail-impersonation infrastructure cluster around the trading peaks: the weeks before Black Friday and Cyber Monday, the run-up to Singles' Day, the end-of-season clearance windows and the back-to-school period. Operators register in batches, park the domains while they age slightly, then bring them live at the exact moment shoppers are conditioned to expect a discount so steep it would normally look suspicious.
In banking or professional services the lure usually arrives by email. In retail it arrives through paid search and social advertising. Shoppers who never opened an email and never received a text still land on the clone, because they searched for a product and clicked the first commercial result. Your email security stack, however good, is not in that path at any point.
The consequence lands on the retailer regardless of fault. Customers who paid a cloned checkout raise disputes with their issuing bank, and many file against the legitimate merchant because that is the brand name they believe they bought from. Customer service absorbs the contact volume, trust and safety absorbs the takedown requests, and finance watches the chargeback ratio climb toward the thresholds that trigger acquirer monitoring programmes — while the same shoppers post publicly about a brand that took their money and never shipped. The direct fraud loss is frequently the smallest line item in the whole episode. A head of e-commerce watching the trading calendar and a fraud manager watching chargeback ratios are effectively watching the same clock from different ends.
Most retail security spend sits on the inbound perimeter and on payment fraud scoring. Neither of those layers sees a domain that a customer reached from an advertisement, and neither of them can tell a customer-service agent whether the link a shopper just pasted into chat is hostile.
A lookup against a DNS-verified list of actively resolving phishing domains is a small, cheap, fast decision that fits anywhere a URL passes through your systems. It does not replace brand monitoring or fraud scoring; it gives every one of your surfaces the same answer in under fifty milliseconds.
Not a generic threat taxonomy: the six recurring shapes that land in retail inboxes, phones, seller consoles and back-office systems.
Customers are targeted with lures that borrow the retailer's identity, and the retailer's own people are targeted with lures that borrow the identity of the systems they use every day. A store associate reads a message about a shift swap; a merchandiser reads a message about a purchase order; a marketplace seller reads a message about a policy violation on a listing. The shared characteristic is urgency attached to money or account access, and a link to a domain registered recently that resolves right now.
The six patterns below are ordered roughly by the volume most retailers report internally rather than by financial impact. Delivery-fee smishing dwarfs everything else on raw message counts, while supplier invoice redirection produces individually large losses from a handful of successful attempts. Each pattern ends at a domain, which is exactly why a domain-level check is worth wiring in at more than one point in the stack.
A text claims a parcel is held pending a small customs or redelivery charge and links to a landing page that captures card details. Volume peaks in the fortnight after a trading event, when a large share of customers genuinely are waiting on a parcel and cannot recall which carrier has it. The page is usually mobile-only and short-lived.
Loyalty balances and gift-card funds are close to cash and rarely protected by strong customer authentication. Lures offer point expiry warnings or a balance check, then collect the account credential or the card number and PIN directly. Drained balances usually surface first in customer service, not in fraud monitoring.
A message confirms an expensive order the recipient never placed, with a cancel link, or offers a refund that requires re-entering card details to receive. Both variants exploit the sheer density of legitimate transactional mail around peak trading, when a customer may receive a dozen genuine order updates in a week.
Sellers are told a listing breached policy or a payout is suspended, and are sent to a cloned seller console sign-in. Once inside, the attacker changes the settlement bank account and lists high-demand goods that will never ship. The marketplace operator inherits the refunds and the reputational damage.
A message that appears to come from a supplier or dropship partner announces new remittance details, often supported by a cloned supplier portal for confirming the change. Losses here are individually large because a single redirected purchase-order payment can be six figures, and detection typically waits until the real supplier chases the invoice.
Front-line staff receive lures imitating the scheduling app, the payroll portal or the corporate identity provider. The prize is access to back-office and POS-adjacent systems: price overrides, refund authorisation, inventory adjustments and, in the worst case, a route toward systems inside the cardholder data environment.
The API is one HTTP call, so the real design question is which surfaces call it, and what each of them does with the answer.
On a headless commerce platform the storefront is a rendering layer, and the URLs that matter mostly live elsewhere: in the transactional mail your ESP sends, in user-generated content stored against products, in seller and affiliate records held in the marketplace console, and in whatever your customer-service agents paste into a ticket. A platform engineer can usually list them in an afternoon, and each has a different appetite for latency and a different correct action on a positive verdict.
Extract the registrable domain from the URL, call /api/v1/check with it, and branch on is_phishing. The response also carries category, dns_status, last_checked and a confidence value, which is 0.98 on a hit and 0.0 on a miss. Under fifty milliseconds makes it realistic inline where a human is already waiting; fractions of a cent per credit make it realistic at volumes a heavier analysis product could never carry.
A retailer that wants enforcement at the edge subscribes to the feed, pulls the CSV after the 04:30 UTC export, and pushes the domain list into CDN or WAF rules, into a DNS resolver policy for corporate and store networks, or into the deny list a secure web gateway consults for the POS estate and back-office workstations. No per-request credits, no added latency, at the price of being a day granular rather than live.
Most retailers end up running both: the feed for blanket enforcement across the estate, and the API for the moments where a decision has to be made about one specific URL right now.
What happens between a customer tapping a link and your system deciding whether to let them through.
const ENDPOINT = 'https://phishingdetectionapi.com/api/v1/batch';
/**
* Called by the ESP webhook that renders an order-confirmation
* template. Any hostile domain in the rendered body stops the send
* and raises an incident for the platform on-call.
*/
async function screenTemplateLinks(renderedUrls) {
const domains = [...new Set(
renderedUrls.map(u => new URL(u).hostname.replace(/^www\./, ''))
)].slice(0, 100); // batch limit is 100 domains
const res = await fetch(ENDPOINT, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ apikey: process.env.PDA_API_KEY, domains })
});
const data = await res.json();
const hits = data.results.filter(r => r.is_phishing);
if (hits.length) {
throw new Error(
'Send blocked, phishing domain in template: ' +
hits.map(h => h.domain + ' (' + h.category + ')').join(', ')
);
}
return { checked: data.checked, credits_used: data.credits_used };
}curl -s -X POST https://phishingdetectionapi.com/api/v1/batch \
-H "Content-Type: application/json" \
-d '{
"apikey": "YOUR_API_KEY",
"domains": [
"seller-shop-updates.example.com",
"track-my-parcel-fee.example.net",
"brand-outlet-clearance.example.org"
]
}'
{
"results": [
{ "domain": "seller-shop-updates.example.com",
"is_phishing": true, "category": "phishing/malware",
"dns_status": "resolves", "confidence": 0.98,
"last_checked": "2026-07-27T04:30:00Z" },
{ "domain": "track-my-parcel-fee.example.net",
"is_phishing": true, "category": "phishing/malware",
"dns_status": "resolves", "confidence": 0.98,
"last_checked": "2026-07-27T04:30:00Z" },
{ "domain": "brand-outlet-clearance.example.org",
"is_phishing": false, "category": null,
"dns_status": null, "confidence": 0.0,
"last_checked": null }
],
"checked": 3,
"phishing_found": 2,
"credits_used": 3
}User-generated content is the highest-volume candidate. Reviews, product questions, community answers and seller storefront descriptions all accept free text, and a link inside a five-star review of a popular product is read by more people than most of your marketing email. Screen the domain at submission and again on any edit, and hold anything that returns a hit for moderation rather than publishing it and cleaning up afterwards. The same treatment applies to seller onboarding, where the registration form captures a business website and often a support URL: a batch call at application time is a single credit per domain and gives the trust and safety team a documented reason to decline.
Affiliate and partner link screening is the same problem with different economics. Affiliates are paid to send traffic, which means some fraction of them will experiment with landing pages you did not approve. Running the destination domains through a nightly batch job catches the ones that have started pointing at infrastructure already known to be hostile. Customer-service macros deserve a lookup too, because agents are the people most likely to be handed a suspicious URL by a customer who is already worried, and a verdict rendered directly in the ticket view removes the temptation for an agent to open the link and find out.
Finally, push the daily feed outward. The same list that answers your API calls exports as CSV with domain,category,dns_status columns, which is trivially loadable into CDN or WAF edge rules, into a DNS resolver policy covering the store network and the POS estate, and into the blocklists your endpoint tooling consults on corporate laptops. Retailers running a PIM, an OMS and a seller console alongside the storefront tend to find that the feed covers the machine-to-machine surfaces cleanly while the API covers everything with a human in the loop. See the daily feed page for the export format and the API documentation for the full response schema.
A working list for the platform engineer who has the API key and needs to decide where the calls go.
Every verdict comes from the same daily-rebuilt list of domains that were resolving when they were last checked.
Domains arrive from curated threat-intelligence and OSINT sources, then every one of them is resolved through rotating proxies using fifty concurrent threads with a ten second timeout. Only domains holding an active A record are retained; anything that stops resolving is pruned on the next rebuild. The surviving set is deduplicated, classified, diffed against the previous day to produce a changelog, and loaded into both the API and the CSV export. That is why a hit means a domain that was live, not a domain that was reported once in 2023.
What the frameworks actually ask of a retailer, and where a domain lookup does and does not help.
PCI DSS applies to any entity that stores, processes or transmits cardholder data — for most retailers, the storefront checkout, the call-centre payment flow, the POS estate and every system in scope of the cardholder data environment. The v4.0 revision is stricter than its predecessor about people, and it expects organisations to have mechanisms in place to detect and protect personnel against phishing rather than treating awareness training as the whole answer. That matters most for retailers with large, distributed, high-turnover store workforces, because the personnel in scope are not only the head-office security team but everyone whose credentials can reach a connected system.
The other v4.0 emphasis retailers should read carefully concerns payment pages: controls over the scripts loaded into a page that takes cardholder data, and mechanisms to detect unauthorised modification of the payment page as delivered to the consumer browser. This is a direct response to skimming attacks that inject a script into a legitimate checkout, and it sits alongside the counterfeit-storefront problem rather than replacing it. One is an attack on your page; the other is an attack using a copy of your page. A PCI compliance lead scoping v4.0 work should treat script integrity and impersonation monitoring as separate workstreams with separate evidence.
For customer data, GDPR Article 32 requires security measures appropriate to the risk, and Articles 33 and 34 govern breach notification, including the seventy-two hour window for notifying the supervisory authority. A retailer whose customers have had loyalty accounts drained after a credential-harvesting campaign will need to reason quickly about whether a notifiable personal data breach has occurred, and that reasoning is far easier when there is a dated record of the domains involved and when they were first observed as live. Detection logs from a screening layer are useful evidence of both the timeline and the state of your technical measures.
Beyond data protection there is a broader consumer-protection and advertising exposure specific to retail. When a brand's name, trade marks and product imagery appear on a cloned site, the consumer harm is commercial as well as informational: people paid for goods that were never going to arrive. National consumer-protection authorities and advertising standards bodies take an interest in misleading commercial practices conducted under a recognised brand, and while the retailer is a victim rather than the trader responsible, it is the retailer who will be asked what it did on becoming aware. Being able to show a systematic screening and escalation process is a materially better answer than pointing at an inbox of customer complaints.
Marketplace operators carry an additional duty to police the conduct of the sellers on their platform, and regulatory expectations in several jurisdictions have moved steadily toward requiring verification of trader identity and prompt action on notified illegal content. A domain lookup is a narrow but genuinely useful control here, because it applies at the two moments that matter: when a seller is onboarded, and when a seller publishes a link.
Be plain about the limits. A domain-reputation lookup tells you whether a domain appears on a DNS-verified list of active phishing infrastructure. It does not satisfy PCI DSS on its own, does not constitute a risk analysis, does not monitor payment-page scripts, does not perform takedowns, does not analyse message content, and does not verify a trader's identity. It is one control that produces evidence, contributing to programmes described in financial services, logistics and supply chain and telecommunications in much the same way.
Where the calls typically go in a retail stack, and what comes back from each one.
Signals in the response
The six questions that come up most often when a retailer scopes this work before peak trading.
Count the distinct domains you will screen, not the URLs. A retailer sending two million transactional mails a month is still only checking the handful of unique domains that appear in the templates, so template screening costs almost nothing. The volume comes from user-generated content and seller activity, where each submitted link is one credit.
Work it from the packs: Professional is $249 for 100,000 lookups at $0.0025, Business is $499 for 250,000 at $0.0020, and Enterprise is $999 for 750,000 at $0.0013. Credits are valid for twelve months, so buying a larger pack in September to cover the whole trading peak is usually cheaper than topping up in November. Full detail is on the pricing page.
A lookup returns in under fifty milliseconds, which is small next to the round trips a checkout already makes to a PSP or gateway. That said, treat it as an advisory call rather than a hard dependency: set an aggressive client timeout, run it concurrently with other checkout work rather than in series, and decide in advance what happens if the call does not return in time.
Most retailers fail open in the checkout path and fail closed in the moderation and onboarding paths, where nobody is waiting on a page render. Keep the key server-side in every case; it must never appear in client-side code.
Maintain your own allowlist in front of the lookup and check it first. Your own domains, your PSP and gateway hosts, your ESP click-tracking domains, your CDN asset hosts and your established affiliate networks should short-circuit before a credit is ever spent. That saves money and removes the largest category of operational surprise.
Beyond that, the database only retains domains that resolved at verification time with an active A record, and prunes those that stop resolving, so it does not accumulate stale entries. If something you consider legitimate returns a hit, treat it as a signal worth investigating rather than an error to suppress, since compromised legitimate infrastructure is a common hosting choice for these campaigns.
It depends who is on the other end of the decision. For content you are about to publish or mail on your own behalf, block: there is no reason to distribute a link to a domain on the list, and the customer never sees the interruption. For seller onboarding and affiliate records, block and route to human review, because a decline needs a documented basis.
For a customer who has already clicked something, an interstitial warning that names the domain and offers a route back to your genuine site usually works better than a hard block. It preserves the customer's ability to make a decision while making the risk explicit, and it generates a support contact you can measure.
Feed, in almost every case. Edge rules want a static list they can evaluate locally at line rate, and an outbound API call from an edge worker on every request would add latency and consume credits at request volume. The daily feed subscription starts at $499 per month, exports as CSV or JSON after 04:30 UTC, and gives you domain,category,dns_status to load straight into a rule set or resolver policy.
Use the API for the surfaces where a specific URL needs a decision at a specific moment, and the feed for blanket enforcement. See the daily feed page for the subscription detail.
Directly, it does not, and it would be dishonest to claim otherwise. A shopper who clicks a paid search advertisement, lands on a clone and pays never touches your infrastructure, so no lookup of yours runs. What screening gives you in that scenario is speed of knowledge rather than prevention.
In practice retailers use the API to check domains reported by customers and by their own brand-monitoring vendors, to confirm that a reported domain is currently resolving, and to feed confirmed hostile domains into ad-platform complaints, registrar abuse reports and their own warning pages. The prevention side of the work sits with takedown and advertising enforcement, which this product does not perform. What it does is tell you quickly and cheaply whether a domain is live and known, which is usually the first question in that process.
Register for an API key, point a batch call at the domains already sitting in your seller records and review queue, and see how many of them are resolving phishing infrastructure right now.
Also useful: credit packs and pricing · the daily threat feed · the e-commerce use case
