1. Overview

WolfPaw Antifraud integrates MaxMind's minFraud service into your Miva Merchant store to screen orders before payment is captured. Every checkout attempt is evaluated against MaxMind's fraud-detection network, built on transaction data contributed by merchants worldwide.

Depending on the service tier you select, minFraud assesses dozens of data points across five areas:

• The IP address — its own risk score, country, region, city and postal code with confidence levels, latitude and longitude, accuracy radius, time zone, the ISP and organization that own it, the autonomous system it belongs to, whether it is residential, business, cellular or hosting, whether it is a proxy, VPN, Tor exit or hosting provider, and how static or transient it is.
• The email address — when MaxMind first saw it, whether it is from a free or disposable provider, whether it is associated with known fraud, and separately the age, classification, risk and reachability of its domain.
• The billing and shipping addresses — whether the postal code matches the city, the distance between each address and the IP address, the distance between billing and shipping, whether each sits in the country the customer is connecting from, and whether the shipping address is one MaxMind associates with fraud.
• The phone number — whether it matches the billing postal code, its country, whether it is fixed line, mobile or VoIP, and the network operator.
• The transaction and the device — order amount and currency, browser and language, and a session identifier that lets MaxMind correlate repeated attempts from the same device, which is the signature of card testing.

Key capabilities

• Pre-payment screening — Orders are screened at the checkout screen, before any charge. High-risk orders are declined instantly with a customizable message.
• MaxMind results on every order — The risk score and the full technical response are written to two Order custom fields, so you can let the module block the clearest fraud automatically and judge the rest yourself before shipping.
• Three minFraud service tiers — Score, Insights or Factors, selected and changeable from the admin configuration screen.
• IP velocity protection — Blocks IP addresses that generate repeated declined orders within a configurable time window, and destroys the session, stopping card-testing runs.
• Google Storebot handling — If enabled, automatically recognizes and bypasses Google Shopping's checkout verification tests, which would otherwise consume queries and eventually trip velocity protection.
• Screening statistics — Today, Yesterday and All-Time figures showing what was screened, what it cost, and what caching and whitelisting saved.
• Query caching — Avoids duplicate minFraud charges when the same customer retries checkout with identical data.
• CDN / proxy detection — Identifies the real client IP behind CloudFlare, Akamai, Nginx reverse proxies, and other CDN/proxy setups.
• IP whitelisting — Bypass screening for trusted IPs (office, warehouse, partners).
• Email notifications — Detailed HTML emailed reports for screened orders, declines, velocity blocks, whitelisted bypasses, Storebot activity, and processing errors.
• Daily log rotation — Date-stamped log files with configurable retention and a built-in admin log viewer.
• Two installable variants — A System Extension version that runs on the OUSL page, and a Component version that can be placed on any page template, useful for customized and/or one-page checkouts.

2. Requirements

3. Installation

The module is distributed as a compiled Miva module file (.mvc) in two variants. You install them through your Miva Merchant admin. If you already have a previous version installed, follow the upgrade instructions below, which preserve your configuration settings. To find out which variant — System Extension or Component — you are currently running, check the title box on the admin configuration screen.

Choosing a variant

Both variants run the same screening and share the same configuration screen, tables, order fields and email notifications. They differ only in how screening is triggered.

Before you install

You need a WolfPaw module registration code — tied to your Miva Domain License number, shown under Settings › Domain Settings › Information on the License # line — and a MaxMind account with an Account ID and license key. Install one variant; the steps differ slightly.

Installing the System Extension

1. Unzip the module package and locate wp_antifraudv10903_module.mvc, and note where you saved it on your PC.
2. In the Miva admin, go to Settings › Domain Settings and open the Modules tab.
3. Click Add Module, then Choose File and navigate to where you saved wp_antifraudv10903_module.mvc. Select the file, then click Open and Upload.
4. Click Add to register the module, then Update and wait for the confirmation message.
5. Go to Settings › Modules, find WolfPaw's Fraud Screening and Detection, and click Install.
6. The configuration screen appears. Continue to Section 6 below to enter your credentials and settings.

