Customer Extra Info and IP Bans: Protecting Your Store from Problem Visitors

Most of your visitors are exactly who they appear to be. But every store eventually meets the exception: the "customer" who places ten orders and never pays, the one who disputes a charge with their bank after the parcel arrives, the person who registers under a new throwaway email every time their last account got cancelled, the competitor quietly logging in from the same office to watch your prices. PrestaShop's back office shows you almost none of this. You see an order, a name, an email — and nothing about the machine, the network, or the history behind it. This guide is about closing that blind spot two ways: collecting enough extra information about who is visiting to recognise a problem visitor, and having an IP ban ready so that when you do recognise one, you can shut the door without a developer and without taking your whole store offline.

Last updated: June 2026.

What PrestaShop tells you about a visitor — and what it hides

Out of the box, PrestaShop stores a customer's name, email, optional date of birth, and the addresses they enter at checkout. It logs connections in the Stats → Visitors online and the connections table, and it records an IP against guest sessions. What it does not do is join those dots for you. There is no screen that says "this account has logged in from six different IPs in three countries this week," or "these four accounts all share one IP and one browser fingerprint." The raw data exists in fragments; the pattern that would let you spot fraud early does not surface anywhere you'd actually look.

That gap matters because abuse is almost always a pattern, not a single event. One returned item is a customer. Twenty returns from accounts that all trace back to one IP is a problem you want to see on day three, not after the third chargeback letter from your acquirer. The first job, then, is visibility — enriching what you know about each visitor so the pattern is legible.

The "extra info" that actually flags a problem visitor

"Customer extra info" doesn't have to mean a longer registration form (longer forms convert worse — that's a real cost). The information that catches abusers is the technical metadata the request already carries, which you simply aren't recording. Our Customer Extra Info & IP Ban module collects it passively, per visit, and attaches it to the customer record so you can read it from the customer's admin page:

• IP address and country — the real one, not your proxy's. Behind Cloudflare or a load balancer, PrestaShop's naive lookup often logs the CDN's IP. The module reads CF-Connecting-IP, X-Real-IP and X-Forwarded-For (validating each) so the address you ban is the visitor's, not your edge.
• Country — derived from Cloudflare's CF-IPCOUNTRY header when present, or PrestaShop's GeoIP database as a fallback. A sudden run of registrations from a country you don't ship to is a signal in itself.
• Browser, OS and device type — parsed from the user agent. Five "different customers" all on the same unusual browser build is not five customers.
• Unique IPs per customer, with first-seen / last-seen and a visit count — this is the multi-account fraud detector. One account hopping across a dozen IPs, or one IP wearing a dozen account names, both jump out of this view.

The collection is deliberately quiet: it de-duplicates so it only writes one record per IP-plus-customer per hour rather than hammering your database on every page load, and each data point (user agent, OS, browser, screen resolution) is an independent on/off toggle so you collect exactly what you need and nothing you'd rather not store. So what does that buy you? When a dispute lands, you open the customer's profile and see their whole footprint — every IP, every country, every session — instead of guessing. That's the difference between acting on evidence and reacting in a panic.

The customer list shows each customer with their name, email, status and registration and last-visit dates.

If you need to audit the raw footprint during an investigation, the module stores it in ps_mprceiipban_info. Replace the prefix if your shop does not use ps_:

SELECT id_customer, ip_address, country_code, browser_name, device_type, date_add
FROM ps_mprceiipban_info
WHERE id_customer = 123
ORDER BY date_add DESC
LIMIT 50;

IP banning in PrestaShop: more precise than "block the address"

PrestaShop's core has no real visitor-banning tool — the maintenance-mode IP allowlist under Shop Parameters → General → Maintenance locks out everyone except the listed IPs, which is the opposite of what you want for one bad actor. So banning is exactly the kind of capability a module adds. The naive version of an IP ban — one address, blocked everywhere — is also the least useful, because it's both too blunt and too easy to dodge. A ban that actually earns its place gives you control over which address, where it bites, and for how long.

Match more than a single address

Bad actors rarely sit on one static IP. The module matches a ban against:

• An exact IP — the simple case.
• A wildcard like 203.0.113.* — when someone keeps returning on adjacent addresses in the same block.
• A CIDR range like 203.0.113.0/24 — the precise way to cover a whole subnet.
• An address range like 203.0.113.10-203.0.113.40 — for an arbitrary span.
• A country code — block an entire origin you don't serve, evaluated against the GeoIP country above.
• A user-agent pattern — plain-text contains-match or a full regex, for an abuser identifiable by their client string rather than their address.

Choose where the ban applies

This is the part that turns a sledgehammer into a scalpel. Each ban carries a scope:

That separation matters because of the dynamic-IP and shared-IP reality: offices, universities and mobile carriers put many real people behind one public address. A full ban on a shared IP can quietly cost you genuine orders. A narrow checkout or auth ban contains the damage to exactly the action being abused. And because the visitor's real IP is resolved correctly behind your CDN, you're banning the person, not a coincidental neighbour.

Set a ban to expire — and never lock yourself out

Two more controls keep bans from becoming their own problem. Every ban can be temporary, with an expiry timestamp after which it's automatically deactivated — useful for a cooling-off block where a permanent ban would be overkill, and tidy for data retention (more on the GDPR angle below). And a whitelist always wins: any IP or CIDR you list there can never be banned, including by an automatic rule. Put your own office, your developer's connection, and your monitoring services on it first, so a broad ban you set in anger at 2am can't accidentally shut you out.

Each ban row shows its scope, IP address and active status side by side.

Trusted addresses sit in the whitelist while flagged orders show a risk score and reason.

