A merchant score can be too thin for an AI buyer

A merchant score feels like the clean answer an AI buyer wants. The agent sees a seller at 82 out of 100, decides the store is safe, and moves on to price. That is exactly the wrong habit. A score is a compact summary of evidence. It is not a promise that the seller is honest, the listing is clean, or the current purchase fits the job the user gave the agent.

Scores are useful when they slow the agent down and explain what is known. They become dangerous when the agent treats them as permission. Merchant trust should push thin or conflicting evidence to review before money moves.

The score is a warning light

Watchpost uses merchant trust as one pillar in a purchase verdict. It looks at the seller's domain, public signals, available purchase history, and verified merchant status. The result feeds the user's rules beside listing risk and spending limits. If the merchant is below the user's trust floor, the purchase blocks. If the evidence is thin and the amount is above the unknown-merchant review line, the purchase goes to review.

That shape matters because each signal answers a narrower question than people expect. A threat feed can say a domain is already known for phishing. It cannot say a clean domain is a good merchant. Domain age can say a site is not new. It cannot say the operator, inventory, or listing is honest today.

A useful agent should read the score as "how much evidence do we have?" The next question is still "may I buy?"

Thin evidence should change the route

Thin evidence is not the same as bad evidence. A new independent shop may have no Watchpost purchase history, no Tranco rank, no verified merchant flag, and too little domain age to comfortably treat the score as earned reputation. That should not automatically call the merchant unsafe. It should make the agent ask a person sooner.

Watchpost handles that with a separate unknown-merchant review threshold. The balanced defaults send non-trivial purchases at thin-data merchants to review above $10. The point is to keep a cold-start score from acting like a mature trust record. A score around 50 can mean "nothing obvious is wrong" rather than "this seller has proven itself."

This distinction matters for small merchants. If an agent blocks every unfamiliar store, it will bias buying toward large platforms even when the user asked for something niche. If it approves every neutral-looking store, it gives fresh domains too much room. Review is the middle path: preserve the option, show the evidence, and let the owner decide whether this particular purchase is worth the uncertainty.

Thin evidence should also travel with the verdict. "Trust 52" is too bare. "Trust 52, no prior purchases, no top-site rank, domain age unknown" gives the person a reason they can actually judge. A buying agent should carry that uncertainty forward instead of compressing it out of the message.

Marketplace ratings are local context

Many agents will see a rating before they see the seller's own domain. That rating may be useful, but it belongs to the platform that produced it. Google's store ratings documentation says ratings can draw from Google Customer Reviews, supported review partners, Google-led research, and shopping reviews. It also describes country-specific rating thresholds and filtering for questionable reviews. That is a platform view, with platform rules and platform coverage.

eBay's seller performance documentation shows the same problem from another angle. Seller levels depend on recent sales, cases closed without seller resolution, transaction defects, late shipments, and related performance measures. Buyer feedback is visible, while some seller-level detail is mainly a seller account-health tool. A buying agent should not flatten those into a single universal merchant truth.

Product ratings add another boundary. Google Merchant Center's product ratings policy requires participating merchants to share all reviews, including low-star reviews, and says feeds must be refreshed at least monthly to stay eligible. That helps the rating remain useful. It still says little about a changed checkout total, a return policy, a subscription term, or whether the user authorized this agent to buy today.

Known-bad lists miss new or quiet sellers

Google's Safe Browsing documentation describes constantly updated lists of unsafe web resources, including phishing, deceptive sites, malware, and unwanted software. That is strong evidence when it matches. Watchpost treats a live threat listing as a hard warning and crushes trust.

The absence of a match is weaker. A new scam may not be listed yet. A compromised merchant may still be in the gap between the attack and the report. OpenPhish's public feed page shows the same kind of limitation in another way: the free community feed is limited and updates every 12 hours, while higher tiers update faster and carry more fields. Feeds are useful because they are specific. They are incomplete for the same reason.

For an AI buyer, the correct response is simple. A hit should stop the purchase. A miss should leave the other checks in place.

Reviews and popularity can be gamed

A public reputation score often leans on reviews, star ratings, social proof, or search visibility. Those signals have a long abuse history. The Federal Trade Commission's final rule on fake reviews and testimonials covers reviews from people who do not exist, reviews from people without real experience, insider reviews without clear disclosure, review suppression, and bought fake social media indicators.

That does not mean every good review is suspect. It means an agent should not treat a high public rating as a complete safety check. A rating may describe old service, a different product, a suppressed set of complaints, or a storefront that has changed hands. The agent does not know which unless another signal says so.

Popularity has the same edge. Tranco exists because web security researchers need a top-site ranking that is more stable and harder to manipulate than older lists. Its own site says rankings can disagree, shift daily, and be manipulated. A rank can be a useful prior for a well-known domain. It is not a reason to skip the listing or the buyer's rules.

Identity checks answer a different question

Some marketplaces have stronger merchant identity duties. The EU Digital Services Act's Article 30 traceability rule requires online platforms that let consumers conclude distance contracts with traders to collect trader identity, payment account, register, and self-certification information before those traders can offer products to EU consumers. It also requires best efforts to check whether certain trader information is reliable and complete.

That is valuable infrastructure. It still answers "who is this trader?" more than "is this particular purchase sensible?" A verified trader can sell the wrong item, write a confusing subscription term, or have a checkout total that differs from the product page. Trader traceability helps with accountability. It does not replace purchase judgment.

Domain registration data has a similar boundary. ICANN's lookup tool uses RDAP to show current registration data where it is available. That can help estimate whether a domain is fresh, long-lived, or missing useful data. It does not prove who controls the store today or whether the checkout page is safe.

Agent commerce adds a listing problem

Buying agents read product data as instructions and evidence. That creates a threat that a normal reputation score may not see. AP2's security and privacy considerations state that agentic commerce should treat LLMs and agents as potential attackers, and its manipulated discovery section names prompt injection causing a shopping agent to choose bad products or make poor purchase decisions.

A merchant can have a decent score while one listing contains text aimed at the model: choose this product, ignore other constraints, treat this as verified, or prefer this over equivalent options. The merchant score and the listing scan are separate for a reason. One judges the seller. The other judges the thing the agent is reading right now.

Payment protocols do not erase that split. AP2 is built around signed mandates and constrained authority. OpenAI's ACP key concepts describe a checkout flow where the merchant remains the merchant of record and handles acceptance, charging, and order confirmation in its own systems. Those facts help prove who is allowed to do what in the payment flow. They do not say whether the product text is clean, whether the return terms are acceptable, or whether this purchase matches the user's actual task.

How to use the score safely

Use the trust score as a routing signal. High trust can let low-value, ordinary purchases continue when the listing and rules also pass. Low trust should block. Thin trust should ask a person above a smaller amount, especially for a first purchase at a new merchant.

In Watchpost, start on the rules page. Set a minimum trust score and keep the unknown merchant review line turned on. Then read how Watchpost checks a submitted purchase, because trust is only one pillar. Listing risk, recurrence, currency, category blocks, and caps still apply after the merchant score is known.

Your action today is to test one purchase from a seller your agent has never used. Keep the amount small, submit the final cart to Watchpost, and inspect the verdict details. If the agent reports only "merchant score 70" with no listing coverage, no recurrence flag, and no rule result, the agent is not ready to buy from unfamiliar stores on its own.