Requirements
A WooCommerce store with the Store API reachable (the default on current WooCommerce), and the ability to install a plugin and edit its settings. The plugin is dependency-free PHP and signs checkout terms with the built-in openssl extension, so there is no Composer step or external library. You do not change your theme, your payment gateway, or your human checkout form.
-
Install and activate the plugin
Copy the plugin into
wp-content/plugins/agent-gateway/and activate it. Activation creates the verification log table and adds an Agent Gateway settings screen under WooCommerce settings.wp plugin activate agent-gateway -
Get a merchant key
Request early access to receive an
mg_live_…key bound to yourmerchant_id. The key is sent as a bearer token from your server to the verify API and never belongs in the browser. -
Configure the settings
The plugin stores its configuration in a single
agent_gateway_settingsoption. Set it from the settings screen, or with WP-CLI:verify_api_url = https://verify.mandategate.com # the client appends /v1/verify api_key = mg_live_xxxxxxxxxxxx merchant_id = mch_store_01 policy_mode = monitor # monitor | standard | strict review_behavior = allow # allow | block, for review decisions fail_behavior = open # open | closed, when the API is unreachableKeep
fail_behavioronopen: if the verify API cannot be reached, checkout proceeds and the event is logged rather than blocking a sale. -
Verify in monitor mode
With
policy_mode = monitor, the plugin runs the full verification on every agent checkout and writes the decision it would have made, but denies nothing. Drive a checkout with Web Bot Auth headers, or let real agent traffic arrive, then read the log table:wp db query "SELECT decision, reason_codes, created_at FROM wp_ag_verification_log ORDER BY id DESC LIMIT 5"You should see rows with a
decisionand thereason_codesthat produced it. Human checkouts produce no rows at all, because detection keys on the agent's signature headers. -
Sign your checkout terms
Standard mode adds checkout attestation: the store signs its own checkout terms so the gateway can confirm the agent is paying the price the merchant set, not a figure the agent invented. Generate an ECDSA P-256 key, put the private PEM in
merchant_signing_key, and give the public key to the gateway with yourmerchant_idwhen you request access. With a signing key present, the plugin exposes the signed terms as acheckout_jwton the Store API cart, and the gateway begins emittingcheckout.*reason codes. -
Promote to standard mode
Switch to
policy_mode = standardandreview_behavior = block. Now an unverified agent is denied with a reason code, while an agent presenting a valid, cart-bound mandate and your signed terms checks out. Every decision, allow or deny, stays in the tamper-evident log.policy_mode = standard review_behavior = block fail_behavior = open # still fail-open: an outage never blocks a sale
How a verification flows
When an agent reaches checkout with Web Bot Auth headers, the plugin builds the request server-side, so the cart and merchant id come from your store rather than the agent, and sends a POST /v1/verify. It reads the decision and enforces it: an allow lets the order proceed, a deny stops it with an agent_gateway_denied response, and a review follows your review_behavior. The exact request and response shape is in the API reference, and every signal in the response is listed in the reason code reference.
Why human checkout stays safe
Detection keys on the presence of the Web Bot Auth signature triple. A human browser never sends those headers, so the verification code path is never entered for a human order, in any mode. Combined with the fail-open default, the worst case for a human shopper is no change at all. That is what lets you install in monitor mode on a live store with confidence, and decide to enforce later on your own evidence.