Radar for Fraud Teams: Das Regel-Einmaleins

Dieser Leitfaden enthält verschiedene Themen rund um Radar-Regeln, darunter über 100 Radar-Regeln, die Sie nutzen können, sowie Best Practices zum Backtesting, zur Erstellung von Regeln und vieles mehr.

  1. Einführung
  2. Die Bedeutung von Reihenfolge und Hierarchie der Regeln
  3. Spickzettel für die Regelsprache
  4. Häufig verwendete Radar-Regeln
    1. Regeln, die Kartentests oder Card Cashing verhindern helfen
    2. Regeln zur Vorbeugung von Betrug mit bekanntermaßen risikoreichen SKUs
    3. Regeln, die Missbrauchsversuche mit Prepaid-Karten verhindern helfen
    4. Regeln, die zur Vermeidung mehrerer Zahlungsanfechtungen von einer Karte aus beitragen können
  5. Drei Attributtypen zur Erstellung von Regeln
    1. Typ 1
    2. Typ 2
    3. Attribute, die auf der Häufigkeit basieren
    4. Attribute, die auf Kartenangaben basieren
    5. Attribute, die auf Zahlungsdetails basieren
    6. Attribute, die auf Details von Kund/innen basieren
    7. Typ 3
  6. Verwendung gespeicherter Listen in Ihren Regeln (beispielsweise Erlaubt- oder Blocklisten)
  7. Komplexe Regeln mit mehreren Bedingungen schreiben
  8. Backtesting von Regeln
    1. Backtesting im Dashboard
    2. Durchführung von kundenspezifischen Backtesting-Analysen
  9. Häufige Betrugsvektoren
    1. Tests
    2. Wertextraktion
  10. Analyse Ihrer Betrugsfälle als Grundlage für die Regelentwicklung
    1. Überprüfung von Betrugsfällen
  11. Weitere Best Practices
    1. Die Verwendung von Stripe.js ist wichtig
  12. Fazit
    1. Weitere Hinweise

Die Standardregeln von Stripe nutzen maschinelles Lernen, um eine signifikante Anzahl betrügerischer Zahlungen vorherzusagen und zu blockieren. Für Unternehmen, die mehr Einfluss darauf wünschen, welche Zahlungen überprüft, zugelassen oder blockiert werden sollen, sind Regeln ein leistungsstarkes Tool zur Anpassung der Betrugsvorbeugung.

Dieser Leitfaden enthält verschiedene Themen rund um Radar-Regeln, darunter über 100 Radar-Regeln, die Sie nutzen können, sowie bewährte Verfahren zum Backtesting, zur Erstellung von Regeln und vieles mehr.

Legen wir los.

Die Bedeutung von Reihenfolge und Hierarchie der Regeln

Die Reihenfolge, in der die Regeln auf Ihrer Radar-Seite aufgelistet sind, spielt eine Rolle. Jede Zahlung wird anhand der von Ihnen erstellten Regeln in der folgenden Reihenfolge bewertet und ausgeführt:

  1. Request 3DS: Regeln, die eine 3D-Secure-Authentifizierung anfordern, wenn sie mit der Payment-Intents-API oder Checkout verwendet werden. Unabhängig von den Übereinstimmungen mit dieser Regel werden die Regeln Allow, Block und Review danach ausgewertet.
  2. Allow: Regeln, die die Verarbeitung einer Zahlung ermöglichen. Allow-Regeln sollten sorgfältig implementiert werden, da sie alle anderen außer 3DS-Regeln übergehen – einschließlich der Modelle für das maschinelle Lernen von Stripe, und sollten mit größter Vorsicht verwendet werden. Nur Händler, die mehr als 100.000 USD verarbeitet haben, können Allow-Regeln schreiben.
  3. Block: Regeln, die eine Zahlung blockieren und ablehnen. Wird eine Zahlung abgelehnt, wird sie nicht anhand von Review-Regeln bewertet.
  4. Review: Diese Zahlungen werden verarbeitet und beim Kunden abgebucht, werden aber gekennzeichnet, damit Sie gegebenenfalls einen zweiten Blick darauf werfen können.

Die folgenden Regeln dienen als praktisches Beispiel. Alle Zahlungen unter 10 $ werden bearbeitet. Dies liegt daran, dass die erste Regel die Zahlung zulässt, ohne dass weitere Regeln ausgewertet werden. Weiterhin wäre auch eine Zahlung von 1.500 USD innerhalb der USA mit einem normalen Risikoniveau zulässig, obwohl Zahlungen über 1.000 $ blockiert werden. Grund dafür ist die zweite Regel in der Liste, die Zahlungen innerhalb der USA mit einem normalen Risikoniveau zulässt. Sobald eine bestimmte Regel ausgelöst wird, werden keine weiteren Regeln mehr ausgewertet.

  • Allow payments less than $10

  • Allow payments within the US and with a risk level of normal

  • Block payments where the risk level is high

  • Block payments greater than $1,000

  • Review payments with a card issued outside the US

Spickzettel für die Regelsprache

Die Regeln ähneln SQL. Es stehen verschiedene Operatoren zur Verfügung, deren Anwendung vom Datentyp abhängt, den Sie zur Erstellung Ihrer Regel verwenden. Hier ist ein Spickzettel.

Operator
Zeichen-folge
Metadaten
Land
Numerisch
Beschreibung
Beispiel
=
Ist gleich

:card_country: = 'us'

!=
Ist nicht gleich

:card_funding: != 'prepaid'

<
Kleiner als

:amount_in_gbp: < 10.00

>
Größer als

:amount_in_usd: > 500.00

<=
Kleiner als oder ist gleich

:amount_in_eur:<= 100.00

>=
Größer als oder ist gleich

:amount_in_cad: >= 10.00

IN
Gehört zur Gruppe

:card_country: IN ('gb', 'ie')

INCLUDES
Enthält die Zeichenfolge

:ip_address: INCLUDES '192.168'

Wenn Sie explizit auf das Vorhandensein eines Attributs oder Metadatenattributs prüfen möchten, verwenden Sie nicht den Operator !=, sondern die Funktion is_missing. Übergeben Sie dieser Funktion das Attribut oder den Metadatenschlüssel, der möglicherweise fehlt. Sie könnten zum Beispiel eine Regel schreiben, die alle Zahlungen erfasst, bei denen Sie keinen Zugriff auf die E-Mail-Adresse des Kunden/der Kundin haben:

  • Review if is_missing(:email_domain:)

Oder Sie könnten eine Regel schreiben, die alle Zahlungen erfasst, bei denen die E-Mail-Adresse eines Kunden/einer Kundin NICHT fehlt:

  • Review if !(is_missing(:email_domain:))

Häufig verwendete Radar-Regeln

Hier folgt eine Liste häufig verwendeter Radar-Regeln mit unterschiedlichen Zielsetzungen.

Regeln, die Kartentests oder Card Cashing verhindern helfen

Block if :total_charges_per_ip​_address_hourly: > 1

Diese Regel eignet sich besonders zur Bekämpfung von Kartentests. Sie blockiert Zahlungen, wenn eine IP-Adresse mehr als einmal erfolgreich in Ihrem Konto autorisiert wurde.

Block if :blocked_charges_per_ip​_address_hourly: > 1

Wenn Sie bei der Bekämpfung der Betrugsmasche Kartentests aggressiver vorgehen möchten, verwenden Sie diese Regel in Verbindung mit :total_charges_per_ip_address_hourly:

Block if :total_charges_per​_card_number_hourly: > 1

Diese Regel eignet sich besonders zur Verhinderung von Card Cashing. Sie blockiert Zahlungen, wenn eine Kartennummer in der vergangenen Stunde mehr als einmal erfolgreich in Ihrem Konto autorisiert wurde.

Block if :blocked_charges_per_card​_number_hourly: > 1

Wenn Sie bei der Bekämpfung der Betrugsmasche Card Cashing aggressiver vorgehen möchten, verwenden Sie diese Regel in Verbindung mit :total_charges_per_card_number_hourly:

Block if :address_zip_check: != 'pass'

Achten Sie darauf, die Postleitzahl in Ihrem Checkout-Formular zu erfassen, um diese Regel zu verwenden. Diese Regel blockiert Zahlungen, wenn der Kartenaussteller feststellt, dass die angegebene Postleitzahl nicht mit den Daten übereinstimmt, die für die Karte hinterlegt wurden.

Block if :cvc_check:: != 'pass'

Achten Sie darauf, die Prüfziffer (CVC) in Ihrem Checkout-Formular zu erfassen, um diese Regel zu verwenden. Diese Regel blockiert Zahlungen, wenn der/die Kartenaussteller/in feststellt, dass die angegebene CVC (oder CVV) nicht mit den Daten übereinstimmt, die für die Karte hinterlegt wurden.

Regeln zur Vorbeugung von Betrug mit bekanntermaßen risikoreichen SKUs

Diese Regel erfordert Metadaten oder die Übergabe von SKU-Informationen als Zahlungsbeschreibung. Diese Zahlungen werden verarbeitet und bei den Kund/innen abgebucht. Sie werden allerdings gekennzeichnet, damit Sie einen zweiten Blick darauf werfen können.

