Zahlungsbetrug erkennen: Wo IP-Signale in Ihren Stack gehören
Die Erkennung von Zahlungsbetrug ist ein mehrschichtiger Stack, und die IP ist seine günstigste Ebene: was Netzwerksignale vor der Autorisierung erfassen und wo sie übergeben.

Fragen Sie zehn Payment-Teams, was Betrug stoppt, und Sie hören zehn verschiedene Einzelantworten: Regeln, Machine Learning, 3-D Secure, manuelle Prüfung. Die ehrliche Antwort ist ein Stack. Jede funktionierende Abwehr im Zahlungsverkehr ist mehrschichtig, weil jede Ebene einen blinden Fleck hat und Angreifer genau auf die zielen, die Sie ausgelassen haben. Dieser Leitfaden zeichnet den Stack von Anfang bis Ende nach und konzentriert sich auf die Ebene, die zuerst greift und am wenigsten kostet: das Netzwerk, meist verdichtet zu einem IP-Risikoscore von 0 bis 100, auf den Sie reagieren können. Richtig eingesetzt beseitigt IP-Intelligence ganze Angriffsklassen, bevor sie Ihren Zahlungsdienstleister überhaupt erreichen, und verbessert unauffällig jede Ebene dahinter.

Das Problem, ehrlich beziffert
Kartenbetrug schrumpft nicht. Der Nilson Report beziffert die weltweiten Verluste durch Kartenbetrug auf 33,45 Milliarden US-Dollar im Jahr 2022, mit einer Prognose von über 43 Milliarden US-Dollar bis 2028, wobei die US-Verluste überwiegend ein Card-not-present-Problem sind (Nilson Report). Und die Kostenasymmetrie ist in beide Richtungen brutal: Jeder Dollar Betrug kostet US-Händler im Einzel- und Onlinehandel 4,61 US-Dollar, wenn Arbeitszeit, Untersuchung und Rückgewinnung mitgerechnet werden (The Paypers), während die Überblockierung legitimer Bestellungen still Umsatz versickern lässt. Eine Abwehr im Zahlungsverkehr muss Betrug und falsche Ablehnungen gleichzeitig reduzieren, und genau dafür sind abgestufte, mehrschichtige Systeme da.
Kennen Sie Ihren Angreifer: die vier Familien von Zahlungsangriffen
Der Katalog automatisierter Bedrohungen von OWASP benennt die industriellen Varianten (OWASP Automated Threats):
| Angriff | OWASP-ID | Was passiert | Das Erkennungsmerkmal |
|---|---|---|---|
| Card Testing | OAT-001 Carding | Bots führen kleine Autorisierungen mit massenhaft gestohlenen Karten durch, um gültige zu finden | Hohe Versuchsgeschwindigkeit, Herkunft aus Rechenzentren oder Proxys, winzige Beträge |
| Card Cracking | OAT-010 | Bots ermitteln per Brute Force fehlende Ablaufdaten und CVVs zu unvollständigen Kartendaten | Viele Ablehnungen pro Karte, systematische Variation der Parameter |
| Cashing Out | OAT-012 | Validierte gestohlene Karten werden für echte Einkäufe oder Geschenkkarten verwendet | Geografische Abweichung, Anonymisierer, Expressversand, digitale Güter |
| ATO beim Checkout | (Kontoebene) | Ein gekapertes Kundenkonto bezahlt mit der hinterlegten Karte | Neues Netzwerk und neues Gerät bei einem vertrauenswürdigen Konto |
Friendly Fraud, bei dem der echte Karteninhaber einen tatsächlichen Kauf anfechtet, steht bewusst nicht in dieser Tabelle: Kein Netzwerksignal sieht ihn kommen, und das ist schon für sich eine Lektion über den Stack.
Der Stack, Ebene für Ebene
- Netzwerkebene (vor der Autorisierung). Bewerten Sie die IP bei jedem Checkout, jeder Kartenaktualisierung und jedem Zahlungsversuch. Hier werden Skripte aus Rechenzentren, anonymisierte Sitzungen und Quellen mit hoher Geschwindigkeit herausgefiltert, bevor sie Sie etwas kosten.
- Geschwindigkeitsebene. Versuche pro IP, pro /64-Präfix, pro Karte, pro Konto, pro Kampagne. Günstige Zähler erfassen, was Reputation übersieht.
- Geräte- und Verhaltensebene. Fingerprints und Sitzungsverhalten erkennen wiederkehrende Kunden und entdecken Automatisierung, die den Netzwerkfilter überstanden hat. Die Arbeitsteilung behandelt Device Fingerprinting vs. IP-Intelligence.
- Authentifizierungsebene des Kartenherausgebers. Risikobasierte Authentifizierung mit 3-D Secure, bei der der Kartenherausgeber Bestellungen mit geringem Risiko reibungslos genehmigt und für den Rest eine Challenge verlangt, und bei authentifiziertem Betrug geht die Haftung auf den Kartenherausgeber über (Visa zu 3-D Secure).
- Prüf- und Beweisebene. Warteschlangen für die manuelle Prüfung wirklich unklarer Fälle und protokollierte Belege für die Streitfälle, die Sie später ausfechten, wie in Chargebacks mit IP-Erkennung reduzieren beschrieben.
Die Reihenfolge ist wichtig, weil die Kosten mit der Tiefe steigen. Eine IP-Abfrage dauert Millisekunden und kostet Bruchteile eines Cents. Eine 3-D-Secure-Challenge kostet Conversion. Eine manuelle Prüfung kostet Minuten eines menschlichen Analysten. Ein Chargeback kostet die Ware, die Gebühren und Ihre Chargeback-Quote. Jeder Angriff, den Sie auf Ebene eins stoppen, stellt Ihnen auf Ebene fünf nie eine Rechnung.
Was die IP-Ebene vor der Autorisierung beiträgt
Ehrlichkeit der Infrastruktur. Echte Kunden bezahlen über Privat- und Mobilfunkanschlüsse. Ein Checkout aus einem Rechenzentrums- oder Hosting-Bereich ist Automatisierung, bis das Gegenteil bewiesen ist, und Verbindungstyp plus ASN-Typ ist der günstigste erste Filter, den Sie betreiben können.
Anonymisierung beim Zahlungsschritt. VPN- und Proxy-Flags beim Surfen sind für sich allein schwache Belege. Dieselben Flags gezielt beim Schritt der Karteneingabe oder ein Tor-Exit beim Checkout verdienen zusätzliche Hürden. Die Mechanik der Erkennung steht in wie VPN- und Proxy-Erkennung funktioniert.
Geografische Konsistenz. Drei Länder sollten in der Regel übereinstimmen: der Standort der IP, das Ausgabeland der Karten-BIN und die Liefer- oder Rechnungsadresse. Eine Abweichung ist ein Reisender oder ein VPN. Wenn alle drei bei einer Erstbestellung mit Expressversand voneinander abweichen, ist das ein Muster, das eine Challenge rechtfertigt.
Richtig gezählte Geschwindigkeit. Card Testing führt Hunderte Versuche pro Quelle durch. Zählen Sie pro IP und bei IPv6 pro /64-Präfix statt pro vollständiger Adresse, sonst sieht ein einziger Ring aus wie Tausende Nutzer (IPv6 pro /64 per Rate Limit begrenzen).
Die Dämpfer. Carrier-Grade NAT bündelt Tausende legitime Kunden hinter einer Adresse, und 42 % der Erwachsenen in den USA gaben in der Umfrage von Security.org vom August 2026 unter 1.008 Personen an, ein VPN zu nutzen. Ein CGNAT-Flag sollte Ihre Reaktion auf Geschwindigkeit bei geteilten IPs abmildern, nicht verschärfen.
Ein Tor-Exit und ein iCloud-Relay am selben Checkout
Dieselbe Frage nach Anonymisierung bekommt gegensätzliche Antworten, je nachdem, was die IP tatsächlich ist. Wir haben am 05.10.2026 einen Tor-Exit und einen Ausgang von iCloud Private Relay abgefragt (die Ergebnisse ändern sich, wenn sich Bereiche verschieben):
[
{
"ip": "185.220.101.1",
"asn": { "asn": 60729, "asn_type": "hosting", "connection_type": "datacenter" },
"geo": { "country_code": "DE", "city": "Hamburg (Hamburg-Nord)" },
"detection": { "is_tor": true, "is_relay": false, "is_anonymous": true, "anonymity_level": "high" },
"scoring": {
"fraud_score": 100,
"recommended_action": "block",
"detection_methods": ["tor_exit", "datacenter_blocklisted", "rdns_tor", "known_spammer"]
}
},
{
"ip": "104.28.46.99",
"asn": { "asn": 13335, "asn_type": "unknown", "connection_type": "unknown" },
"geo": { "country_code": "AO", "city": "Luanda", "geo_confidence": 0.8 },
"detection": {
"is_tor": false,
"is_relay": true,
"is_anonymous": false,
"relay_provider": "iCloud Private Relay"
},
"scoring": {
"fraud_score": 9,
"recommended_action": "allow",
"detection_methods": ["relay_ip"]
}
}
]
Der Tor-Exit bekommt einen Score von 100 mit recommended_action: "block", und detection_methods zeigt warum: tor_exit plus rdns_tor aus seinem Reverse DNS, auf Hosting-Infrastruktur. Das ist der Bereich bestätigt schlechter Fälle, den Sie vor der Autorisierung stoppen. Das Relay bekommt 9 und allow, weil is_relay: true mit relay_provider: "iCloud Private Relay" ein Apple-Kunde ist, der eine eingebaute Datenschutzfunktion nutzt, kein Proxy. Beachten Sie das Land auf IP-Seite, Angola: Ein Relay-Ausgang kann weit vom Karteninhaber entfernt liegen, daher ist eine Abweichung zwischen BIN-Land und IP-Land bei einer Relay-IP ein schwacher Beleg und sollte die Bestellung nicht allein in den Sperrbereich schieben.
Card Testing verdient einen eigenen Absatz
Card Testing betrifft rund ein Drittel der Onlinehändler weltweit (Statistiken zu Card Testing), und es ist das reinste Beispiel für einen Angriff, den die IP-Ebene schlicht entfernen sollte. Die Bots validieren gestohlene Karten mit kleinen Autorisierungen, Sie zahlen die Autorisierungs- und Ablehnungsgebühren so oder so, und jede Karte, die sie validieren, wird anderswo zu echtem Betrug. Das Traffic-Profil ist unverkennbar: Herkunft aus Rechenzentren und Proxys, Versuchsraten in Maschinengeschwindigkeit, winzige Beträge oder Beträge von null Dollar. Bewerten Sie die IP, bevor die Anfrage Ihren Zahlungsdienstleister erreicht, setzen Sie Rate Limits pro Adresse und pro Präfix und lehnen Sie stillschweigend ab oder isolieren Sie in einer Sandbox, was durchfällt. Card Testing am Netzwerkrand zu stoppen ist die Betrugskontrolle mit dem höchsten ROI, die die meisten Payment-Teams noch nicht vollständig eingeführt haben.
Den Kartenherausgeber versorgen, nicht bekämpfen
3-D Secure ist kein Konkurrent Ihrer eigenen Erkennung; es ist eine Ebene, die von Signalen lebt. Der Kartenherausgeber entscheidet anhand des Risikobilds, das er sehen kann, zwischen reibungslos und Challenge, und Sie entscheiden, welche Bestellungen überhaupt in diesen Ablauf gehen. Das bewährte Muster spiegelt Schwellenwerte für den Risikoscore pro Aktion: Lassen Sie den sauberen Bereich reibungslos zu, leiten Sie den mittleren Bereich in eine 3-D-Secure-Challenge, damit die Haftung für authentifizierten Betrug auf den Kartenherausgeber übergeht, und blockieren Sie den Bereich bestätigt schlechter Fälle vor der Autorisierung, damit er Ihre Genehmigungsquote nie berührt. IP-Intelligence ist das, was diese Bereiche günstig und nachvollziehbar sortiert.
Was die IP-Ebene nicht sehen kann
Seien Sie bei den blinden Flecken präzise, denn sie definieren den Rest des Stacks. Die IP kann keinen Friendly Fraud sehen, bei dem der legitime Karteninhaber in seinem gewohnten Heimnetz einen Kauf anfechtet, den er selbst getätigt hat. Sie kann keine gestohlene Karte markieren, die aus der eigenen Nachbarschaft des Opfers genutzt wird. Sie kann ohne Hilfe nicht zwei Kunden hinter einer CGNAT-Adresse unterscheiden. Diese Lücken sind der Grund, warum es Geräteerkennung, Authentifizierung durch den Kartenherausgeber und Prüfung nach der Transaktion gibt, und warum IP-Risiko-Scoring als eine nachvollziehbare Eingabe in eine Entscheidung konzipiert ist und nicht als die Entscheidung selbst.
Eine Abfrage pro Zahlungsversuch
Eine Abfrage pro Zahlungsversuch liefert das Bild vor der Autorisierung: connection_type und asn_type trennen Privat- und Mobilfunkkunden von Skripten aus Rechenzentren und Hosting; der Detection-Block markiert VPN-, Proxy-, Tor- und Relay-Ausgänge mit dem proxy_type und dem anonymity_level hinter jedem Flag; der Geo-Block liefert Ihnen das Land auf IP-Seite für Konsistenzprüfungen gegen BIN und Adresse, mit einer geo_confidence, damit Sie wissen, wie stark Sie sich darauf stützen können; is_cgnat markiert geteilte Mobilfunkadressen, damit Sie abmildern statt ablehnen; und der nachvollziehbare Risikoscore von 0 bis 100 kommt mit einer recommended_action (allow, review, step-up oder block), die sich direkt auf die Bereiche reibungslos, Challenge und Sperre Ihres 3-D-Secure-Routings abbilden lässt. Jedes Feld ist im kostenlosen Tarif mit 1.500 Abfragen pro Tag enthalten, und Sie können den Risikoscore jeder IP ohne API-Schlüssel prüfen, bevor Sie ihn in Ihren Zahlungsablauf einbinden.
Beginnen Sie den Stack zur Erkennung von Zahlungsbetrug beim Netzwerk
Dieser Beitrag ist die Karte; die benachbarten Leitfäden sind das Gelände. Die Schwellenwerte stehen im oben verlinkten Leitfaden zu Schwellenwerten pro Aktion, die Tür zur Kontosicherheit behandelt Account Takeover und Credential Stuffing erkennen, den Nutzen auf der Seite der Streitfälle der Chargeback-Leitfaden aus der Stack-Liste und die Integration in zehn Minuten IP-Betrugserkennung mit einer kostenlosen API einbauen. Bauen Sie die Netzwerkebene zuerst. Sie ist die einzige Ebene, die umso günstiger wird, je früher sie läuft.
Häufig gestellte Fragen
Was ist die Erkennung von Zahlungsbetrug?
Die Erkennung von Zahlungsbetrug ist die Gesamtheit der Prüfungen, die ein Unternehmen vor, während und nach einer Transaktion durchführt, um unautorisierte oder betrügerische Zahlungen zu erkennen: Nutzung gestohlener Karten, Card Testing, Account Takeover beim Checkout und Friendly Fraud. Ausgereifte Systeme sind mehrschichtig statt monolithisch. Netzwerk- und IP-Prüfungen laufen zuerst, Geschwindigkeits- und Gerätesignale bestätigen, die Authentifizierung durch den Kartenherausgeber wie 3-D Secure übernimmt den mittleren Risikobereich, und die Prüfung nach der Transaktion plus Belege für Chargebacks schließen den Kreis.
Welche IP-Signale zählen beim Checkout am meisten?
Vier Gruppen leisten den Großteil der Arbeit: Verbindungstyp und ASN-Typ (ein Checkout eines Privatkunden aus einem Rechenzentrums- oder Hosting-Bereich ist ein Skript, bis das Gegenteil bewiesen ist), Anonymisierungs-Flags (VPN, Proxy oder Tor beim Zahlungsschritt), geografische Konsistenz (IP-Land gegenüber BIN-Land der Karte gegenüber Lieferadresse) und Geschwindigkeit, gezählt pro IP und pro IPv6-/64-Präfix (viele Kartenversuche aus einer Quelle sind Card Testing). Jedes davon braucht Kontext, denn Carrier-Grade NAT und die Nutzung gängiger VPNs sind normal.
Was ist Card Testing und wie stoppe ich es?
Card Testing (OWASP OAT-001 Carding) bedeutet, dass Bots kleine Autorisierungen mit massenhaft gestohlenen Kartennummern durchführen, um herauszufinden, welche Karten noch gültig sind. Jeder Versuch kostet Sie Autorisierungsgebühren, und jeder Erfolg wird später irgendwo zu echtem Betrug. Es ist der Zahlungsangriff, der sich am besten über die IP lösen lässt: Die Bots laufen aus Rechenzentrumsbereichen und Proxy-Pools mit Raten, die kein Mensch erreicht. Wenn Sie die IP bewerten und pro Adresse und pro /64-Präfix ein Rate Limit setzen, bevor die Anfrage Ihren Zahlungsdienstleister erreicht, beseitigen Sie den Großteil davon.
Ersetzt 3-D Secure die Betrugserkennung?
Nein. 3-D Secure ist eine Authentifizierungsebene, die bei authentifizierten Transaktionen die Betrugshaftung auf den Kartenherausgeber verlagert, und ihr risikobasierter Ablauf funktioniert am besten, wenn er reichhaltige Signale erhält. Fordern Sie bei allem eine Prüfung an, verlieren Sie Conversions; fordern Sie bei nichts eine an, behalten Sie die Haftung. Das praktische Muster besteht darin, Ihr eigenes Risiko-Scoring einschließlich IP-Intelligence zu nutzen, um zu entscheiden, welche Transaktionen in eine 3-D-Secure-Challenge geleitet, welche reibungslos zugelassen und welche schon vor der Autorisierung blockiert werden.
Sollte ich VPN-Nutzer beim Checkout blockieren?
Nicht automatisch. Etwa jeder vierte Internetnutzer verwendet ein VPN, überwiegend aus legitimen Datenschutzgründen, sodass eine harte Sperre bei jedem VPN-Flag echten Umsatz ablehnt. Behandeln Sie ein gewöhnliches VPN-Flag als Grund für eine zusätzliche Prüfung, etwa indem Sie die Bestellung in eine 3-D-Secure-Challenge leiten, und reservieren Sie harte Sperren für bestätigte Fälle wie Tor-Exits oder IPs mit bekanntem Missbrauch in Kombination mit weiteren Risikosignalen wie geografischen Abweichungen oder hoher Geschwindigkeit.
Das Team hinter der GeoIPHub-API
Verfasst vom GeoIPHub-Team, den Menschen, die die GeoIPHub-API für IP-Intelligence und ihren Scanner entwickeln. Entwürfe entstehen mit KI-Unterstützung und werden vom Team redigiert; API-Beispiele sind echte Abfragen gegen die Live-API, sofern nicht als illustrativ gekennzeichnet.


