Checkout fraud

Stop card testing before it reaches your payment processor

Card testing shows up as many small checkout attempts and payment failures from networks real shoppers rarely use. FindIP Shield records checkout views, payment attempts and payment failures with the network signals behind each one, lets you add friction on the checkout form, and gives your server a check to run before capture. Start by monitoring; the payment decision stays with you and your processor.

Free Preview · 10,000 events per site per day · No credit card · Terms apply

Hosting / datacenter Proxy Tor Malicious IP Payment failures by network IP rotation in session
The problem

Your processor sees the card. It does not see the connection.

A card-testing run is dozens of small checkouts in minutes, most of them failing, from hosting providers and proxy networks. Each one looks like a single shopper to your checkout page. The chargebacks and the processor warnings arrive later.

Fraud tools that score the transaction need the order. By then the attempt has already consumed a payment authorisation. Network context is available earlier: at checkout_view, at payment_attempt, at payment_failed.

Shield puts that context on the checkout flow itself, without ever seeing card data, cart contents or customer fields, and leaves the authoritative decision where it belongs: on your server, with your processor's own tools.

One event, explained

What one of these looks like in Shield

Every visit and form submit is recorded with a score, the reasons behind it, the session around it, and what the page did. A hosting network or a VPN is used legitimately every day; the reasons are there so you can judge, not a verdict on a person.

A recorded eventSample data

payment_failed

64 · high

/checkout · a moment ago

Why this risk score
  • proxy_detectedThe current IP is a known anonymizing proxy.
  • hosting_networkThe IP belongs to hosting infrastructure rather than a consumer access network.
Session
Network
AS64500 · hosting · United States
Payment attempts in this session
5 in 3 minutes
Payment failures
4
Form
checkout (WooCommerce)
What happened
Shield recommended
challenge
A verdict for your site to use. On its own it stops nothing.
Observed in the page
Slowed
This store slows suspicious checkouts down by a few seconds and asks for a Turnstile check on the highest scores. A fifth attempt never came.
How Shield helps

From the first checkout event to a capture you can stand behind

Shield is a network-signal layer next to your processor's fraud tools, not a replacement for them. Here is how the two fit together.

Start by monitoring

Install the WordPress plugin, the Shopify app, or the snippet on a custom checkout. Checkout views, payment attempts and payment failures arrive with their score and network reasons.

Read the reasons

A card-testing run is many small attempts from hosting and proxy networks, most of them failing. In the session view those failures cluster by network, where a single decline would not.

Add your own context

Match the session with your order records and your processor's decline codes. Shield never sees the card or the cart; you hold the business context, it holds the network context.

Choose a response on the checkout form

On a snippet or WordPress install, slow suspicious checkouts down, ask for a Turnstile check, or stop the highest scores. On Shopify the app reports; the store's own controls respond.

Verify before you capture

Before the payment is captured, verify the session from your server with your secret key. The authoritative decision stays with you and your processor, with the network context attached.

What Shield shows you

The evidence, then the response you choose

Checkout and payment events with network reasons

checkout_view, payment_attempt and payment_failed events carry the risk score and reasons such as hosting_network, proxy_detected or malicious_ip. For WooCommerce, cart, checkout, payment-failure and order-received context comes from the plugin.

Failures clustered by network

Repeated payment failures from the same hosting range or proxy pool stand out in the session view, where a single declined card would not.

Friction on the checkout form, when you choose

On a snippet or WordPress install, give the checkout form a response: slow down, a Turnstile check, or stop for the highest scores. Verify the session server-side before capturing payment.

Setup

Install on your store in three steps

For WooCommerce stores, the WordPress plugin adds cart, checkout, payment-failure and order-received context automatically. Custom checkouts use the snippet; Shopify uses the app, visibility only.

Install the plugin

In WordPress go to Plugins, Add New, search for FindIP Shield and activate it. The plugin loads nothing until a site key is saved.

Paste your site key

Create a Shield site for your domain at findip.net and paste the public site key into the plugin settings. Choose strict, balanced or advanced privacy mode and the consent behaviour you need.

Open the dashboard