No template changes are needed — the System Extension runs automatically at the beginning of the checkout (OUSL) page.

Installing the Component

Use this variant for custom or one-page checkouts where the System Extension doesn't fire.

1. Unzip the package and locate wp_antifraudv10903_component.mvc, and note where you saved it on your PC.
2. In the Miva admin, go to Settings › Domain Settings and open the Modules tab.
3. Click Add Module, then Choose File and navigate to where you saved wp_antifraudv10903_component.mvc. Select the file, then click Open and Upload.
4. Click Add to register the module, then Update and wait for the confirmation message.
5. Go to Settings › Modules, find WolfPaw's Fraud Screening and Detection, and click Install. The configuration screen appears.
6. Go to User Interface › Templates › Pages and open OSEL Checkout: Shipping/Payment Selection (or your custom checkout page).
7. Add this line at the top of the template, then click Update:

   <mvt:item name="wp_antifraud" param="fraud_check" />

8. Click Items, find wp_antifraud in the list, and switch it On (it turns green).

Screening now runs wherever that item renders. Continue to Section 6.

[ Screenshot: configuration screen — full card view ]images/config-overview.png

Upgrading from an earlier version

1. Record your current settings first — a screenshot of the configuration screen is enough. Settings carry forward automatically, but keep a copy regardless.
2. Identify your current variant: go to Settings › Domain Settings › Modules, click the antifraud module, then Information. If Module Features lists component, you have the Component; otherwise the System Extension. Upgrade to the matching variant.
3. With the module selected, click Information, uncheck Active, and click Update.
4. Click Files › Upload. Check Overwrite, click Choose File and navigate to the new v10.903 file that matches your variant, then click Open, Upload, and Update.
5. Click Information, check Active, and click Update again.
6. Your new version is now installed. Go to Payment Settings, verify your settings migrated correctly, and review Section 6 below for any new settings.

During the upgrade, database changes are applied automatically (including the cache, velocity, Storebot and statistics tables), your existing configuration is preserved, your current decline and processing-error screen messages are kept (the new HTML defaults are optional), separate IPv4/IPv6 whitelist fields are merged into one CIDR field, and screening statistics are carried across.

Verifying the installation

Open the configuration screen and look at the Module Information card. It shows the installed version — WP_ANTIFRAUD v10.903 - Component Version or WP_ANTIFRAUD v10.903 - System Extension Module Version. This is the quickest way to confirm which variant and version are live.

Database tables

The module creates five tables (prefixed with your store table prefix). You never need to edit them directly; they are listed here for reference.

The two MaxMind results are stored as Order custom fields using Miva's native Custom Fields tables (CFM_Groups, CFM_OrderFields, CFM_OrderValues). The module only reads and writes those tables — it never creates or alters them.

4. Quick Start

After installing the module, follow these steps to configure and start screening orders.

1. Create a MaxMind account — Go to maxmind.com and sign up for a MaxMind minFraud account or free trial. New accounts qualify for a free trial with 1,000 risk score queries.
2. Get your credentials — Locate your MaxMind Account ID on the dashboard under Account › Account Information. Generate a License Key under Account › Manage License Keys.
3. Enter your credentials — In the module's configuration screen, enter your MaxMind Account ID and License Key in the MaxMind Configuration card.
4. Test the connection — Click Test Connection to confirm your credentials. A successful test shows a result panel with your account details and remaining balance.
5. Choose your service tier — Still in the MaxMind Configuration card, select the minFraud service. Choose Risk Score Only if the module will decide everything. Choose Insights or Factors if you intend to review orders yourself, because Score returns a number and nothing to read. You can change this at any time.
6. Install the order fields — Confirm the Custom Fields in Orders Table for MaxMind Results control (bottom of the MaxMind card) shows Currently Installed. These are created automatically on install; if it shows Not Installed, type install to create them.
7. Enable query caching — Open the Query Caching card and enable it. This saves money by reusing results when customers retry with identical contact and address data.
8. Check email notifications — Open the Email Notifications card and verify the From and To addresses. Make sure the To address is a mailbox you monitor.
9. Configure proxy/CDN detection — Open the Cart Behind Proxy / CDN card. It displays your 1st Hop IP and Derived Browser IP. If these differ, set Cart Is Behind a Proxy or CDN to on.
10. Whitelist your office IP — Open the Whitelisting card and add your office IP so staff and test orders don't consume queries or trigger IP velocity protection.
11. Enable Google Storebot (if applicable) — If you list products on Google Shopping or Merchant Center, turn on Automatically Whitelist Google Storebot in the same card.
12. Verify logging is enabled — Open the Logging card and make sure logging is on. Logs are invaluable for understanding how the module processes orders.
13. Set risk thresholds — Open the Risk Thresholds card. Set the Email Notification Threshold to 0 so you receive an email on every screened order, and the Decline Threshold to 100 so no orders are declined initially. Section 5 covers where to take it from there.
14. Configure error handling — Open the On Processing Error card. Make sure the disposition is set to Accept Order and the error notification is on.
15. Enable screening — In the Fraud Screening Status card, set Enable Fraud Screening to on and save. Your store is now screening orders.

