Anwendungsfälle

Abweichende Rechnungs- und Lieferländer erkennen

Nicht jede Bestellung mit einer Rechnungsadresse in einem Land und einer Lieferadresse in einem anderen ist Betrug, denn viele Menschen kaufen Geschenke für Familie im Ausland oder lassen an eine Urlaubsadresse liefern. Ein Händler, der die Rückbuchungsdaten eines Jahres auswertete, stellte jedoch fest, dass Bestellungen, bei denen drei getrennte Standortsignale, nämlich Rechnungsland, Lieferland und das aus der verbindenden IP-Adresse der Bestellung ermittelte Land, alle voneinander abwichen, dramatisch häufiger in einem Streitfall endeten als Bestellungen, bei denen wenigstens zwei der drei übereinstimmten.

Rechnungs- und Lieferland erfasste der Händler bereits als Standardfelder im Checkout. Hinzu kam das dritte, unabhängige Signal: /v1/ip ermittelte das Land der IP-Adresse, von der die Bestellung aufgegeben wurde, und glich es automatisch mit den beiden vom Kunden eingegebenen Feldern ab. Eine Geschenkbestellung, bei der sich Rechnungs- und Lieferland häufig unterscheiden, die IP-Adresse aber meist noch zum Rechnungsland passt, weil der eigentliche Käufer die Bestellung von zu Hause aus aufgibt, sah deutlich anders aus als eine Bestellung, bei der alle drei voneinander abwichen, denn dieses Muster lässt sich viel schwerer mit einem harmlosen, alltäglichen Szenario erklären.

Der Händler baute eine einfache Bewertungsregel statt einer pauschalen Sperre: Eine Bestellung, bei der alle drei Signale übereinstimmten, lief normal und ohne zusätzliche Hürden weiter. Eine Bestellung mit einer plausiblen Übereinstimmung von zwei Signalen, etwa eine Geschenkbestellung mit übereinstimmendem Rechnungs- und IP-Land, aber abweichender Lieferadresse, lief ebenfalls normal weiter, denn dieses Muster entsprach einem äußerst verbreiteten und völlig legitimen Einkaufsverhalten. Eine Bestellung, bei der alle drei voneinander abwichen, wurde vor dem Versand für einen manuellen Prüfschritt oder eine zusätzliche Verifizierungsanfrage markiert, eine kleine zusätzliche Hürde, die nur bei dem Muster greift, das die eigenen Daten des Händlers als überproportional riskant ausgewiesen hatten.

Das war wichtig, weil die Alternative, jede Abweichung zwischen Rechnungs- und Lieferadresse schon für sich genommen als verdächtig zu behandeln, bei einer riesigen Zahl völlig legitimer Geschenkbestellungen zusätzliche Hürden geschaffen hätte, genau die Art von Fehlalarm, die einen Händler echte Umsätze kostet, ohne Betrug nennenswert zu verringern. Durch das dritte, unabhängige IP-basierte Signal konnte der Händler den Prüfschritt viel gezielter einsetzen, nämlich bei dem Muster, das seine eigenen Daten tatsächlich mit Rückbuchungen in Verbindung brachten, statt bei einem breiten und größtenteils harmlosen Verhalten, das mit diesem Muster nur eine oberflächliche Ähnlichkeit teilte.

Der Händler maß die Wirkung der Änderung in den folgenden Monaten direkt an seiner Rückbuchungsquote und stellte einen echten Rückgang fest. Er wies allerdings ausdrücklich darauf hin, dass diese einzelne Prüfung nur ein Teil einer umfassenderen Betrugsprävention war, zu der auch andere Signale gehörten, darunter Zahlungsverifizierung, Schwellenwerte für den Bestellwert und die Kontohistorie, und schrieb die Verbesserung deshalb nicht allein dem IP-Abgleich zu.

Die Kosten waren im Verhältnis zum geschützten Wert verschwindend gering: eine zusätzliche Abfrage pro Bestellung, die bei einem mittelgroßen Händler bequem in das kostenlose Tageskontingent passte und nur in der Hochsaison auf Prepaid-Guthaben überging. Diese Kosten fielen neben den durchschnittlichen Kosten einer einzigen Rückbuchung, die Gebühren und Reputationsschäden weit über den Wert der strittigen Bestellung hinaus mit sich bringt, überhaupt nicht ins Gewicht.

Die Dokumentation zum Endpunkt finden Sie unter /docs/ipv4-lookup/ und /docs/ipv6-lookup/, die Authentifizierungsmethoden sind unter /docs/authentication/ beschrieben.