Visits, sessions and form activity start arriving. With WooCommerce active you also see cart, checkout, payment-failure and order-received context.

Prefer another route? On Shopify? The FindIP Shield app reports storefront visits and sessions from the App Store, with no theme edits.

On your platform

Install the FindIP Shield plugin from WordPress.org and paste your public site key. With WooCommerce active, cart, checkout, payment-failure and order-received context is added to the events automatically. Responses on the checkout form are set in the Shield dashboard.

WordPress admin → Plugins → Add New → "FindIP Shield" → Activate
Settings → FindIP Shield → Public site key: pub_your_site_key
                         → Privacy mode: balanced · WooCommerce context: on
Open the storefront once; the first checkout_view appears on the Install page.
WooCommerce guide

The app runs as a Web Pixel inside Shopify's sandbox and reports consented storefront visits and sessions with their network signals. It cannot see or act on the checkout form; responses stay with Shopify's own controls and your payment provider.

Shopify App Store → FindIP Shield → Install (two minimal permissions, no theme edits)
In the app: paste the public site key of a Shield site whose domain is your storefront hostname
Accept your own cookie banner, open a product page: the first consented visit is scored.
Shopify guide: exactly what the pixel can and cannot see

The snippet reports checkout_view, payment_attempt and payment_failed with the session. Your server verifies the session before the capture call; the payment provider's own fraud tools keep their job.

// browser: the SDK reports the checkout form automatically; name the outcome yourself
track('payment_failed');            // after a decline from your provider

// server: before capture
const verdict = await verifyShieldSession(sessionId, 'payment_attempt');
if (verdict.decision === 'reject') return holdForReview(order, verdict.reason);
await provider.capture(paymentIntent);
Server verification reference

One POST from your server with the secret key, before the sensitive action. verified tells you the session is real; recommendation is allow, monitor, challenge or block; risk_status unknown means FindIP had no intelligence for that IP, which you treat as monitor, never as safe.

curl -X POST https://shield.findip.net/v1/shield/sessions/verify \
  -H "Authorization: Bearer $FINDIP_SHIELD_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{"session_id": "<from the browser or the findip_session field>", "event": "signup_attempt"}'

# → {"verified": true, "risk_status": "available", "risk_score": 78,
#    "recommendation": "challenge", "challenge_passed": false}
Server verification reference
Boundaries

What a risk score is, and what it is not

An assessment, not proof. A VPN, a hosting network or a changing IP is common for privacy-conscious and corporate users too. Shield explains the reasons so you can decide; it does not pass judgement on a person.
Friction, not a security boundary. Anything decided in the browser can be bypassed by someone who controls it. For decisions that matter, verify the session from your server with your secret key.
Unknown is never safe. Where no intelligence was available the status is unknown. Shield fails open: if a decision does not arrive, the form submits as normal.
Questions

Frequently asked

Never. Card data, payment fields, cart contents, prices, product identifiers and customer fields are not sent. Shield sees the event, the network it came from, and limited session context depending on the privacy mode.

No. Shield does not talk to your payment processor. On a form you configure it can slow down, challenge or stop the submit in the browser; the authoritative decision is yours, made on your server with the verify call before capture, alongside your processor's own fraud tools.

On Shopify the app runs as a Web Pixel inside the Shopify sandbox. It reports consented storefront visits and sessions with network signals; it cannot see or act on the checkout form. See the Shopify page for exactly what it covers.

It is a network-signal layer, not a transaction-scoring product. It tells you where a checkout came from and why that is unusual. Pair it with your processor's fraud tools and your own order context for decisions.

A slow-down is a few seconds and applies only where you set it, on the highest scores; most sessions never see it. Start in monitor only, read which reasons your card-testing runs actually carry, and respond to those. Every outcome is logged next to the recommendation so you can see what the friction did.

Start by watching one real flow.

Create a free Shield site, install it, and look at the first real event before you decide on any response.

Monitor my checkout

Next: create a free Shield site, install the plugin, app or snippet, and see the first real checkout event. Nothing is slowed or stopped until you choose a response.

Free Preview · Monitor first · Stop, slow, challenge, or redirect risky submits when you choose