Stopping the automated abuse before it needs a ban

A lot of "problem visitor" traffic is a script, not a person — and the cleanest defence is to make the attack expensive automatically. The module tracks failed login attempts per IP and can auto-ban an address that crosses a threshold you set (so many failures inside a time window), with a temporary auth-scope block rather than a permanent one. That's a targeted answer to credential stuffing: the brute-forcer gets locked out of login for an hour after, say, ten misses, while a customer who fat-fingered their password twice is untouched.

Auto-banning on login failures is one layer. The broader job of separating good bots from bad — scrapers, vulnerability scanners, ad-fraud clicks — is its own discipline; we cover it in Visitor Control: blocking bad bots and unwanted traffic. And the single highest-value step for stopping fake registrations and form spam at the source is a challenge on the form itself — see reCAPTCHA for PrestaShop. Where a bad actor is hammering your faceted-search URLs into a denial-of-service, the front line is your CDN, not a PrestaShop ban list: surviving the ?q= flood.

Where IP banning fits in your wider hardening

Be honest with yourself about what an IP ban can and can't do. It is excellent against the casual and the careless — the majority of abusers, who aren't sophisticated enough to bother with a VPN. It is not a perimeter against a determined attacker, who can change addresses faster than you can ban them. Treat it as one well-aimed tool, not your security strategy. The strategy lives in the cluster:

• The full sweep — file permissions, the admin folder, headers, updates — is in the PrestaShop security hardening checklist, with a gentler walk-through in the plain-English guide for store owners.
• Locking down the back office itself — admin accounts are the real prize for an attacker — is covered in two-factor auth, password policies and admin security.
• If you're stuck on a version you can't upgrade, advanced hardening with virtual patching is the realistic path.
• And if the worst has already happened, don't improvise — follow data breach response: what to do if your store gets hacked.

The legal and record-keeping side

Banning a customer in the EU is your right — you can refuse service — but the data you keep to justify it lives under GDPR. Two practical consequences. First, collect proportionately: that's why each metadata field in the module is an individual toggle and why old records can be purged on a schedule, so you're not hoarding device fingerprints you never use. Second, keep a clear reason on every ban (the module stores a reason and the employee who set it) so that if a banned customer escalates to their bank or a consumer authority, you can show why the restriction was applied, not just that it was. If that customer later files an Article 17 erasure request, you generally comply — though you may retain what's genuinely necessary for legal claims or compliance. Your terms and conditions should already spell out that accounts can be terminated for policy violations; that's the clause that gives a ban its footing.

Frequently asked questions

Will an IP ban accidentally block real customers behind Cloudflare?

It will if you ban the wrong address — which is exactly the trap behind a CDN. PrestaShop's naive IP lookup often records Cloudflare's or your load balancer's IP rather than the visitor's, so a "ban" can land on your own edge and lock out everyone. The module reads CF-Connecting-IP, X-Real-IP and X-Forwarded-For (validating each) so the address you ban is the actual visitor's, not your CDN's. Resolve the real IP first; only then is a ban safe.

Why would I use a "checkout" or "auth" ban instead of a full block?

Because offices, universities and mobile carriers put many real people behind one public IP, so a full ban on a shared address can quietly cost you genuine orders. A checkout-scope ban lets a serial non-payer browse but not place orders; an auth-scope ban stops fake-account creation and credential stuffing from a source without blocking legitimate guests on that same IP. Match the scope to the action being abused — full blocks are for outright abuse you want gone completely.

How do I stop credential-stuffing scripts without banning real customers who mistype?

Use the failed-login auto-ban with a sensible threshold. The module counts failed login attempts per IP and can auto-apply a temporary auth-scope block once an address crosses, say, ten misses inside a time window — so the brute-forcer is locked out of login for an hour while a customer who fat-fingered their password twice is untouched. It's a targeted answer to scripts, not a blanket hammer. Form spam and fake registrations are better stopped at the form with reCAPTCHA.

How do I avoid locking myself out with a broad ban?

Build the whitelist first. A whitelist always wins — any IP or CIDR you list there can never be banned, including by an automatic rule — so add your own office, your developer's connection and your monitoring services before you create any broad country or CIDR ban. That way a wide ban you set in anger at 2am can't accidentally shut you out. Pair it with temporary bans (an expiry timestamp auto-deactivates them) for cooling-off blocks where a permanent ban would be overkill.

Is banning a customer and storing their IPs a GDPR problem?

Refusing service is your right, but the data you keep to justify it lives under GDPR, so collect proportionately. Each metadata field is an individual toggle and old records can be purged on a schedule, so you're not hoarding device fingerprints you never use. Keep a clear reason on every ban (the module stores the reason and the employee who set it) so you can show why a restriction was applied if a customer escalates to their bank or a consumer authority. Honour Article 17 erasure requests, retaining only what's genuinely necessary for legal claims — and make sure your terms spell out that accounts can be terminated for policy violations.

A balanced door, not a fortress

The point of all this isn't to greet shoppers with suspicion — it's to run a friendly store that quietly keeps receipts. Most stores rarely need to ban anyone. But the time to build the capability is before you need it, not during the crisis when a fraud ring is mid-spree and you're learning the back office under pressure. Turn on visitor metadata collection so the patterns are visible. Whitelist your own connections first. Keep scoped, expiring IP bans as a tool you can reach for in seconds — a checkout block on the non-payer, an auth block on the account-farmer, a full block on the genuinely abusive — and let the auto-ban handle the brute-force scripts on its own. That's what Customer Extra Info & IP Ban is built to give you: the visibility to recognise a problem visitor, and a precise, reversible way to stop them — all from your back office, no developer required.