Review if ::SKU Category:: IN ('baby formula', 'personal hygiene')

Nehmen wir an, Sie betreiben einen Lebensmittelladen und senden uns Metadaten mit der SKU-Kategorie. Sie haben festgestellt, dass das Risiko bei Bestellungen, die Artikel der SKU-Kategorien „Körperpflege“ und „Säuglingsnahrung“ enthalten, häufig höher ist. Mit dieser Regel werden sämtliche Bestellungen mit diesen Artikeln auf die Liste „Manuelle Prüfung“ in Ihrem Stripe-Dashboard gesetzt, damit Sie sie genauer überprüfen können. Bitte beachten Sie, dass die damit verbundenen Zahlungsvorgänge weiterhin abgewickelt und Kund/innen belastet werden, außer Sie stornieren die Bestellung manuell.

Review if :charge_description: = 'Trial class'

Nehmen wir an, Sie verkaufen zwei Produkte („Probeunterricht“ und „Paket 10 Unterrichtsstunden“) und geben Stripe gegenüber den Produktnamen als Zahlungsbeschreibung an. Mit dieser Regel werden sämtliche Bestellungen, deren Zahlungsbeschreibung „Probeunterricht“ lautet, auf die Liste „Manuelle Prüfung“ in Ihrem Stripe Dashboard gesetzt, damit Sie sie genauer überprüfen können. Bitte beachten Sie, dass die damit verbundenen Zahlungsvorgänge weiterhin abgewickelt und Kund/innen belastet werden, außer Sie stornieren die Bestellung manuell.

Regeln, die Missbrauchsversuche mit Prepaid-Karten verhindern helfen

Block if :card_funding: = 'prepaid' OR :card_funding: = 'unknown'

Nehmen wir an, Sie sind ein/e Einzelhändler/in und bieten Produkte an, die zu Hause getestet werden können und haben vermehrt Personen mit betrügerischen Absichten entdeckt, die Prepaid-Karten verwendet haben, die später nicht belastet werden können. Mit dieser Regel blockieren Sie sämtliche Bestellungen, die nicht mit einer Kredit- oder Debitkarte bezahlt werden.

Regeln, die zur Vermeidung mehrerer Zahlungsanfechtungen von einer Karte aus beitragen können

Block if :prior_fraud_disputes_with​_card_count_all_time: > 0

Diese Regel blockiert Transaktionen in Verbindung mit Karten, die mit einer früheren angefochtenen Zahlung in Zusammenhang stehen.

Block if :prior_fraud_disputes_with​_card_yearly: > 0

Diese Regel blockiert Transaktionen in Verbindung mit Karten, die im vergangenen Jahr mit einer angefochtenen Zahlung in Zusammenhang standen.

Drei Attributtypen zur Erstellung von Regeln

Typ 1

Post-Authorisation-Attribute: Diese stehen für alle zur Verfügung. Beim Einsatz von Post-Authorization-Attributen müssen Sie Doppelpunkte vor und nach Attributen wie :cvc_check: verwenden.

Eigenschaften
Beschreibung

:address_line1_check:

Prüfung durch den Kartenaussteller, ob die erste Zeile der angegebenen Rechnungsadresse (in der Regel Straße und Hausnummer) mit den hinterlegten Daten der Karteninhaberin/des Karteninhabers übereinstimmt.

:address_zip_check:

Prüfung durch den Kartenaussteller, ob die angegebene Postleitzahl mit den hinterlegten Daten der Karteninhaberin/des Karteninhabers übereinstimmt.

:cvc_check​:

Prüfung durch den Kartenaussteller, ob die angegebene Prüfziffer (CVC oder CVV) mit den hinterlegten Daten der Karteninhaberin/des Karteninhabers übereinstimmt.
Mögliche Werte
Beschreibung

pass

Die angegebenen Daten sind korrekt.

fail

Die angegebenen Daten sind nicht korrekt.

unavailable

Der Kartenaussteller der Kundin/des Kunden wird die angegebenen Daten nicht prüfen. Nicht alle Kartenaussteller oder Länder unterstützen die Adressprüfung.

unchecked

Die Daten wurden übermittelt, sind aber noch nicht geprüft. Der Kartenaussteller der Kundin/des Kunden wird die angegebenen Daten später prüfen.

not_provided

Die Daten wurden nicht an Stripe übermittelt.
Achten Sie auf Groß- und Kleinschreibung bei den Werten.

Hier folgt ein Beispiel für die Verwendung von Post-Authorisation-Attributen:

  • Block if :address_line1_check: != 'pass' Mit dieser Regel wird jede Zahlung blockiert, wenn sie die Prüfung des Kartenausstellers nicht besteht, bei der die erste Zeile der angegebenen Rechnungsadresse mit den Informationen abgeglichen wird, die für den Karteninhaber/die Karteninhaberin vorliegen. Das bedeutet, dass die Zahlung blockiert wird, wenn die Prüfung ‘unavailable’ ist, wenn diese Daten beim Aussteller ‘unchecked’ oder ‘not_provided’ sind.

Typ 2

Standardattribute: Diese stehen für alle zur Verfügung. Sie müssen Doppelpunkte vor und nach den Standardattributen verwenden, z. B. :card_bin: Wir haben unsere Standardattribute in vier Kategorien unterteilt:

  • Attribute, die auf der Häufigkeit basieren – nützlich, um Kartentests oder Card Cashing vorzubeugen
  • Attribute, die auf Kartenangaben basieren
  • Attribute, die auf Zahlungsdetails basieren
  • Attribute, die auf Kund/innendetails basieren

Einige Attribute erfordern Werte in Form von Strings, während für andere ein Wert als Zahl erforderlich ist. Zur Verdeutlichung haben wir für jedes Attribut ein Beispiel angegeben. Erfordert das Attribut eine Zeichenkette wie :card_bin:, so sehen Sie im Beispiel, dass der String innerhalb von ' ' liegt. Beispielsweise :card_bin: = ‘424242’ – ist dagegen eine Zahl erforderlich, gibt es keine ‘ ’, so wie in :amount_in_usd: > 250.

Attribute, die auf der Häufigkeit basieren

Es gibt vier Typen von Attributen, die auf der Häufigkeit basieren und besonders nützlich sind, um gestohlene Karten, Kartentests und Card Cashing zu verhindern.

  1. Authorization: basierend auf Autorisierungen durch den Aussteller
  2. Charge: basierend auf Zahlungen
  3. Decline: basierend auf Ablehnungen durch den Aussteller
  4. Block: basierend auf den vom maschinellen Lernen von Radar durchgeführten Blockierungen

Es gibt auch Attribute, die auf dem Ergebnis der Zahlung basieren, einschließlich Autorisierungen (basierend auf erfolgreichen Autorisierungen durch den Aussteller), Zahlungen (basierend auf Zahlungsversuchen), Ablehnungen (basierend auf Ablehnungen durch den Aussteller), Anfechtungen (frühere Transaktionen, die als betrügerisch angefochten wurden) und Blockierungen (basierend auf Blockierungen durch das maschinelle Lernen von Radar). Um ein Attribut zu bilden, werden die Ergebnisse mit einem Kundendetail (E-Mail, IP-Adresse, Name oder Kunden-ID) kombiniert.

Außerdem können Sie die Häufigkeit eines Kundendetails (E-Mail, Name) mit der bei einer Transaktion verwendeten Karte oder IP-Adresse kombinieren. Anders ausgedrückt: Es gibt zwei Arten von Häufigkeitsregeln:

  1. Basierend auf dem Ergebnis der Zahlung (z. B. authorized_charges_per_email_hourly, blocked_charges_per_email_hourly) mit dem Resutat: erfolgreiche Autorisierung, Zahlungsversuch, Ablehnungen, Zahlungsanfechtungen, Blockierungen
  2. Basierend auf Verbindungen zwischen Kund/in und Karte oder IP (z. B. name_count_for_card_weekly, email_count_for_ip_hourly)

Häufigkeitsregeln schließen die Zahlung aus, die Sie gerade verarbeiten. Zum Beispiel gibt authorized_charges_per_email_hourly die Anzahl der bisherigen erfolgreichen Zahlungsversuche von einer E-Mail-Adresse in der vorangegangenen Stunde an. Beim ersten Zahlungsversuch innerhalb einer bestimmten Stunde für eine E-Mail-Adresse hat authorized_charges_per_email_hourly also den Wert 0. War die erste Zahlung erfolgreich, hat der zweite Zahlungsversuch innerhalb der gleichen Stunde von dieser E-Mail-Adresse den Wert 1, und so weiter.

Eigenschaft
Beschreibung

:authorized_charges_per​_card_number_all_time:

Die Anzahl der in einer erfolgreichen Autorisierung resultierten, über diese Karte abgewickelten Zahlungen in Ihrem Konto. Dies gilt für Kontozahlungen ab 2020. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:authorized_charges_per​_card_number_weekly:

Die Anzahl der in einer erfolgreichen Autorisierung resultierten, über diese Karte abgewickelten Zahlungen im Verlauf der vergangenen Woche in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:authorized_charges_per​_card_number_daily:

Die Anzahl der in einer erfolgreichen Autorisierung resultierten, über diese Karte abgewickelten Zahlungen im Verlauf des vergangenen Tages in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:authorized_charges_per​_card_number_hourly:

Die Anzahl der in einer erfolgreichen Autorisierung resultierten, über diese Karte abgewickelten Zahlungen im Verlauf der vergangenen Stunde in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:authorized_charges_per​_email_all_time:

Die Anzahl der in einer erfolgreichen Autorisierung resultierten Zahlungen von dieser E-Mail in Ihrem Konto. Dies gilt für Kontozahlungen ab 2020. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:authorized_charges_per​_email_weekly:

Die Anzahl der in einer erfolgreichen Autorisierung resultierten Zahlungen von dieser E-Mail im Verlauf der vergangenen Woche in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:authorized_charges_per​_email_daily:

Die Anzahl der in einer erfolgreichen Autorisierung resultierten Zahlungen von dieser E-Mail im Verlauf des vergangenen Tages in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:authorized_charges_per​_email_hourly:

Die Anzahl der in einer erfolgreichen Autorisierung resultierten Zahlungen von dieser E-Mail im Verlauf der vergangenen Stunde in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:authorized_charges_per​_ip_address_all_time:

Die Anzahl der in einer erfolgreichen Autorisierung resultierten Zahlungen von dieser IP-Adresse in Ihrem Konto. Dies gilt für Kontozahlungen ab 2020. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:authorized_charges_per​_ip_address_weekly:

Die Anzahl der in einer erfolgreichen Autorisierung resultierten Zahlungen von dieser IP-Adresse im Verlauf der vergangenen Woche in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:authorized_charges_per​_ip_address_daily:

Die Anzahl der in einer erfolgreichen Autorisierung resultierten Zahlungen von dieser IP-Adresse im Verlauf des vergangenen Tages in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:authorized_charges_per​_ip_address_hourly:

Die Anzahl der in einer erfolgreichen Autorisierung resultierten Zahlungen von dieser IP-Adresse im Verlauf der vergangenen Stunde in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:authorized_charges_per​_customer_daily:

Wie oft eine Kundin/ein Kunde im Verlauf der vergangenen 24 Stunden erfolgreich über Ihr Konto autorisiert wurde. (Die aktuell zu bewertende Zahlung wird nicht mitgezählt.)

:authorized_charges_per​_customer_hourly:

Wie oft eine Kundin/ein Kunde im Verlauf der vergangenen Stunde erfolgreich über Ihr Konto autorisiert wurde. (Die aktuell zu bewertende Zahlung wird nicht mitgezählt.)

:blocked_charges_per​_card_number_daily:

Wie oft eine Kartennummer im Verlauf der vergangenen 24 Stunden von den Stripe-Modellen für maschinelles Lernen in Ihrem Konto blockiert wurde. Die aktuell zu bewertende Zahlung wird nicht mitgezählt (z. B. 4).

:blocked_charges_per​_card_number_hourly:

Wie oft eine Kartennummer im Verlauf der vergangenen Stunde von den Stripe-Modellen für maschinelles Lernen in Ihrem Konto blockiert wurde. Die aktuell zu bewertende Zahlung wird nicht mitgezählt (z. B. 4).

:blocked_charges_per​_customer_daily:

Wie oft eine Kundin/ein Kunde im Verlauf der vergangenen 24 Stunden von den Stripe-Modellen für maschinelles Lernen in Ihrem Konto blockiert wurde. Die aktuell zu bewertende Zahlung wird nicht mitgezählt (z. B. 4).

:blocked_charges_per​_customer_hourly:

Wie oft eine Kundin/ein Kunde im Verlauf der vergangenen Stunde von den Stripe-Modellen für maschinelles Lernen in Ihrem Konto blockiert wurde. Die aktuell zu bewertende Zahlung wird nicht mitgezählt (z. B. 4).

:blocked_charges_per​_ip_address_daily:

Wie oft eine IP-Adresse im Verlauf der vergangenen 24 Stunden von den Stripe-Modellen für maschinelles Lernen in Ihrem Konto blockiert wurde. Die aktuell zu bewertende Zahlung wird nicht mitgezählt (z. B. 4).

:blocked_charges_per​_ip_address_hourly:

Wie oft eine IP-Adresse im Verlauf der vergangenen Stunde von den Stripe-Modellen für maschinelles Lernen in Ihrem Konto blockiert wurde. Die aktuell zu bewertende Zahlung wird nicht mitgezählt (z. B. 4).

:total_charges_per​_card_number_daily:

Wie oft im Verlauf der vergangenen 24 Stunden versucht wurde, eine Karte in Ihrem Konto zu belasten. Die aktuell zu bewertende Zahlung wird nicht mitgezählt (z. B. 4).

:total_charges_per​_card_number_hourly:

Wie oft im Verlauf der vergangenen Stunde versucht wurde, eine Karte in Ihrem Konto zu belasten. Die aktuell zu bewertende Zahlung wird nicht mitgezählt (z. B. 4).

:total_charges_per​_customer_daily:

Wie oft eine Kundin/ein Kunde im Verlauf der vergangenen 24 Stunden versucht hat, Ihr Konto zu belasten. Die aktuell zu bewertende Zahlung wird nicht mitgezählt (z. B. 4).

:total_charges_per​_customer_hourly:

Wie oft eine Kundin/ein Kunde im Verlauf der vergangenen Stunde versucht hat, Ihr Konto zu belasten. Die aktuell zu bewertende Zahlung wird nicht mitgezählt (z. B. 4).

:total_charges_per​_ip_address_daily:

Wie oft eine IP-Adresse im Verlauf der vergangenen 24 Stunden versucht hat, Ihr Konto zu belasten. Die aktuell zu bewertende Zahlung wird nicht mitgezählt (z. B. 4).

:total_charges_per​_ip_address_hourly:

Wie oft eine IP-Adresse im Verlauf der vergangenen Stunde versucht hat, Ihr Konto zu belasten. Die aktuell zu bewertende Zahlung wird nicht mitgezählt (z. B. 4).

:declined_charges_per​_card_number_daily:

Wie oft eine Kartennummer im Verlauf der vergangenen 24 Stunden vom Kartenaussteller in Ihrem Konto abgelehnt wurde. Die aktuell zu bewertende Zahlung wird nicht mitgezählt (z. B. 4).

:declined_charges_per​_card_number_hourly:

Wie oft eine Kartennummer im Verlauf der vergangenen Stunde vom Kartenaussteller in Ihrem Konto abgelehnt wurde. Die aktuell zu bewertende Zahlung wird nicht mitgezählt (z. B. 4).

:declined_charges_per​_customer_daily:

Wie oft eine Kundin/ein Kunde im Verlauf der vergangenen 24 Stunden vom Kartenaussteller in Ihrem Konto abgelehnt wurde. Die aktuell zu bewertende Zahlung wird nicht mitgezählt (z. B. 4).

:declined_charges_per​_customer_hourly:

Wie oft eine Kundin/ein Kunde im Verlauf der vergangenen Stunde vom Kartenaussteller in Ihrem Konto abgelehnt wurde. Die aktuell zu bewertende Zahlung wird nicht mitgezählt (z. B. 4).

:declined_charges_per​_ip_address_daily:

Wie oft eine IP-Adresse im Verlauf der vergangenen 24 Stunden vom Kartenaussteller in Ihrem Konto abgelehnt wurde. Die aktuell zu bewertende Zahlung wird nicht mitgezählt (z. B. 4).

:declined_charges_per​_ip_address_hourly:

Wie oft eine IP-Adresse im Verlauf der vergangenen Stunde vom Kartenaussteller in Ihrem Konto abgelehnt wurde. Die aktuell zu bewertende Zahlung wird nicht mitgezählt (z. B. 4).

:declined_charges_per​_email_all_time:

Die Anzahl der abgelehnten Zahlungen von dieser E-Mail in Ihrem Konto. Dies gilt für Kontozahlungen ab 2020. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:declined_charges_per​_email_weekly:

Die Anzahl der abgelehnten Zahlungen von dieser E-Mail im Verlauf der vergangenen Woche in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:declined_charges_per​_email_daily:

Die Anzahl der abgelehnten Zahlungen von dieser E-Mail im Verlauf des vergangenen Tages in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:declined_charges_per​_email_hourly:

Die Anzahl der abgelehnten Zahlungen von dieser E-Mail im Verlauf der vergangenen Stunde in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:dispute_count_on_ip_all_time:

Anzahl der betrugsbedingten Anfechtungen in Zusammenhang mit Zahlungen von dieser IP-Adresse in Ihrem Konto. Dies gilt für Kontozahlungen ab 2020. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:dispute_count_on_ip_weekly:

Anzahl der betrugsbedingten Anfechtungen in Zusammenhang mit Zahlungen von dieser IP-Adresse in Ihrem Konto im Verlauf der vergangenen Woche. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:dispute_count_on_ip_daily:

Anzahl der betrugsbedingten Anfechtungen in Zusammenhang mit Zahlungen von dieser IP-Adresse in Ihrem Konto im Verlauf des vergangenen Tages. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:dispute_count_on_ip_hourly:

Anzahl der betrugsbedingten Anfechtungen in Zusammenhang mit Zahlungen von dieser IP-Adresse in Ihrem Konto im Verlauf der vergangenen Stunde. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:email_count_for​_card_all_time:

Die Anzahl der mit dieser Karte verknüpften E-Mails aus Transaktionen in Ihrem Konto. Dies gilt für Kontozahlungen ab 2020. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:email_count_for​_card_weekly:

Die Anzahl der mit dieser Karte verknüpften E-Mails aus Transaktionen in Ihrem Konto im Verlauf der vergangenen Woche. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:email_count_for​_card_daily:

Die Anzahl der mit dieser Karte verknüpften E-Mails aus Transaktionen in Ihrem Konto im Verlauf des vergangenen Tages. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:email_count_for​_card_hourly:

Die Anzahl der mit dieser Karte verknüpften E-Mails aus Transaktionen in Ihrem Konto im Verlauf der vergangenen Stunde. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:email_count_for​_ip_all_time:

Die Anzahl der mit dieser IP-Adresse verknüpften E-Mails aus Transaktionen in Ihrem Konto. Dies gilt für Kontozahlungen ab 2020. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:email_count_for​_ip_weekly:

Die Anzahl der mit dieser IP-Adresse verknüpften E-Mails aus Transaktionen in Ihrem Konto im Verlauf der vergangenen Woche. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:email_count_for​_ip_daily:

Die Anzahl der mit dieser IP-Adresse verknüpften E-Mails aus Transaktionen in Ihrem Konto im Verlauf des vergangenen Tages. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:email_count_for​_ip_hourly:

Die Anzahl der mit dieser IP-Adresse verknüpften E-Mails aus Transaktionen in Ihrem Konto im Verlauf der vergangenen Stunde. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:name_count_for​_card_all_time:

Die Anzahl der mit dieser Karte verknüpften Namen aus Transaktionen in Ihrem Konto. Dies gilt für Kontozahlungen ab 2020. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:name_count_for​_card_weekly:

Die Anzahl der mit dieser Karte verknüpften Namen aus Transaktionen in Ihrem Konto im Verlauf der vergangenen Woche. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:name_count_for​_card_daily:

Die Anzahl der mit dieser Karte verknüpften Namen aus Transaktionen in Ihrem Konto im Verlauf des vergangenen Tages. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:name_count_for​_card_hourly:

Die Anzahl der mit dieser Karte verknüpften Namen aus Transaktionen in Ihrem Konto im Verlauf der vergangenen Stunde. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:total_charges_per​_card_number_all_time:

Die Gesamtzahl der über diese Karte abgewickelten Zahlungen in Ihrem Konto. Dies gilt für Kontozahlungen ab 2020. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:total_charges_per​_card_number_weekly:

Die Gesamtzahl der über diese Karte abgewickelten Zahlungen im Verlauf der vergangenen Woche in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:total_charges_per​_card_number_daily:

Die Gesamtzahl der über diese Karte abgewickelten Zahlungen im Verlauf des vergangenen Tages in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:total_charges_per​_card_number_hourly:

Die Gesamtzahl der über diese Karte abgewickelten Zahlungen im Verlauf der vergangenen Stunde in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:total_charges_per​_email_all_time:

Die Gesamtzahl der Zahlungen von dieser E-Mail in Ihrem Konto. Dies gilt für Kontozahlungen ab 2020. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:total_charges_per​_email_weekly:

Die Gesamtzahl der Zahlungen von dieser E-Mail im Verlauf der vergangenen Woche in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:total_charges_per​_email_daily:

Die Gesamtzahl der Zahlungen von dieser E-Mail im Verlauf des vergangenen Tages in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:total_charges_per​_email_hourly:

Die Gesamtzahl der Zahlungen von dieser E-Mail im Verlauf der vergangenen Stunde in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:total_charges_per​_ip_address_all_time:

Die Gesamtzahl der Zahlungen von dieser IP-Adresse in Ihrem Konto. Dies gilt für Kontozahlungen ab 2020. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:total_charges_per​_ip_address_weekly:

Die Gesamtzahl der Zahlungen von dieser IP-Adresse im Verlauf der vergangenen Woche in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:total_charges_per​_ip_address_daily:

Die Gesamtzahl der Zahlungen von dieser IP-Adresse im Verlauf des vergangenen Tages in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

:total_charges_per​_ip_address_hourly:

Die Gesamtzahl der Zahlungen von dieser IP-Adresse im Verlauf der vergangenen Stunde in Ihrem Konto. (Hinweis: Der obere Grenzwert ist auf <= 25 beschränkt)

Attribute, die auf Kartenangaben basieren

Eigenschaft
Beschreibung

:card_bin:

Die Bank-Identifikationsnummer (BIN) der Karte, die für die Zahlung verwendet wird. Es handelt sich um die ersten sechs Ziffern der Kartennummer (z. B. '424242').

:card_brand:

Marke der für die Zahlung verwendeten Karte. Folgende Werte werden unterstützt: 'amex' (American Express), 'visa' (Visa), 'mc' (Mastercard), 'dscvr' (Discover), 'diners' (Diners Club), 'interac' (Interac), 'jcb' (JCB) und 'cup' (UnionPay).

:card_country:

Aus zwei Buchstaben bestehender Code des Landes, in dem die Karte herausgegeben wurde (zum Beispiel 'US'). Auf dieser Seite finden Sie eine Liste der Ländercodes. Verwenden Sie den Operator IN, um mehrere Länder anzugeben: IN ('GB', 'DE', 'AE').

:card_fingerprint:

Fingerabdruck der Karte, die für die Zahlung verwendet wird. Der Fingerabdruck der Karte ist eine eindeutige Kennung für eine bestimmte Kartennummer. Sie finden diese Nummer, indem Sie zum Menüpunkt „Zahlungen“ gehen und eine Zahlung im Abschnitt „Zahlungsmethode“ untersuchen (z. B. 'VfE3rx3VlaQhS8Lp'). Achten Sie auf Groß- und Kleinschreibung.

:card_funding:

Angabe, ob es sich um eine Prepaid-, Debit- oder Kreditkarte handelt. Folgende Werte werden unterstützt: 'credit', 'debit', 'prepaid' und 'unknown'.

:card_3d_secure_support:

Umfang der 3D Secure-Unterstützung für die zur Zahlung verwendete Karte. Folgende Werte werden unterstützt: 'required', 'recommended', 'optional' und 'not_supported'.

Attribute, die auf Zahlungsdetails basieren

Eigenschaft
Beschreibung

:amount_in_xyz:

Zahlungsbetrag in der durch xyz festgelegten Währung (z. B. amount_in_usd). Geben Sie eine der folgenden unterstützten Währungen an, damit Stripe automatisch den umgerechneten Betrag für die Zahlung ermittelt: aud, brl, cad, chf, dkk, eur, gbp, hkd, inr, jpy, mxn, nok, nzd, ron, sek, sgd oder usd. Verwenden Sie keine Untereinheiten (z. B. verwenden Sie Dollar, keine Cent) (z. B. :amount_in_usd: > 250)

:average_usd_amount​_attempted_on_card_all_time:

Der durchschnittliche Betrag (in USD) der versuchten Transaktionen für diese Karte in Ihrem Konto. Dies gilt für Kontozahlungen ab 2020.

:average_usd_amount​_successful_on_card_all_time:

Der durchschnittliche Betrag (in USD) der Transaktionen, die in einer Autorisierung für diese Karte in Ihrem Konto resultiert sind. Dies gilt für Kontozahlungen ab 2020.

:risk_level:

Von Stripe festgelegte Risikostufe einer bestimmten Zahlung. Folgende Werte werden unterstützt: ‘normal’, ‘elevated’, ‘highest’ und ‘not_assessed’

:risk_score:

Von Stripe festgelegte Risikobewertung einer bestimmten Zahlung (z. B. > 50). Die Werte liegen zwischen 0 (geringstes Risiko) und 100 (höchstes Risiko). Eine Risikobewertung mit einem Wert von gleich 65 oder größer entspricht der Risikostufe „elevated“, während eine Risikobewertung mit einem Wert von gleich 75 oder größer der Risikostufe „highest“ entspricht.

:charge_description:

Mit der Zahlung übermittelte Beschreibung (z. B. „Probeunterricht“)

:is_recurring:

Gibt an, ob die Zahlung wiederkehrend ist, zum Beispiel bei Abonnements. (Es handelt sich dabei um einen booleschen Ausdruck, verwenden Sie also :is_recurring:, wenn die Aussage zutrifft, und NOT :is_recurring:, wenn die Aussage nicht zutrifft. Die Verwendung von != ist nicht möglich.)

:is_off_session:

Zeigt an, wenn eine Zahlung von Stripe Billing nicht direkt von einem Nutzer/einer Nutzerin ausgelöst wurde oder wenn die Markierung off_session bei der Bestätigung des PaymentIntents gesetzt wird. (Es handelt sich dabei um einen booleschen Ausdruck, verwenden Sie also :is_off_session:, wenn die Aussage zutrifft, und NOT :is_off_session:, wenn die Aussage nicht zutrifft. Die Verwendung von != ist nicht möglich.)

:digital_wallet:

Art der Digital Wallet, die zum Speichern von Zahlungsinformationen verwendet wird. Folgende Werte werden unterstützt: ‘android_pay’, ‘amex_express_checkout’, ‘apple_pay’, ‘masterpass’, ‘samsung_pay’, ‘unknown’, ’visa_checkout’ und ‘none’.

:destination:

Für Connect-Nutzer/innen, die Destination Charges erstellen: Zielkonto, für das die Zahlung getätigt wird (z. B. ‘acct_19KCB9AlaaEw6AgR’). Achten Sie auf Groß- und Kleinschreibung.

:is_checkout:

Gibt an, ob die Zahlung über Checkout abgewickelt wird. Diese Eigenschaft gilt nur für Zahlungen, die über die neue Version von Checkout abgewickelt werden, und erfasst keine Zahlungen über ältere Versionen von Checkout. (Es handelt sich dabei um einen booleschen Ausdruck. Verwenden Sie also :is_checkout:, wenn die Aussage zutrifft, und NOT :is_checkout:, wenn die Aussage nicht zutrifft. Die Verwendung von != ist nicht möglich.)

:is_3d_secure​_authenticated:

Gibt an, ob die Zahlung auf eine erfolgreich abgeschlossene 3D-Secure-Verifizierung mit Authentifizierung folgt. Die Authentifizierung kann entweder auf Risiko- oder auf Challenge-Grundlage erfolgen. (Es handelt sich dabei um einen booleschen Ausdruck, verwenden Sie also :is_3d_secure_authenticated:, wenn die Aussage zutrifft, und NOT :is_3d_secure_authenticated:, wenn die Aussage nicht zutrifft. Die Verwendung von != ist nicht möglich.)

:is_3d_secure:

Gibt an, ob die Zahlung von einer Quelle stammt, die 3D Secure verwendet. (Es handelt sich dabei um einen booleschen Ausdruck, verwenden Sie also :is_3d_secure:, wenn die Aussage zutrifft, und NOT :is_3d_secure, wenn die Aussage nicht zutrifft. Die Verwendung von != ist nicht möglich.)

:has_liability_shift:

Trifft zu, falls sich die Betrugshaftung für diese Zahlung geändert hat (Es handelt sich dabei um einen booleschen Ausdruck, verwenden Sie also :has_liability_shift:, wenn die Aussage zutrifft, und NOT :has_liability_shift, wenn die Aussage nicht zutrifft. Die Verwendung von != ist nicht möglich.)

:prior_fraud_disputes​_with_card_count_all_time:

Anzahl aller bisher betrugsbedingt angefochtenen Zahlungen in Ihrem Konto, die mit der für die aktuelle Zahlung verwendeten Karte in Verbindung stehen. Dazu gehören unter anderem Abfragen und Abrufe.

:prior_fraud_disputes​_with_card_count_yearly:

Anzahl aller im Verlauf des vergangenen Jahres betrugsbedingt angefochtenen Zahlungen in Ihrem Konto, die mit der für die aktuelle Zahlung verwendeten Karte in Verbindung stehen. Dazu gehören unter anderem Abfragen und Abrufe.

:seconds_since_card​_first_seen:

Die Anzahl der Sekunden, seit die bei der Zahlung angegebene Karte zum ersten Mal auf Ihrem Konto angezeigt wurde. Dies gilt für Kontozahlungen ab 2020.

:seconds_since_first_successful​_auth_on_card:

Die Anzahl der Sekunden seit der ersten erfolgreichen Authentifizierung für die mit der Zahlung verknüpfte Karte auf Ihrem Konto. Dies gilt für Kontozahlungen ab 2020.

:total_usd_amount_failed​_on_card_all_time:

Der Gesamtbetrag der Transaktionen von dieser Karte (in USD), die in Ihrem Konto fehlgeschlagen sind (gesperrt oder abgelehnt wurden). Dies gilt für Kontozahlungen ab 2020.

:total_usd_amount_successful​_on_card_all_time:

Der Gesamtbetrag der Transaktionen (in USD), die in einer Autorisierung für diese Karte in Ihrem Konto resultiert sind. Dies gilt für Kontozahlungen ab 2020.

Attribute, die auf Details von Kund/innen basieren

Eigenschaft
Beschreibung

:ip_country:

Der aus zwei Buchstaben bestehende Code, der der Geolokation der IP-Adresse auf Landesebene entspricht, von der die Zahlung stammt (zum Beispiel 'GB'). Auf dieser Seite finden Sie eine Liste der Ländercodes. Verwenden Sie den Operator IN, um mehrere Länder anzugeben: IN ('GB', 'DE', 'AE').

:ip_address:

Die IP-Adresse, von der die Zahlung stammt (z. B. '192.168.0.1', um eine einzelne IP anzugeben, oder falls Sie die Suche erweitern wollen, können Sie INCLUDES '192.168' verwenden, um sämtliche IP-Adressen mit den gleichen ersten sechs Ziffern einzubeziehen).

:is_anonymous_ip:

Gibt an, ob die IP-Adresse, von der die Zahlung stammt, ein bekannter Proxy oder ein Tor-Exitknoten ist. Diese Angabe wird täglich aktualisiert. (Es handelt sich dabei um einen booleschen Ausdruck, verwenden Sie also :is_anonymous_ip:, wenn die Aussage zutrifft, und NOT :is_anonymous_ip:, wenn die Aussage nicht zutrifft. Die Verwendung von != ist nicht möglich).

:is_my_login_ip:

Gibt an, ob die IP-Adresse, von der die Zahlung stammt, bereits zur Anmeldung bei Ihrem Stripe-Konto verwendet wurde. Diese Eigenschaft kann als Stellvertreter für „entspricht meiner IP-Adresse“ verwendet werden. (Es handelt sich dabei um einen booleschen Ausdruck, verwenden Sie also :is_my_login_ip:, wenn die Aussage zutrifft, und NOT :is_my_login_ip:, wenn die Aussage nicht zutrifft. Die Verwendung von != ist nicht möglich.)

:email:

Mit der Zahlung übermittelte E-Mail-Adresse (z. B. 'user@example.com')

:email_domain:

Mit der Zahlung übermittelte Domain der E-Mail-Adresse (z. B. 'example.com').

:is_disposable_email:

Eigenschaft gibt an, ob die mit der Zahlung übermittelte E-Mail-Adresse von einem/einer bestimmten Anbieter/in für temporäre E-Mail-Adressen stammt. Stripe pflegt eine Liste von Domains entsprechender temporärer E-Mail-Adressen, um diese Eigenschaft bereitzustellen. (Es handelt sich dabei um einen booleschen Ausdruck, verwenden Sie also :is_disposable_email:, wenn die Aussage zutrifft, und NOT :is_disposable_email:, wenn die Aussage nicht zutrifft. Die Verwendung von != ist nicht möglich.)

:billing_address:

Die vollständige angegebene Rechnungsadresse des/der Karteninhaber/in (z. B. '510 Townsend, San Francisco, CA 94110').

:billing_address_line1:

Erste Zeile der angegebenen Rechnungsadresse des/der Karteninhaber/in (in der Regel Straße und Hausnummer) (z. B. '510 Townsend').

:billing_address_line2:

Zweite Zeile der angegebenen Rechnungsadresse des/der Karteninhaber/in (in der Regel Wohnungs- oder Etagennummer) (z. B. 'Wohnung 5b').

:billing_address_postal_code:

Postleitzahl (PLZ) der angegebenen Rechnungsadresse des/der Karteninhaber/in (z. B. '94110').

:billing_address_city:

Stadt der angegebenen Rechnungsadresse des/der Karteninhaber/in (z. B. 'San Francisco').

:billing_address_state:

Bundesland/Bundesstaat/Kanton der angegebenen Rechnungsadresse des/der Karteninhaber/in (z. B. 'CA').

:billing_address_country:

Aus zwei Buchstaben bestehender Code des Landes, in dem sich die angegebene Rechnungsadresse des/der Karteninhaber/in befindet (zum Beispiel 'US'). Auf dieser Seite finden Sie eine Liste der Ländercodes. Verwenden Sie den Operator IN, um mehrere Länder anzugeben: IN ('US', 'DE', 'AE').

:seconds_since​_email_first_seen:

Die Anzahl der Sekunden, seit die bei der Zahlung angegebene E-Mail-Adresse zum ersten Mal in Ihrem Konto angezeigt wurde. Dies gilt für Kontozahlungen ab 2020.

:seconds_since​_email_first_seen_on_stripe:

Die Anzahl der Sekunden, seit die bei der Zahlung angegebene E-Mail-Adresse zum ersten Mal auf Stripe angezeigt wurde. Dies gilt für Kontozahlungen ab 2020.

:shipping_address:

Die vollständige angegebene Versandadresse (z. B. '510 Townsend, San Francisco, CA 94110').

:shipping_address_line1:

Erste Zeile der angegebenen Versandadresse (in der Regel Straße und Hausnummer) (z. B. '510 Townsend').

:shipping_address_line2:

Zweite Zeile der angegebenen Versandadresse (in der Regel Wohnungs- oder Etagennummer) (z. B. 'Wohnung 5b').

:shipping_address_postal_code:

Postleitzahl (PLZ) der angegebenen Versandadresse (z. B. '94110').

:shipping_address_city:

Stadt der angegebenen Versandadresse (z. B. 'San Francisco').