What to expect

You will receive a merchant notification email on every order (unless the result is served from cache) showing the MaxMind-calculated risk score and whether the order was accepted or declined. Since the decline threshold is at 100, all orders will be accepted and every email will read "Order Accepted."

Familiarize yourself with the typical risk score for your customer base. This gives you an idea of where your decline threshold should end up. We've found most legitimate orders score under 3% to 5% — but, as they say, your mileage may vary depending on your industry, customer demographics, and geographic distribution.

5. Choosing Your Approach

You can let the module decide every order from the decline threshold, or review orders yourself before shipping. Which approach you take decides where that threshold belongs, and which minFraud service you need.

If the module decides everything

Set a decline threshold and leave it. Orders scoring at or above the threshold are stopped at checkout, before payment is processed. Nothing is held for review.

This takes no ongoing effort, and no money ever changes hands on a blocked order. A declined customer does see your decline message, which can invite them to check their billing details and try again or to call you — so the sale is not necessarily lost. But you never see the order yourself, and never get the chance to judge a borderline case that the threshold decided against.

Lower the decline threshold gradually to a value above your normal range. A common progression is:

100 (monitor only)  ->  50  ->  30  ->  15  ->  fine-tune from there

Because nothing is reviewed, the threshold is the only thing standing between a bad order and your warehouse — which is why it ends up close to your normal scores.

If you review orders manually before shipment

If you are accustomed to reviewing orders before they ship, and would rather the module declined only the most egregious and obvious fraud, set the Decline Threshold to around 75 and review everything below it yourself using the two MaxMind order fields described in Section 7.

You can afford the higher figure precisely because the orders that would have been false positives are now looked at rather than refused. This is the approach many merchants arrive at once they have watched real scores for a few weeks — it blocks what is obviously fraudulent without anybody looking at it, and puts a human judgement on the genuinely ambiguous middle, which is where almost all false positives live.

Which service you need

Manual review needs Insights or Factors. A Score query returns a number and nothing else, so reviewing an order would mean judging it on the same figure the threshold already acted on. Insights returns the detail you actually read — and costs one cent more per order. Factors adds the specific reasons behind each score. The tier is a setting in the module's admin configuration screen, not a different plan, so you can change it whenever you like.

6. Configuration

The module's configuration screen is organized into cards, documented below in the order they appear. Changes are saved with the Update button.

Card 1 — Module Information

Displays the installed module version, developer information, module description, and documentation links. No configuration needed. Use this to verify the correct variant and version are deployed.

Card 2 — Screening Statistics

A collapsible panel showing what the module has done, in three columns: Today, Yesterday and All Time. Click to expand it.

The gap between total screenings and queries consumed is what caching, whitelisting and velocity protection are saving you.

Preserve statistics on uninstall (checkbox, on by default) keeps the counters if the module is uninstalled or the variant is switched. Reset Statistics starts a new counting period — useful at the start of a quarter, or after changing your thresholds. Resetting clears counters only; orders, order fields and the daily log are untouched, and the action requires a second click to confirm.

[ Screenshot: Screening Statistics card (expanded) ]images/card02-stats.png

