A reviewer opens your dispute. The cardholder says they never made this purchase. Your evidence includes a line of numbers: 203.0.113.42. The reviewer has seen ten thousand of these. Unless that number is attached to a story, it is just numbers.
Most merchants either ignore the IP address or treat it like a fingerprint. Neither is right. The IP address is one of the cheapest pieces of evidence you already have. It is also one of the easiest to misread, in both directions.
What an IP address actually is
An IP address is the network address your server saw when the customer's device connected. It is not a person, a device, or a street address. It identifies the connection, usually one assigned by an internet provider or a mobile carrier.
That gives it a narrow, specific job. It can tell you roughly where a connection came from, and it can tell you whether two events came from the same connection. Everything useful you can do with it comes from one of those two things.
What it cannot do is prove who was sitting at the keyboard. A reviewer knows that. If your rebuttal claims otherwise, you lose credibility on everything else in the packet.
Why the location claim is weaker than it looks
IP geolocation is an estimate drawn from databases. It is often decent at country level and region level, and unreliable at street level. Providers route traffic in ways that can place a customer in the wrong city entirely.
Two more things blur the picture:
- VPNs and proxies. A legitimate customer on a work VPN can appear to be in another country. So can a fraudster, deliberately.
- Shared addresses on mobile networks. Many carriers put large numbers of phones behind a smaller pool of public addresses, so one address may not point to one person.
So an IP address in the same city as the billing address is mildly reassuring, not conclusive. And an IP address in a different country is not proof of fraud, since travel and VPNs are common. Treat location as a soft signal and say so.
The stronger use: the same connection, over time
The better argument is not "the IP is near the cardholder." It is "this is the same connection the cardholder has used before, on activity they don't dispute."
Consider what that looks like in a real file. The disputed order was placed from an address. Three months earlier, an undisputed order was placed from that same address. The account was created from it. A support email asking about shipping was sent from it. The customer logged in from it the day before the disputed charge.
Now the story has a spine. Either the cardholder made the purchase, or someone with access to their usual network and their account did. For a household or a small office, that second possibility often points to a family member or a coworker, which is a separate dispute type with its own evidence.
This is the same logic card networks apply when they accept prior undisputed transactions as evidence of a returning customer. The IP is one of the details that makes the link concrete. If you want the full rules on that, our piece on Compelling Evidence 3.0 covers them. Here the point is narrower: the IP is the thread that ties separate events together.
What the dispute form actually asks for
Stripe's dispute evidence includes a field for the customer's purchase IP address, alongside fields for things like the customer's email, billing address, and an access activity log for digital products. Pulling the address from the charge is easy when you collected it at checkout. If you use Stripe's hosted tools, it is typically recorded with the payment. If you built your own flow, you may be logging it yourself, or not logging it at all.
Check which one you are. If your own database does not store the address with each order and login, the evidence you want will not exist when a dispute arrives.
Build the comparison table, not the screenshot
A lone number does little. A short table does a lot. Something like this:
| Date | Event | IP address |
|---|---|---|
| Jan 12 | Account created | 203.0.113.42 |
| Jan 12 | First purchase (not disputed) | 203.0.113.42 |
| Mar 3 | Support email sent | 203.0.113.42 |
| Apr 9 | Login | 203.0.113.42 |
| Apr 10 | Disputed purchase | 203.0.113.42 |
The reviewer can see the match in two seconds. Add one sentence above the table: what the match shows, and what you are not claiming. Something like: "The disputed purchase came from the same network as the account's creation and earlier undisputed orders. We are not claiming this identifies the individual, only that the activity is consistent with the account holder's established use."
That second half matters. Restraint reads as honesty, and reviewers are looking for honesty.
When the addresses don't match
Sometimes they won't, and you should know what to do with that.
If the disputed purchase came from an address you have never seen, and your earlier orders from this customer all came from one place, the IP is evidence against you. Don't hide that. You may still have strong evidence elsewhere: a delivery to a confirmed address, a matching CVV and postal code check, device details, or a reply from the customer after the order. Lead with those. Leave the IP out rather than present a mismatch as a match.
If the addresses differ because the customer was on mobile one time and home broadband another, say so only if you can support it, for example with matching device or account details. Otherwise don't stretch.
What to do with it before the dispute
The most important thing about this evidence is that it is time-sensitive. Logs rotate. A server that keeps 30 days of access records cannot show you an account creation from last year. The decision to keep IP addresses has to be made before a dispute exists. Keep in mind that IP addresses can count as personal data under some privacy laws, so decide how long to keep them, and say so in your privacy policy.
Your next moves
- Check what you already store. Open a recent order in your admin panel or database and see whether an IP address is saved with it. Do the same for account creation and login events. Write down which of the three you have.
- Start logging the missing ones today. If account creation or login events don't record the IP, add it. A single column and a few lines of code is usually enough.
- Set a retention period on purpose. Decide how long you keep these records (many merchants choose at least as long as the dispute window for their payment methods) and write it down. Confirm your privacy policy mentions that you collect IP addresses.
- Make a template for the comparison table. Save a blank version with the columns above. When a dispute arrives, you only fill in rows.
- Pull IP data for your last lost dispute. Look at one you lost. Would a matching-history table have been possible? That tells you whether your records are ready.
Where this fits
The IP address will never win a dispute alone, and it was never going to. What it does is turn a pile of unrelated records into one account's history, which is what a reviewer is trying to decide about. The merchants who use it well are the ones who captured the data months ago and write about it modestly.
Argeback pulls the details already attached to your Stripe disputes, including customer and charge data, and builds them into a draft response you can review and file from your phone before the deadline. If you would rather not assemble tables like this by hand each time, you can see how it works at argeback.lumenlabs.works.