:shipping_address_state:

Bundesland/Bundesstaat/Kanton der angegebenen Versandadresse (z. B. 'CA').

:shipping_address_country:

Aus zwei Buchstaben bestehender Code des Landes, in dem sich die angegebene Versandadresse befindet (zum Beispiel 'US'). Auf dieser Seite finden Sie eine Liste der Ländercodes. Verwenden Sie den Operator IN, um mehrere Länder anzugeben: IN ('US', 'DE', 'AE').

Hier folgt ein Beispiel für die Verwendung von Standardattributen:

  • Block if :card_country: IN ('CA', 'DE', 'AE')

Mit dieser Regel wird jede Zahlung von einer in Kanada, Deutschland oder den Vereinigten Arabischen Emiraten ausgestellten Karte blockiert.

Typ 3

Metadatenattribute: Diese Attribute hängen von den Metadaten ab, die Sie an Stripe senden. Bei diesen Attributen müssen Sie Doppelpunkte vor und nach den Standardattributen verwenden, z. B. ::Customer Age::. Metadatenattribute können entweder als Strings oder als Zahlen operieren. Bei der Verwendung von Metadatenattributen als Strings wird zwischen Groß- und Kleinschreibung unterschieden.

Mit Metadaten lassen sich sehr leistungsfähige Regeln erstellen, z. B. für die Aufnahme von Zahlungen in die manuelle Prüfung anhand der SKU oder zur Erleichterung für wiederkehrende Kund/innen. Weitere Informationen zur Übergabe von Metadaten finden Sie in dieser Anleitung.

Die Metadatenattribute werden in der folgenden Struktur geschrieben:

  • ::[metadata attribute name]::[operator] [metadata_value]

Angenommen, Zahlungen haben die folgenden Schlüsselwertdaten im Metadatenfeld:

Metadatenname
Metadatenwert
Customer age
22
Item ID
5A381D
Category ID
groceries

Es kann eine Regel geschrieben werden, um Zahlungen, die die folgenden Kriterien erfüllen, in die Prüfung aufzunehmen.

  • Review if ::Customer Age:: < 30

Sie können auch Regeln schreiben, die sowohl Metadatenattribute als auch andere in diesem Dokument erwähnte unterstützte Attribute verwenden. Sie können z. B. eine Regel schreiben, die eine Zahlung nur dann in die Prüfung aufnimmt, wenn die Artikel-ID mit 5A381D übereinstimmt und der Zahlungsbetrag 1.000 USD übersteigt.

  • Review if ::Item ID:: = '5A381D' and amount_in_usd: > 1000

Metadatenattribute unterstützen auch den Operator IN zum Abgleich gegen mehrere Werte. Sie können z. B. eine Regel schreiben, die eine Zahlung in die Prüfung aufnimmt, wenn die Kategorie-ID eine der Kategorien „Lebensmittel“, „Elektronik“ oder „Kleidung“ ist.

  • Review if ::Category ID:: IN ('groceries', 'electronics', 'clothing')

Der Operator INCLUDES kann mit Regeln für Metadaten-Attribute und andere String-Attribute verwendet werden, um Teilstrings abzugleichen.
Sie können zum Beispiel eine Regel schreiben, die eine Zahlung in die Prüfung aufnimmt, wenn die Artikel-ID den String A381 enthält. Dies entspricht „A381“, „5A381D“, „A381D“, „5A381“ usw.

  • Review if ::Item ID:: INCLUDES 'A381'

Der Zugriff auf Metadaten ist auch über Kunden- und Zielobjekte möglich (wenn diese für eine bestimmte Zahlung verwendet werden). Diese Attribute werden in der folgenden Struktur geschrieben:

  • ::[customer|destination]:[metadata attribute name]::[operator][metadata_value]:

Angenommen, Sie haben eine/n Kund/in mit den folgenden Metadaten:

Metadatenname
Metadatenwert
Trusted
true

Sie könnten eine Regel schreiben, die Zahlungen immer zulässt, wenn das Metadatenfeld Trusted des Kunden/der Kundin true ist.

  • Allow if ::customer:Trusted:: = 'true'

Oder angenommen, Sie haben ein Ziel mit den folgenden Metadaten:

Metadatenname
Metadatenwert
Category
new

Sie könnten eine Regel schreiben, die eine Zahlung in die Prüfung aufnimmt, wenn das Metadatenfeld Category des Ziels new ist.

  • Review if ::destination:Category:: = 'new'

Verwendung gespeicherter Listen in Ihren Regeln (beispielsweise Erlaubt- oder Blocklisten)

Sie können in Ihren Regeln auf eine Gruppe von Werten verweisen, die Sie zuvor erstellt haben (beispielsweise Erlaubt- oder Blocklisten). Möchten Sie mehrere E-Mail-Adressen blockieren, sollten Sie eine Blockliste erstellen, anstatt mehrere Regeln für jede E-Mail zu erstellen, die Sie blockieren möchten.

Alle Listenalias, auf die in Regeln verwiesen wird, müssen mit @ beginnen. Um eine Regel zu erstellen, die sich auf eine Liste bezieht, müssen Sie der folgenden Struktur folgen:

  • {action} [attribute] in [list]

Angenommen, Sie haben eine Liste von Kartenländern, die Sie blockieren möchten. Sie könnten eine Regel mit mehreren OR-Klauseln schreiben:

  • Block if :card_country: = 'CA' OR :card_country: = 'DE' OR :card_country: = 'AE'

Sie könnten auch eine Regel mit einer Inline-Liste schreiben:

  • Block if :card_country: IN ('CA', 'DE', 'AE')

Sie können auch eine Liste der zu blockierenden Kartenländer erstellen und sie card_countries_to_block nennen. Sie können dann die Länder in die Liste aufnehmen und in einer Regel auf diese Liste verweisen:

  • Block if :card_country: in @card_countries_to_block

Eine Liste ist nicht nur übersichtlicher, sondern lässt sich auch sehr viel leichter bearbeiten und erweitern.

Händler in der EU sollten die Geoblocking-Verordnung und das darin enthaltene Verbot kennen, Zahlungen von Kund/innen mit Sitz in einem EU-Mitgliedstaat zu blockieren. Weitere Informationen zu dieser Verordnung.

Komplexe Regeln mit mehreren Bedingungen schreiben

Sie können komplexe Bedingungen erstellen, indem Sie die Grundbedingungen mit den Operatoren AND, OR und NOT verknüpfen. Alternativ können Sie auch deren symbolische Entsprechungen verwenden: &&, || bzw. !. Wie bei den Programmiersprachen C, Python und SQL unterstützt Stripe die Standard-Operatorpriorität (Operatorrangfolge). Zum Beispiel wird die komplexe Bedingung:

  • {condition_X} OR NOT {condition_Y} AND {condition_Z}

wie folgt interpretiert:

  • {condition_X} OR ((NOT {condition_Y}) AND {condition_Z})

Die Gruppierung von Unterbedingungen innerhalb komplexer Bedingungen wird ebenfalls durch Klammern unterstützt. Das vorherige Beispiel ließe sich dahingehend ändern, dass die Auswertungsreihenfolge von Unterprädikaten ausdrücklich geändert wird:

  • ({condition_X} OR (NOT {condition_Y})) AND {condition_Z}

  • {condition_X} OR NOT ({condition_Y} AND {condition_Z})

Durch die Verwendung von Klammern an verschiedenen Orten führt jede dieser komplexen Bedingungen zu unterschiedlichen Ergebnissen.

Die Funktion is_missing kann auch in OR- oder AND-Konjunktionen verwendet werden:

  • Review if is_missing(:email_domain:) OR :email_domain: IN ('yopmail.net', 'yandex.ru')

Oder Sie können die Funktion is_missing verwenden, wenn etwas nicht fehlt, in diesem Fall, wenn sie Zahlungen blockiert, wenn :ip_country: NICHT fehlt und die IP entweder aus den USA oder aus Puerto Rico stammt.

  • Block if !(is_missing(:ip_country:))AND :ip_country: IN ('US', 'PR')

Backtesting von Regeln

Generell gilt für die Regelanalyse, dass es einen Kompromiss zwischen der Verhinderung von Betrug und der Blockierung legitimer Transaktionen bzw. False Positives gibt. Das Backtesting hilft Ihnen, Regeln zu finden, die Ihrer Risikobereitschaft entsprechen oder das richtige Gleichgewicht zwischen vermiedenen Zahlungsanfechtungen und einem Anstieg von False Positives finden. Zum Abschätzen der Auswirkungen einer Regel können Sie über das Radar-Dashboard Backtesting-Kombinationen mit den Transaktionsdaten der letzten sechs Monate durchführen und gezieltere Analysen vornehmen, um zu sehen, was die Regel bewirkt hätte, wenn sie erst kürzlich in Kraft getreten wäre.

Backtesting im Dashboard

Die Definitionen dessen, was betrügerische und andere erfolgreiche Zahlungen ausmacht, unterscheiden sich je nach getestetem Regeltyp:

Blockregel

  • Angefochten, frühzeitige Betrugswarnung erhalten, oder Rückerstattung wegen Betrug: erfolgreiche Zahlungen, die angefochten oder wegen Betrug rückerstattet wurden oder erfolgreiche Zahlungen, die in die Prüfung aufgenommen und wegen Betrug angefochten oder rückerstattet wurden

  • Sonstige erfolgreiche Zahlungen: erfolgreiche Zahlungen, die nicht angefochten oder wegen Betrug rückerstattet wurden oder erfolgreiche Zahlungen, die in die Prüfung aufgenommen und nicht angefochten oder wegen Betrugs rückerstattet wurden

  • Fehlgeschlagene Zahlungsversuche: vom Aussteller abgelehnt oder von Radar gesperrt

Regel überprüfen

  • Angefochten, frühzeitige Betrugswarnung erhalten, oder Rückerstattung wegen Betrug: erfolgreiche Zahlungen, die angefochten oder wegen Betrugs rückerstattet wurden

  • Sonstige erfolgreiche Zahlungen: erfolgreiche Zahlungen, die nicht angefochten oder wegen Betrug rückerstattet wurden

  • Fehlgeschlagen oder bereits in die Prüfung aufgenommen: vom Aussteller abgelehnt, von Radar gesperrt, oder erfolgreiche Zahlungen, die in die Prüfung aufgenommen wurden (unabhängig vom Status der Zahlungsanfechtung oder Rückerstattung)

Erlaubtregel

  • Von Stripe oder benutzerdefinierten Regeln blockiert: von Radar blockierte Zahlungen

  • Angefochten, frühzeitige Betrugswarnung erhalten, oder Rückerstattung wegen Betrug: erfolgreiche Zahlungen, die angefochten oder wegen Betrug rückerstattet wurden oder erfolgreiche Zahlungen, die in die Prüfung aufgenommen und angefochten oder wegen Betrug rückerstattet wurden

  • Sonstige erfolgreiche oder von der Bank abgelehnte Zahlungen: erfolgreiche oder vom Aussteller abgelehnte Zahlungen, die nicht angefochten oder wegen Betrugs rückerstattet wurden oder erfolgreiche Zahlungen, die in die Prüfung aufgenommen und nicht angefochten oder wegen Betrugs rückerstattet wurden

Durchführung von kundenspezifischen Backtesting-Analysen

Die Backtesting-Funktion im Radar-Dashboard konzentriert sich auf die Transaktionen der letzten sechs Monate und umfasst Zahlungsanfechtungen, frühzeitige Betrugswarnungen und als betrügerisch rückerstattete Zahlungen.

Sie können eine gezieltere Analyse durchführen, wenn Sie beispielsweise Gefahr laufen, in einem Visa Betrugsüberwachungsprogramm (das sich ausschließlich auf frühzeitige Betrugswarnungen konzentriert) identifiziert zu werden, oder wenn Sie in letzter Zeit eine Häufung von Betrugsfällen von einer bestimmen IP-Region oder einem bestimmten Wallet-Typ feststellen. Dazu können Sie eine SQL-Abfrage in Sigma erstellen oder Berichte über Zahlungsdaten im Dashboard exportieren und analysieren. Das benutzerdefinierte Backtesting ermöglicht flexible Zeitrahmen (über sechs Monate hinaus) und gezieltere Analysen (z. B. können Sie sich nur auf angefochtene Zahlungen oder frühzeitige Betrugswarnungen konzentrieren). Die nachstehende Beispielabfrage führt Backtesting für frühzeitige Betrugswarnungen (EFWs) von Visa bei Transaktionen > 100 USD durch, wenn Sie annehmen, dass das Betrugsvolumen in letzter Zeit bei höheren Werten in die Höhe geschnellt ist und dass Transaktionen mit erhöhtem Wert ein Überwachungsprogrammrisiko erstellen:

Felder und Tabellen sind in Sigma verfügbar

with base as (
    select
        c.id,
        c.amount,
        c.captured,
        e.created as efw_created
    from charges c
    left join early_fraud_warnings on e.charge_id = c._id
    where card_brand = ‘visa’
    and (c.amount / 100) >= 100
    and c.captured >= dateadd(‘day’, -180, current_date)
)

select
    count(case when efw_created >= dateadd(‘day’, -60, current_date) then id else null end) as fraud_charge_count,

sum(case when efw_created >= dateadd(‘day’, -60, current_date) then amount else null end) as fraud_amount,

count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then id else null end) as false_positive_charge_count,

count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then amount else null end) as false_positive_amount

from based

Das Backtesting der letzten 60 Tage nach dem EFW-Erstellungsdatum konzentriert sich auf die aktuellsten Betrugsfälle, während das Backtesting der letzten 60 bis 120 Tage der nicht betrügerischen Verkäufe die Betrugsfälle besser erkennen lässt.

Häufige Betrugsvektoren

Die meisten betrügerischen Akteurinnen und Akteure gehen nach einem bestimmten Muster vor. Zunächst validieren sie gestohlenen Zahlungsinformationen (beispielsweise Karten). Nachdem sie sich davon überzeugt haben, dass sie funktionieren, nutzen sie diese Anmeldedaten, um Werte in Form physischer Waren für den persönlichen Gebrauch oder den Weiterverkauf (Luxusgüter oder Elektronik), Dienstleistungen für den persönlichen Gebrauch oder den Weiterverkauf (Lebensmittellieferdienste) oder Dienstleistungen und Produkte, mit denen weitere Betrugsdelikte begangen werden können (z. B. Web-Hosting-Dienste, Nachrichten-Spamming-Dienste usw.), zu erwerben.

Lesen Sie weiter, um mehr über die häufigsten Betrugsvektoren zu erfahren und wie Sie Radar-Regeln einsetzen können, um diese zu entschärfen.

Tests

Mit Kartentests überprüfen betrügerische Akteurinnen und Akteure unter Zuhilfenahme von Skripten oder manuellen Prozessen, ob die gestohlenen Kartennummern noch aktiv sind. Diese Betrugsphase dient nicht der Beschaffung physischer Waren oder Dienstleistungen, sondern der Überprüfung, ob die Karten aktiv sind. Diese Zahlungen sind in der Regel Transaktionen mit geringen Beträgen oder Autorisierungen. Die Prüfungen erfolgen in der Regel in schneller Folge und mit hoher Geschwindigkeit. Hilfreiche Attribute sind Merkmale zur Gruppierung und Geschwindigkeit, wie beispielsweise:

  • total_charges_per_customer

  • cards_per_email_address

  • cards_per_ip_address

  • total_charges_per_ip

Betrügerische Akteurinnen und Akteure versuchen in der Regel, diese zu umgehen, indem sie fingierte E-Mails versenden und unterschiedliche E-Mail-Adressen benutzen. Fortgeschrittenere Akteurinnen und Akteure maskieren IP-Adressen oder haben sogar mehrere Geräte, um individuelle Gerätedaten zu liefern. An diesem Punkt ist es wichtig, gute und typische Verhaltensweisen der Kundschaft zu kennen. Merkmale wie die E-Mail-Domain und das IP-Land können neben anderen breiteren Kategorien helfen, Transaktionen mit höherem Risiko zu erkennen. Viele betrügerische Kundinnen und Kunden nutzen beliebte E-Mail-Domains von etablierten Anbietern wie gmail.com. Möglicherweise begegnen Ihnen Domains wie gmail.comms oder gomail.co, mit denen betrügerische Akteurinnen und Akteure ihre Identität zu verschleiern versuchen. Kartenland und IP-Land können auch der Segmentierung der Kundschaft dienen und sicherstellen, dass die Transaktionen aus Gebieten stammen, die für Ihren Kundenstamm typisch sind. Transaktionen außerhalb dieser Regionen kämen dann für eine Überprüfung oder Blockierung infrage.

Eine weitere Funktionalität zur Eindämmung von Kartentests ist die Verwendung von CAPTCHA.

Sobald unser maschinelles Lernen einen Kartentest-Angriff feststellt, werden in Stripe Checkout automatisch CAPTCHA-Aufgaben gestellt. Um Kartentests einzudämmen, setzt Stripe eine Reihe automatischer und manueller Kontrollen ein, darunter Ratenbegrenzungen, Warnungen und kontinuierliche Prüfungen sowie Trainingsmodelle für Kartentests, um Angriffe automatisch aufzudecken. Diese Modelle stellen nur dann eine Aufgabe, wenn ein Kartentest-Angriff stattfindet, sodass echte Nutzer/innen fast nie ein CAPTCHA zu sehen bekommen, sondern nur Bots. Für Unternehmen, die Stripe Checkout verwenden, hat sich dadurch die Anzahl der Kartentests um stattliche 80 % verringert, ohne dass eine Auswirkung auf die Konversionsraten zu erkennen war.

Die Einführung von über Stripe-gemanagten CAPTCHAs für alle Checkout-Nutzer/innen konnte die Zahl der Kartentests um 80 % senken, mit einer Auswirkung von weniger als 0,02 % auf die Autorisierungsraten.

Außerdem können Sie benutzerdefinierte Regeln erstellen, wie z. B. „Blockieren, wenn mehr als 3 Ablehnungen von einer bestimmten IP-Adresse aus erfolgen“, um Kartentest-Angriffe zu reduzieren.

Wertextraktion

Gestohlene Kreditkarten (neues Verhalten)