Card 3 — Fraud Screening Status

The master switch.

The card header shows the current state unmistakably — a green Enabled or a red Disabled — so a store that is not actually screening is easy to spot at a glance.

Card 4 — WolfPaw License

Card 5 — MaxMind Configuration

There is no subscription or plan to choose. minFraud queries are pay-as-you-go — you buy service credit, and the service selected here determines what each query returns and what it costs. You can change it at any time; the change takes effect on the next order.

Use the Test Connection button (see Section 8) to verify your credentials before enabling screening. * Query prices as of October 2026.

Custom Fields in Orders Table for MaxMind Results

At the bottom of this card is the control that installs or removes the two MaxMind order fields (MM Risk Score and MM Technical Response). It shows the current state — Currently Installed or Not Installed — derived by checking whether the fields exist, so it stays correct even if the fields are changed directly in Miva.

• When installed, type remove in the confirm box and Update to delete the two fields and their recorded values. The Additional Order Information group is left in place. This removes the MM Risk Score and MM Technical Response for every order — on the Orders page and in the order history — and cannot be undone.
• When not installed, type install and Update to create (or repair) the two fields.

The fields are created automatically on install and upgrade, so most stores never need this control — it exists so you can remove the fields cleanly (in case of conflicts with certain shipping or order integrations), or reinstall them if they were deleted. See Section 7.

[ Screenshot: MaxMind Configuration card ]images/card05-maxmind.png

Card 6 — IP Velocity Protection

Tracks how many times a given IP address is declined. After exceeding the threshold within the configured time window, the IP is temporarily blocked from placing orders — no minFraud query is consumed during the block period. This is what stops card-testing runs.

Only declined attempts count. A customer who orders repeatedly and passes screening each time is never blocked.

When an address reaches the attempt limit, the module also deactivates the basket session used for those attempts, so an attacker cannot continue with the same cart after clearing cookies. Adding an address to the whitelist clears any velocity block on it. Use View / Clear Velocity Table (Section 8) to inspect or reset the tracking data.

[ Screenshot: IP Velocity Protection card ]images/card06-velocity.png

Card 7 — Query Caching

When enabled, the module caches the risk-score result for each unique combination of customer and device identity data. If the same customer retries checkout with the same identity and device, the cached result is returned without consuming another minFraud query credit. Trivial differences such as capitalization or phone number formatting do not defeat it.

A cache entry applies only to the cart information it was created for, with the exception of order amounts and contents, so a customer's second, separate order (a new basket) is always screened afresh. If the customer materially changes their address, the cache does not apply and a new query is made — which is correct, because it is a different transaction to assess.

Automatic cache purge: when the IP whitelist is changed, cached whitelist entries are purged. When the decline or email threshold is changed, the query cache is also purged. This ensures cached decisions always reflect current settings.

Card 8 — Email Notifications

Card 9 — Cart Behind Proxy / CDN

If your store is behind a CDN (CloudFlare, AWS CloudFront) or a reverse proxy (Nginx, Varnish), the client's real IP may be in a forwarded header. Enable this setting so the module reads the correct IP from CF-Connecting-IP, True-Client-IP, X-Real-IP, or X-Forwarded-For headers.

The card displays a Current IP Detection Results box with your 1st Hop IP and Derived Browser IP. If these differ, your store is behind something and this setting should be on. If the module reports a private address such as 10.0.0.5 or 192.168.1.20 as the customer's IP, you will receive a processing error notification naming the cause.

[ Screenshot: Cart Behind Proxy / CDN card ]images/card09-proxy.png

Card 10 — Whitelisting & Google Storebot

Whitelisted IPs bypass fraud screening entirely. No minFraud query is consumed.

203.0.113.9
198.51.100.0/24
2001:db8::/32

Google Storebot

If you list products on Google Shopping or Google Merchant Center, Google runs periodic automated checkout verification tests against your store. These are not real orders and not fraud attempts — but they look like repeated automated checkouts, so without special handling they consume MaxMind queries, and repeated declines can accumulate in the velocity table until Google is blocked outright. Your Shopping listings would then fail verification, with nothing in the admin explaining why.

With Automatically Whitelist Google Storebot on, requests are identified by user agent and then confirmed by address — the user agent is only a gate, so every request is confirmed independently before it is trusted.

When enabled, the module sends at most two Storebot emails per active day: an alert when verified Storebot activity first begins that day, and a summary the following morning showing the day's total checkout tests, the number of unique addresses, and how each was confirmed.

Card 11 — Logging

Logs are written to the wp-antifraud.logs/ directory, one file per day named antifraud-YYYY-MM-DD.log. The card includes a built-in Log Files viewer so you can read a day's log without leaving the admin. Log entries are prefixed with basket and pending-order identifiers, so all lines for one transaction can be traced together. When contacting support about a specific order, those identifiers from the alert email are the quickest way to locate it.

[ Screenshot: Logging card + Log Files viewer ]images/card11-logging.png

Card 12 — Risk Thresholds

The risk score is a probability, not a verdict. A score of 10 means MaxMind estimates roughly a 10% chance the transaction is fraudulent — so about one order in ten at that score genuinely is. There is no score at which fraud is impossible, and no threshold that blocks all fraud without also blocking legitimate customers. Section 5 covers where to set it.

Because declines can sometimes be legitimate customers rather than fraudsters, the wording of the decline message matters: a message that invites them to check their billing details and try again recovers sales that a blunt refusal loses. Include a phone number or email address so they can reach you.

[ Screenshot: Risk Thresholds card ]images/card12-thresholds.png

Card 13 — On Processing Error

Controls what happens when MaxMind is unreachable, returns an error, or the module encounters an unexpected problem during screening.

Leave notification enabled with either choice. A silent screening failure is far worse than the failure itself — without an alert, you could go weeks unscreened without knowing.

7. Reviewing Orders

The module writes the MaxMind result to two Order custom fields, shown on your Miva admin's Orders page and in the Additional Order Information section on the order detail page. If these fields do not appear, you may need to enable them: on the Order Processing › Orders page, click the plus (+) at the right of the column headers, scroll down to Show/Hide Columns, and click Show/Hide Custom Fields. Make sure MM Risk Score and MM Technical Response are checked.

Fields display alphabetically by field code within the group, so MM Risk Score appears above MM Technical Response. You can add MM Risk Score as a column on your order list from Miva's order-list column controls, so you can scan scores across many orders at once.

[ Screenshot: MM Risk Score + MM Technical Response columns on the Orders list ]images/order-list.png

[ Screenshot: MM Risk Score + MM Technical Response on an order ]images/order-custom-fields.png

Reading the technical response

With the Insights or Factors service tier, the technical response is a flat, readable record — no raw JSON. It begins with the MaxMind transaction ID and a direct link to that transaction in your MaxMind dashboard, followed by the risk score and the sections MaxMind returned (IP address and traits, email, billing and shipping address checks, phone). With the Risk Score Only tier, the technical response shows the score and little else. These are some of the risk indicators merchants find most useful when deciding whether to ship an order:

For the non-screened outcomes, the technical response is a short two-line label: Whitelisted, Google Storebot, Velocity Block, a Cached prefix on a replayed result, or Error with the cause — each followed by the relevant IP address.

The Custom Fields toggle

The two custom order fields — MM Risk Score and MM Technical Response — are created automatically on install and upgrade. The control at the bottom of the MaxMind Configuration card (Section 6, Card 5) lets you remove them — values and definitions — or reinstall them, by typing remove or install to confirm. Removing them leaves the Additional Order Information group in place; reinstalling recreates the fields empty. But be careful — removing the custom fields deletes the entire risk score and MaxMind response history for your orders, and it cannot be undone.

A note for integrations

The two custom order fields are standard Miva Order custom fields. A system that reads orders through Miva's order API or templates will see them alongside any other custom fields that exist. If an integration cannot tolerate additional order custom fields, use the toggle above to remove them — screening continues to run and to log and email MaxMind results; only the on-order record is omitted.

8. Admin Tools

The configuration screen includes interactive tools in addition to the configuration cards.

Test Connection