Bei diesem Betrugsvektor nutzen betrügerische Akteur/innen die validierte gestohlene Karte auf ihrem persönlichen Gerät oder auf einem Gerät, das rein für Betrugszwecke verwendet wird.

Dieser Vektor wird in der Regel entweder mithilfe von skriptgesteuerten Massenangriffen oder in kleinerem Maßstab mit gezielteren Betrügereien missbraucht. Die Verwendung von Regelattributen, die die Neuheit eines Kontos auf Stripe ermitteln, wie z. B. email_first_time_seen_on_stripe, in Kombination mit risk_score und anderen Funktionen, halten brandneue Karteninhaber in Schach. Darüber hinaus schützen Geschwindigkeitsbegrenzungen für IP, E-Mails und Karten Händler vor Massenangriffen, bei denen betrügerische AkteurInnen versuchen, gestohlene Zugangsdaten so schnell wie möglich zu Geld zu machen.

Gestohlene Kreditkarten (Maskierungsverhalten)

Bei diesem Betrugsvektor nutzen betrügerische Akteur/innen die validierte gestohlene Karte auf ihrem persönlichen Gerät oder auf einem Gerät, das rein für Betrugszwecke verwendet wird oder die betrügerischen AkteurInnen haben ein Abonnement-Konto kompromittiert und sich Zugang zu den im Konto gespeicherten Kreditkarteninformationen verschafft.

Die betrügerischen Akteur/innen geben ihr Bestes, um ihre Existenz zu verschleiern durch:

  • Verwendung des gleichen Namens wie bei früheren abgeschlossenen Transaktionen

  • Verwendung der gleichen Rechnungsadresse wie bei früheren abgeschlossenen Transaktionen

  • Verwendung eines VPN, um vorzutäuschen, dass sie der ursprüngliche Karteninhaber sind.
    Mittels VPN können sie dieselbe Stadt und manchmal sogar in denselben Wohnblock vortäuschen.

  • Änderung von kleinen Details, wie E-Mail-Adresse oder Telefonnummer

  • Änderung der Lieferadresse aus früheren Transaktionen für eine physische Ware, wobei die Entfernung zwischen Rechnungs- und Lieferadresse sehr groß sein kann. Dies ist ein ungenaues Signal

Das oben beschriebene Maskierungsverhalten macht es schwierig, herauszufinden, wer die Transaktion tatsächlich vornimmt – der ursprüngliche Karteninhaber/die ursprüngliche Karteninhaberin oder betrügerische Akteur/innen, die das Konto kompromittiert haben. Das bedeutet oft, dass diese Art von Betrug sowohl für den Händler als auch für den ursprünglichen Karteninhaber/die ursprüngliche Karteninhaberin länger unentdeckt bleiben kann.

Die Strategie ist hier dieselbe: Betrügerische Akteur/innen versuchen, so viel Wert wie möglich aus den gestohlenen Anmeldedaten zu extrahieren. Regeln, die geschwindigkeitsbegrenzende Funktionen zusammen mit riskscore, cvccheck oder zip_check verwenden, können zum Schutz vor diesem Verhalten beitragen.

Analyse Ihrer Betrugsfälle als Grundlage für die Regelentwicklung

Überprüfung von Betrugsfällen

Für die Erstellung der effektivsten Regeln benötigen Sie ein umfassendes Verständnis der Betrugsaktivitäten auf Ihrem Konto. Dabei ist es wichtig, die diversen Betrugsvektortypen zu charakterisieren. Mögliche Fragen:

  • Werden Konten neu registriert und sofort für betrügerische Einkäufe unter Verwendung neuer E-Mail-Adressen und Namen von Karteninhaber/innen benutzt?

  • Greifen betrügerische Akteur/innen auf ältere Konten zu und tätigen Käufe in ungewöhnlicher Höhe?

  • Konzentrieren sich die Betrugsfälle auf bestimmte Kartennetzwerke oder Kartenländer?

  • Erfolgt ein hochfrequenter Betrugsversuch, d. h. mehrere Versuche von derselben Karte, E-Mail- oder IP-Adresse innerhalb eines kurzen Zeitraums?

Betrachtet man den hochfrequenten Betrug im obigen Screenshot, könnten Regeln,
die authorized_charges_per_card_number_hourly oder authorized_charges_per_ip_address_hourly verwenden, diesem Betrugsvektor entgegenwirken.

Weitere Best Practices

Im Folgenden finden Sie weitere Best Practices, mit denen Sie die Erstellung von Regeln in Radar optimieren können.

Bezahlvorgang
Verweisen Sie während des Bezahlvorgangs ausdrücklich auf Ihre allgemeinen Geschäftsbedingungen
Stellen Sie im Fall von Rückbuchungen einen eindeutig gekennzeichneten Screenshot bereit, der zeigt, wie die allgemeinen Geschäftsbedingungen während des Bezahlvorgangs angezeigt werden, und erläutern Sie ihre Bedeutung. Dadurch erhöhen Sie Ihre Gewinnchancen.
Prüfen Sie CVS und Postleitzahl
Ermöglicht es dem Aussteller, den/die Karteninhaber/in zu validieren. Kann die Wahrscheinlichkeit erhöhen, aus einer Anfechtung als Gewinner hervorzugehen und verbessert häufig die Autorisierungsquote. Unter Umständen sollten Sie Transaktionen bei einer fehlgeschlagenen Überprüfung blockieren.
Erfassen Sie so viele Kundeninformationen wie möglich
Durch die Erfassung dieser Angaben können Aussteller im Fall von Rückbuchungen Ihren Fall besser einschätzen, was Ihre Gewinnchancen verbessert. Dieser Vorgang gilt als Erfüllung Ihrer Sorgfaltspflicht.
Zum Goldstandard gehören: CVC und Postleitzahl, Name des/der Kund/in, E-Mail-Adresse, vollständige Rechnungsadresse, IP-Adresse, Geräteinformationen usw.
Durch die Verwendung von Stripe.js erhält Radar Informationen zur IP-Adresse und zum Gerät sowie verhaltensbezogene Informationen, die die Betrugserkennung verbessern.
Interaktionen mit Kund/innen
Karten auf der Blockliste mit Rückbuchungen in der Kategorie „betrügerisch“
Wenn ein/e Kund/in eine Zahlung wegen Betrugs anfechtet, ist die Wahrscheinlichkeit hoch, dass auch zukünftige Zahlungen angefochten werden.
Erstatten Sie verdächtige/betrügerische Zahlungen zurück
70–85 % der TC40-Transaktionen werden angefochten, und nur eine Rückerstattung des Gesamtbetrags kann eine Anfechtung verhindern.
Verwenden Sie eine eindeutige Zahlungsbeschreibung in der Abrechnung
Senkt die Zahl der Anfechtungen aufgrund nicht erkannter Abbuchungen.

Die Verwendung von Stripe.js ist wichtig

  • Binden Sie stripe.js in den gesamten Zahlungspfad ein, um eine maximale Signalisierung von Betrugsversuchen zu gewährleisten
  • Um das Beste aus Radar herauszuholen, ohne die Seitenladezeit zu beeinträchtigen, laden Sie stripe.js asynchron auf Nicht-Zahlungsseiten
  • Am einfachsten neben Google-Analytics-Skript-Tags zu setzen
  • Das komplette stripe.js Paket hat eine Größe von 29,6 kB (gzip)
  • Künftig wird radar.js getrennt von stripe.js eingebunden werden können

Fazit

Regeln können ein äußerst leistungsfähiges Tool sein, mit dem Sie Ihre Betrugsvorbeugung individuell gestalten können. Durch die Implementierung einer eigenen Logik, die sich an den in diesem Leitfaden beschriebenen Best Practices orientiert, können Sie in Radar eine Betrugsprävention erstellen, die genau auf die Anforderungen Ihres Unternehmens ausgerichtet ist.

Weitere Informationen zu Radar for Fraud Teams finden Sie hier.

Wenn Sie bereits Nutzer/in von Radar for Fraud Teams sind, sehen Sie sich die Seite Regeln in Ihrem Dashboard an, um mit der Erstellung von Regeln zu beginnen.

Weitere Hinweise

Radar für Plattformen

Sind Sie eine Plattform, die Stripe Connect verwendet? In diesem Fall gelten alle von Ihnen erstellten Regeln nur für Zahlungen, die auf dem Konto der Plattform erstellt werden (in der Connect-Sprache destination oder on-behalf-of).
Zahlungen, die direkt auf dem verbundenen Konto erstellt werden, unterliegen den Regeln dieses Kontos.

Radar für Terminal

Terminal-Zahlungen werden von Radar nicht überprüft. Das bedeutet, dass Sie sich bei der Verwendung von Terminal keine Sorgen darüber machen müssen, dass persönliche Zahlungen blockiert werden könnten, falls Sie Regeln auf der Grundlage der IP-Häufigkeit erstellen.

Startklar? Kontaktieren Sie uns oder erstellen Sie ein Konto.

Erstellen Sie direkt ein Konto und beginnen Sie mit dem Akzeptieren von Zahlungen. Unser Sales-Team berät Sie gerne und gestaltet für Sie ein individuelles Angebot, das ganz auf Ihr Unternehmen abgestimmt ist.