Verifies that your MaxMind Account ID and License Key are valid. The module sends a test query to the minFraud API and displays the response, along with your remaining account balance. A successful test shows a green result panel; a failure shows red with the error message. A failure here is almost always one of: a mistyped license key, a key generated for a different MaxMind service, or outbound HTTPS blocked by a firewall. (The test always uses a Score query, whatever tier you have selected.)

View / Clear Velocity Table

• View — Displays current tracking data with IP address, decline count, window start time, and blocked status.
• Clear — Clears all velocity tracking data. Requires confirmation. Useful after testing, or when you have blocked yourself.

Log Files viewer

View a day's log file directly in the admin panel (Logging card). Logs are stored in wp-antifraud.logs/ and rotate daily.

Reset Statistics

Clears the screening counters and starts a new counting period. Requires a second click to confirm. Orders, order fields and the daily log are not affected.

9. How Screening Works

Screening runs at checkout — on the order checkout screen (OUSL) for the System Extension variant, or wherever the Fraud Check component item renders for the Component variant. The flow is the same for both:

1. Trigger — The customer reaches checkout and screening begins.
2. Enabled check — If fraud screening is disabled, the module exits immediately.
3. Basket & data guard — Empty or expired baskets are skipped. If essential data is missing (IP, email, billing postal or country), the order is handled as a processing error under your error policy rather than sent to MaxMind.
4. Whitelist check — If the client IP is whitelisted, the order is allowed through and any velocity block on that address is cleared. No query is made.
5. Google Storebot check — If enabled and the request is confirmed as Google's verification crawler, the order is allowed through without a query. This runs before velocity so Google's own testing cannot trip the block.
6. Velocity check — If the IP is currently velocity-blocked, the order is declined without consuming a query, and the checkout session is cleared.
7. Cache check — If caching is enabled and a cached result exists for this cart, the cached decision is used — no query.
8. minFraud query — The module sends order data (IP, email, billing and shipping address and names, phone, order amount, currency, browser, and a hashed session identifier) to MaxMind.
9. Risk evaluation — The returned risk score is compared against your thresholds. If it meets or exceeds the decline threshold, the order is declined.
10. Velocity update — If declined and velocity protection is enabled, the IP's decline counter is incremented.
11. Result recorded — Checkout proceeds (accepted) or shows the decline message (declined). The result is written to the two order fields, an email is sent per your notification threshold, and the outcome is logged.

10. Email Notifications Reference

The module sends up to seven types of email notification. Each is a detailed HTML report with color-coded severity for instant inbox identification.

Fraud report emails include customer name, email, billing and shipping addresses, IP address, risk score, order total and currency, the MaxMind response detail (which varies by service tier), and the screening decision. The subject on a fraud report shows the risk percentage and whether the order was accepted or declined, so you can triage from the inbox.

[ Screenshot: fraud notification email ]images/email-fraud-alert.png

11. Troubleshooting

12. Uninstallation

To stop screening without removing the module, set Enable Fraud Screening to off in Card 3. To remove the module entirely, uninstall it from the Miva admin module manager. For the Component variant, also remove the Fraud Check item from your template.

Uninstalling leaves your order data intact: the two MaxMind order fields and their recorded values remain on your orders, and your screening statistics are preserved when Preserve statistics on uninstall is on (the default).

13. Support and Contact

When contacting support, please include your Miva Merchant version, which variant and module version are shown on the Module Information card, your Miva Domain License number, and any relevant lines from the daily log — from the module's built-in log viewer or the wp-antifraud.logs/ directory. The basket and order identifiers from an alert email are the quickest way for us to locate a specific transaction.

14. Tips and Best Practices

Getting started

• Start conservative: email threshold 0, decline threshold 100. Review the reports for a week or two before enabling automatic declining.
• Enable logging from day one. The log is invaluable for understanding how the module processes orders and diagnosing issues.
• Enable IP velocity protection. The defaults — 5 attempts, 10-minute window, 60-minute block — catch card-testing bots without being overly aggressive. Remember it needs your decline threshold to be declining something.
• Turn on query caching with a 10–15 minute TTL to reduce MaxMind costs right away.
• Include contact details in your decline message so legitimate customers who are incorrectly declined can reach you.
• Whitelist your office so staff and test orders don't consume query credits.

Understanding risk scores

The minFraud risk score is a percentage from 0.01 to 99 representing the probability that a transaction is fraudulent. A score of 5.00 means roughly a 5% chance the order is fraudulent.

• Most legitimate orders score under 3% to 5%.
• MaxMind recommends analyzing your own transaction data to determine the right threshold, as score distributions vary across industries and regions.
• The more data sent to minFraud, the more accurate the score. The module sends everything available.
• Watch the logs for patterns. If scores between 10–30% are consistently legitimate, your decline threshold should be above that range.

Recommended starting thresholds

Margins and risk tolerance

Your ideal decline threshold depends heavily on your gross profit margin. The fundamental question is: does the cost of a fraudulent chargeback outweigh the cost of a lost sale?

• Low-margin merchants (electronics, commodities) — A single chargeback can wipe out the profit from many legitimate orders. A lower decline threshold (5–10) reduces fraud losses even at the cost of occasionally declining a legitimate customer.
• High-margin merchants (digital goods, SaaS, custom products) — The profit on each sale can absorb occasional fraud losses. A higher decline threshold (20–50) captures more revenue while still blocking obvious fraud.
• Mixed catalogs — Consider whether high-value physical items deserve tighter scrutiny than low-value or digital items.

As a rule of thumb: the lower your margin, the lower your decline threshold should be — unless you review orders manually, in which case you can set it higher and judge the middle ground yourself.

Velocity protection recommendations

• Start with defaults: 5 attempts, 10-minute window, 60-minute block.
• For high-value stores: consider 3 attempts in 10 minutes with a longer block (120–240 minutes).
• For high-volume stores: increase max attempts to 8–10 to avoid false positives from shared corporate IPs or university networks.
• Monitor the velocity table periodically to verify you're catching real attacks, not creating false positives.

Country blocking

You can block orders from specific countries through your MaxMind account — this is done on MaxMind's side, not in the module:

1. Log in to your MaxMind account at maxmind.com.
2. Go to minFraud › Country Block List.
3. Change any country to "Block" to automatically assign a 100% risk score to orders originating from that country. The module will then decline them if your decline threshold is set below 100.

15. Version History

Version 10.903 — October 2026

• Screening Statistics. Cache-hit results are now included in the Risk Accepted and Risk Declined counts on the statistics panel.
• Custom Fields removal. Removing the MaxMind order fields now uses a two-step confirmation — type remove, then confirm — to guard against accidental deletion of recorded order history.

Version 10.902 — October 2026

• MaxMind results on the order. Risk score and a plain-text technical response written to two Order custom fields, with an admin control to install or remove them.
• Google Storebot verification with forward-confirmed reverse DNS, published-range caching (IPv4 and IPv6), and two-per-day notifications.
• Screening Statistics card with Today / Yesterday / All Time figures and a reset that starts a new counting period.
• Richer MaxMind data — billing street, billing and shipping names, and shipping phone sent when present; session identifier hashed before transmission.
• Green/red Fraud Screening Status indicator, email-send logging on success, and various fixes.

Version 10.803 — earlier

• Google Storebot auto-whitelist, Storebot email notifications, Screening Statistics dashboard, statistics preservation, and OpenSSL 3.0 compatibility.

Version 10.712 — earlier

• IP velocity protection, session invalidation on block, daily log files with a built-in viewer, UTC timestamps, and the empty-basket guard.

Version 10.512 — earlier

• Card-based admin redesign, professional HTML emails, structured logging, CIDR whitelisting with unified IPv4/IPv6 handling, enhanced IP detection (CloudFlare, Akamai, Nginx), and the MaxMind connection test.

Version 10.401 — earlier

• minFraud query caching with a merchant-selectable pruning TTL.

Version 10.301 — earlier

• IPv6 whitelisting and analysis, and support for minFraud's Score / Insights / Factors service tiers.

Copyright © WolfPaw Hosting and Development LLC. All rights reserved.
Real-Time Fraud Detection and Blocking is proprietary software. Unauthorized distribution is prohibited.