Regelverweis

Bevor Sie eine Regel erstellen, sollten Sie sich einen Überblick darüber verschaffen, wie Regeln verarbeitet werden und welche Zahlungsattribute zur Festlegung von Bewertungskriterien verwendet werden können. Das System für maschinelles Lernen zur Betrugserkennung von Stripe kann zwar viele betrügerische Zahlungen für Sie blockieren, aber mithilfe der unterstützten Attribute lassen sich auch Regeln speziell für Ihr Unternehmen einrichten.

Verarbeitung und Sortierung von Transaktionsregeln

Radar wertet jede Zahlung anhand der von Ihnen erstellten Regeln gemäß dem Aktionstyp mit der folgenden Priorisierung aus:

1. 3DS anfordern: Regeln, die bei Verwendung der Payment Intents API oder von Checkout den Aussteller auffordern, die 3D Secure-Authentifizierung durchzuführen, sofern unterstützt. Radar wertet diese Regeln vor Block-, Überprüfungs- oder Zulassungsregeln aus.
2. Allow: Regeln, die die Abwicklung einer Zahlung zulassen. Zahlungen, die unter die Zulassungsregeln fallen, werden nicht mit Sperr- oder Prüfregeln ausgewertet.
3. Block: Regeln, die eine Zahlung blockieren und ablehnen. Blockierte Zahlungen werden nicht mit Prüfregeln ausgewertet.
4. Review: Regeln, die die Abwicklung von Zahlungen zulassen, diese aber anschließend zur Prüfung vorlegen.

Regeln desselben Aktionstyps sind nicht geordnet.

Wenn eine Zahlung die Kriterien einer Regel erfüllt, führt Radar die entsprechende Aktion aus und stellt die Auswertung ein. Wenn eine Zahlung zum Beispiel mit einer Zulassungsregel übereinstimmt, wird sie regulär abgewickelt und es werden keine Sperr- oder Prüfregeln ausgewertet, selbst wenn die Zahlung auch deren Kriterien erfüllen würde. Ein Beispiel für solche Regeln könnte wie folgt aussehen:

• Allow Zahlungen mit einem Betrag kleiner als $10
• Erlauben Sie Zahlungen, die innerhalb der USA und mit der Risikostufe normal getätigt werden
• Block Zahlungen mit der Risikostufe high
• Block Zahlungen greater than $1,000
• Überprüfen Sie Zahlungen mit Kartenausstellung outside the US

Unter Verwendung der oben aufgeführten Regeln:

• Alle Zahlungen unter 10 USD werden bearbeitet, unabhängig von ihrer Risikostufe oder ihrem Ausgabestandort. Da die erste Regel die Auszahlung erlaubt, werden keine weiteren Regeln ausgewertet.
• Eine Zahlung in Höhe von 1.500 USD, die innerhalb der USA mit einem normalen Risikoniveau getätigt wird, wird normalerweise abgewickelt, da sie die Kriterien der zweiten Regel erfüllt und daher nicht nach der Regel bewertet wird, Zahlungen über 1.000 USD zu blockieren.
• Eine Zahlung mit hohem Risiko über 1.000 USD wird blockiert, da sie die Kriterien einer der beiden Zulassungsregeln nicht erfüllt und dann beide Blockregeln auslöst, unabhängig von der Reihenfolge der Bewertung.

Verarbeitung von Kontoregeln

Mit Radar for Platforms kann Ihre Plattform Regeln für Aktionen auf Transaktions- und Kontoebene erstellen. Sie können ein Konto zur Überprüfung vorlegen, mit oder ohne Aussetzung der Auszahlungen auf dem Konto.

Regelstruktur

Die Struktur einer Regel besteht aus zwei Komponenten: der auszuführenden Aktion und der auszuwertenden Bedingung:

{action} if {condition}

Zusammen stellen sie das Prädikat dar. In der Praxis sieht eine Regel zum Blockieren aller Zahlungen über 1.000 USD folgendermaßen aus:

Block if :amount_in_usd: > 1000.00

• Die Aktion lautet Block
• Die Bedingung lautet :amount_in_usd: > 1000.00

Transaktionsaktionen

Eine Regel führt eine der vier in diesem Abschnitt beschriebenen Aktionen aus, wenn eine Zahlung ihre Kriterien erfüllt. Die Reihenfolge der folgenden Aktionstypen stellt die Priorität dar, der Radar bei der Bewertung jeder Regel folgt.

3D Secure anfordern

Wird sie mit der Payment Intents API verwendet, bestimmt diese Regel, ob Stripe den Aussteller auffordert, die 3D Secure-Authentifizierung einzusetzen. Durch die Anforderung von 3DS allein werden nicht alle möglichen 3D Secure Ergebnisse blockiert. Unabhängig von Übereinstimmungen mit dieser Regel werden die Zulassungs-, Block- und Überprüfungsregeln im Anschluss ausgewertet.

Allow

Diese Regel legt fest, wann eine Zahlung zulässig ist, die bestimmte Kriterien erfüllt, unabhängig von anderen Übereinstimmungsregeln. Wenn eine Zahlung die Kriterien in einer Zulassungsregel erfüllt, unterliegt sie keiner weiteren Bewertung der Radarregeln. Stripe verarbeitet die Zahlung auf normale Weise, aber der/die Kartenaussteller/in kann sie trotzdem ablehnen.

Block

Sperrregeln empfehlen, dass Stripe eine Zahlung immer blockieren soll. Wenn eine Zahlung auf die Kriterien einer Sperrregel zutrifft, lehnt Stripe die Zahlung ab und es werden keine weiteren Regeln ausgewertet.

Review

Sie können bestimmte Zahlungen zulassen, haben aber auch die Möglichkeit, diese genauer zu prüfen. Mit Prüfregeln können Sie Zahlungen zur Prüfung vorlegen. Diese Option ist besonders geeignet für Zahlungen, die nicht den gängigen Mustern entsprechen, wie beispielsweise größere Zahlungen oder Zahlungen aus einem Land, in das Sie nicht oft Waren versenden. Stripe wickelt diese Zahlungen zwar ab und belastet das Konto der Kundin/des Kunden, aber Sie haben zusätzlich die Möglichkeit, die Bestellung zu prüfen und auf Anzeichen von Betrug zu untersuchen.

Wenn eine bestimmte Regel ausgelöst wird, führt Radar die vorgeschriebene Aktion aus und unterbricht jede weitere Regelauswertung.

Kontoaktionen

Radar for Platforms enthält Regeln, die eine von zwei Aktionen ausführen, wenn ein Konto die Kriterien erfüllt:

• Zur Überprüfung vorlegen
• Zur Überprüfung vorlegen und Auszahlungen während der Überprüfung pausieren

Überprüfung

Ihre Plattform kann Überprüfungen für Konten veranlassen, die im Abschnitt „Überprüfungswarteschlange von Radar“ Ihrer Liste der verbundenen Konten angezeigt werden. Prüfregeln helfen Ihnen zu erkennen, wann das Konto selbst Ihrer Plattform finanziell schaden könnte.

Unterbrechung der Auszahlung (und Überprüfung)

Sie können schnell handeln, um Verluste zu vermeiden, indem Sie eine Regel festlegen, die Auszahlungen automatisch pausiert, während Sie das Konto überprüfen. Diese Prüfungen erscheinen auch in der Überprüfungswarteschlange von Radar. Wir empfehlen, zunächst Konten zur Überprüfung aufzufordern und automatische Auszahlungspausen erst dann einzusetzen, wenn Sie sicher sind, dass die Regel sich wie beabsichtigt auf die Konten auswirkt.

Bedingungen

Wenn eine Zahlung auf die Bedingung einer Regel zutrifft, wird die entsprechende Aktion ausgeführt. Eine einfache Bedingung besteht grundsätzlich aus drei Teilen:

[attribute] [operator] [value]

• Attribute: Das Attribut einer Zahlung (zum Beispiel der Betrag oder Kartentyp)
• Operator: Die Rechenoperation, die das Attribut mit dem Wert vergleicht (zum Beispiel ist größer als oder ist nicht gleich)
• Value: Das Kriterium, das verwendet werden soll (zum Beispiel 100.00 oder debit)

Wenn die Aktion und die Bedingung miteinander kombiniert werden, lautet die Struktur einer Regel folgendermaßen:

{action} if {[attribute] [operator] [value]}

Es gibt je nach Attributtyp vier Arten von Bedingungen:

• [string_attribute] [operator] [string_value]
• [country_attribute] [operator] [country_value]
• [numeric_attribute] [operator] [numeric_value]
• [boolean_attribute]

Sie können außerdem Attribute als entsprechenden Wert innerhalb einer Bedingung verwenden. Sie können beispielsweise eine Regel zum Blockieren von Zahlungen erstellen, bei denen das Ausstellungsland der Karte nicht mit dem Land übereinstimmt, in dem die Zahlung getätigt wurde:

Block if :card_country: != :ip_country:

Eine Liste aller möglichen Bedingungen finden Sie unter den unterstützten Attributen.

Zeichenfolgenattribute

Diese können aus einer beliebigen Zeichenkombination bestehen. Zeichenfolgenattribute und -werte stellen meist einen Text dar, wie beispielsweise die Marke einer Karte (zum Beispiel visa, amex) oder die Risikostufe (zum Beispiel elevated). Sie können diese in Regeln verwenden, damit nur Zahlungen aus einem bestimmten Land zugelassen oder Zahlungen mit Prepaid-Karten blockiert werden.

Metadatenattribute

Abgeleitet werden diese Attribute von den Metadaten, die Ihren Zahlungen zugeordnet sind. Metadaten können entweder als Zeichenfolgen oder als Ziffernfolgen verwendet werden. Bei Verwendung als Zeichenfolgen wird für Metadatenattribute die Groß-/Kleinschreibung berücksichtigt.

Sie können diese Attribute bei der Erstellung von Regeln für Stripe Radar verwenden. So lassen sich Regeln anhand benutzerdefinierter Unternehmensattribute erstellen, die Sie über das Ihren Zahlungen zugeordnete Metadatenfeld an Stripe übergeben haben.

Metadatenattribute werden nach folgender Struktur geschrieben:

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

Angenommen, es liegen Zahlungen mit den folgenden im Metadatenfeld gespeicherten Schlüsselwertdaten vor:

Sie können eine Regel erstellen, um mit den folgenden Kriterien übereinstimmende Zahlungen zur Prüfung vorzulegen.

Review if ::Customer Age:: < 30

Sie können außerdem Regeln definieren, die sowohl Metadatenattribute als auch andere in diesem Dokument erwähnte unterstützte Attribute verwenden. Beispielsweise können Sie eine Regel erstellen, die eine Zahlung nur dann zur Prüfung vorlegt, wenn die Item ID mit 5A381D übereinstimmt und der Zahlungsbetrag 1.000 USD überschreitet.

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

Metadatenattribute unterstützen auch den Operator IN und können so mit mehreren Werten übereinstimmen. Beispielsweise lässt sich eine Regel definieren, die eine Zahlung dann zur Prüfung vorlegt, wenn die Category ID der Kategorie Lebensmittel, Elektronik oder Bekleidung entspricht.

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

Sie können den Operator INCLUDES mit Regeln für Metadatenattribute und andere Zeichenfolgeattribute verwenden, um Teilzeichenfolgen zu berücksichtigen. Beispielsweise lässt sich eine Regel erstellen, die eine Zahlung dann zur Prüfung vorlegt, wenn die Item ID die Zeichenfolge A381 enthält. Dies trifft unter anderem auf A381, 5A381D, A381D und 5A381 zu.

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

Metadaten in Kunden- und Zielobjekten

Sie können zudem auf Metadaten zu Kunden- und Zielobjekten zugreifen (sofern diese für eine bestimmte Zahlung verwendet werden). Diese Attribute haben die folgende Struktur:

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

Angenommen, Sie haben eine Kundin/einen Kunden mit folgenden Metadaten:

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

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

Oder wenn Sie ein Ziel mit den folgenden Metadaten haben:

Sie können eine Regel erstellen, die eine Zahlung zur Prüfung vorlegt, wenn das Metadatenfeld Category des Ziels new ist.

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

Länderattribute

Diese Attribute verwenden zur Darstellung eines Landes einen aus zwei Buchstaben bestehenden Ländercode, wie zum Beispiel US für die Vereinigten Staaten, GB für das Vereinigte Königreich oder AR für Argentinien. Länderattribute funktionieren wie Zeichenfolgenattribute, nur dass der Wert ein Ländercode sein muss.

Bundesstaatenattribute

Diese Attribute verwenden zur Darstellung eines Bundesstaates oder einer untergeordneten Verwaltungseinheit eines Landes ISO-Codes, wie z. B. CA für Kalifornien in den Vereinigten Staaten, ENG steht für England, das zu Großbritannien gehört oder L für La Pampa in Argentinien. Wir lassen den aus zwei Buchstaben bestehenden Ländercode im ISO-Code des Bundesstaates weg. Wenn Sie also Transaktionen aus Kalifornien blockieren möchten, vergleichen Sie das Bundesstaat-Attribut mit CA.

Blockieren if :ip_state: = 'CA'

Bundesstaatattribute funktionieren genauso wie Zeichenfolgenattribute, nur dass der Wert ein ISO-Code sein muss.

Numerische Attribute

Da diese Attribute ausschließlich Zahlen enthalten, unterstützen sie mehr Operatoren als Zeichenfolgenattribute oder -werte. Ein Beispiel für ein numerisches Attribut ist der Betrag einer Zahlung. Sie können eine Regel zum Ausführen einer Aktion erstellen, wenn der Betrag höher, niedriger, gleich oder nicht gleich dem von Ihnen angegebenen Betrag ist.

Bei numerischen Attributen, bei denen es sich um Zählungen über Zeitfenster handelt, wird eine aktuell abgewickelte Zahlung nicht berücksichtigt. Zum Beispiel stellt das Attribut total_charges_per_customer_hourly die Anzahl der erfolgten Abbuchungsversuche von einer/einem bestimmten Kund/in in der letzten Stunde dar. Das heißt, dass beim ersten Abbuchungsversuch in einer bestimmten Stunde für eine/n Kund/in das Attribut total_charges_per_customer_hourly den Wert 0 hat. Beim zweiten Abbuchungsversuch innerhalb der gleichen Stunde hat es den Wert 1 und so weiter.

Attribute des Typs „Zeit seit dem ersten Sehen“ berücksichtigen auch nicht die Zahlung, die Sie gerade bearbeiten. Beispielsweise fehlt bei einer Zahlung ohne E-Mail der Wert für seconds_since_email_first_seen. Gleiches gilt für Zahlungen mit E-Mails, die nie zuvor in Ihrem Konto gesehen wurden (da wir die Zahlung, die gerade abgewickelt wird, nicht berücksichtigen, ist dies im Grunde das gleiche Verhalten wie im ersten Beispiel). Weitere Details zu fehlenden Werten finden Sie unten. Das Feld seconds_since_email_first_seen ist nur dann nicht Null, wenn eine neue Zahlung mit einer bestimmten E-Mail abgewickelt wird.

Begrenzte numerische Attribute

Begrenzte numerische Attribute sind den oben beschriebenen Attributen ähnlich. Zum Beispiel berücksichtigen sie nicht die Zahlung, die Sie aktuell verarbeiten. Der Unterschied besteht darin, dass die verfügbaren Werte für begrenzte numerische Werte bei einem bestimmten Wert begrenzt werden.

Nehmen Sie als Beispiel authorized_charges_per_email_hourly, was die Anzahl der vorangegangenen Zahlungen darstellt, die für die E-Mail in der letzten Stunde auf Ihrem Konto autorisiert wurden. Angenommen, die Grenze liegt bei 5. Beim ersten Ladeversuch in der letzten Stunde mit der E-Mail jenny.rosen@example.com hat der Zähler den Wert 0. Bei nachfolgenden Ladeversuchen in derselben Stunde steigen die Zählerwerte. Nach der Autorisierung des 6. Ladevorgangs innerhalb einer Stunde von jenny.rosen@example.com hört der Zähler mit der Inkrementierung auf und verbleibt bei 5, obwohl in der letzten Stunde in in Wahrheit 6 Ladeversuche unternommen wurden.

Wenn versucht wird, den Zähler über der dem Grenzwert zu inkrementieren, schließen wir ältere Werte aus und ersetzen diese durch neue Werte. Ein Zähler mit der Begrenzung 3 wurde beispielsweise mit 3 Zahlungen ausgefüllt. Der Zähler lässt sich veranschaulichen, wenn Sie eine Liste von Zeitstempeln führen, die die Ankunftszeit von Zahlungen darstellen, zum Beispiel [10, 20, 30]. Wenn eine Zahlung zum Zeitpunkt 50 eintrifft, sieht der Zähler nun folgendermaßen aus: [20, 30, 50].

Boolesche Attribute

Ein boolesches Attribut gibt an, ob ein bestimmtes Attribut wahr ist. Anders als Zeichenfolgen- oder numerische Attribute haben boolesche Attribute keine Operatoren oder Werte. Sie können ein boolesches Attribut zum Blockieren von Zahlungen verwenden, die mit einer temporären E-Mail-Adresse getätigt wurden, oder Zahlungen zur Prüfung vorlegen, die über eine anonyme IP-Adresse erfolgt sind.

Post-Authorization-Attribute

Bei einem Post-Authorization-Attribut (zum Beispiel :cvc_check:, :address_zip_check: oder :address_line1_check:) muss Stripe im Rahmen der Autorisierung Daten mit Kartenausstellern austauschen. Der Kartenaussteller gleicht diese Daten mit den dort vorliegenden Daten des/der Karteninhabers/in ab und prüft, ob eine Übereinstimmung vorliegt. Regeln mit Nachautorisierungsattributen werden nach Regeln ausgeführt, die keine Nachautorisierungsattribute verwenden. (Dies hat keine Auswirkung darauf, ob eine Zahlung blockiert wird, allerdings kann es beeinflussen, welche Regel die Zahlung blockiert.)

Wenn Sie in einer Regel ein Post-Authorization-Attribut verwenden, kann aus dem Kontoauszug des Kundin/Ihres Kunden vorübergehend eine Autorisierung hervorgehen, selbst wenn die Zahlung letztendlich blockiert wird. Die Autorisierung wird in der Regel nach ein paar Tagen nicht mehr angezeigt.

Die Adress- (AVS) und CVC-Attribute haben fünf mögliche Werte:

Einige Beispielregeln:

• Block if :address_line1_check: = 'fail'
• Block if :cvc_check: = 'fail'
• Block if :address_zip_check: in (‘fail’, 'not_provided')

Die Anforderung eines strikten pass von Regeln kann zu restriktiv sein. Beispielsweise bieten Wallets normalerweise keine CVC, da sie tokenisierte Karteninformationen speichern. Aus diesem Grund sind CVC-Prüfungen wie 3D Secure-Prüfungen für Zahlungsmethoden wie Apple Pay nicht verfügbar. Stripe empfiehlt die Verwendung der integrierten Regeln von Radar, die diese Grenzfälle berücksichtigen.

Unterstützte Attribute

Eine vollständige Liste der Attribute, die Sie auf Ihre Regeldefinitionen anwenden können, finden Sie in der Liste aller unterstützten Attribute.

Umgerechnete Beträge

Bei der Verwendung von amount_in_xyz ermittelt Stripe automatisch den umgerechneten Betrag einer Zahlung, wenn geprüft wird, ob der Betrag Ihren gewählten Kriterien entspricht. Wenn Sie beispielsweise eine Regel mit amount_in_usd erstellen, um alle Zahlungen über mehr als 1.000 USD zu blockieren, blockiert Stripe eine Zahlung mit einem niedrigeren Nennbetrag in einer anderen Währung (zum Beispiel 900 GBP), wenn ihr entsprechender umgerechneter Wert 1.000 USD überschreitet.

„Dies gilt für Kontozahlungen ab 2020“ in der Praxis

Die Beschreibungen einiger Regelattribute enthalten die Formulierung „Dies gilt für Kontozahlungen ab 2020“. Dies bedeutet, dass die Regel eine Karte, mit der zuletzt im Jahr 2019 Transaktionen mit Ihrem Unternehmen durchgeführt wurden, genauso behandelt wie eine Karte, die für Ihr Unternehmen neu ist. Wägen Sie ab, was dies im Kontext Ihres Unternehmens und Ihrer Regeln bedeutet, da es zu kontraintuitivem Verhalten führen könnte. Wenn Sie beispielsweise eine Regel erstellen, um Zahlungen mit hohen Beträgen von neuen Karten zu blockieren, könnte dies zur Folge haben, dass Sie einen guten Kunden/eine gute Kundin sperren, der/die seit 2019 keinen Kauf mehr getätigt hat.

„Dieses Attribut umfasst nur Kundenobjekte im Live-Modus, die am/in der/im vergangenen <week, year> mit Ihrem Konto interagiert haben. Diese Daten werden maximal alle 72 Stunden aktualisiert.“ in der Praxis

Die Beschreibungen einiger Regeleigenschaften enthalten die Sätze „Dieses Attribut umfasst nur Kundenobjekte im Live-Modus, die am/in der/im vergangenen <week, year> mit Ihrem Konto interagiert haben. Diese Daten werden maximal alle 72 Stunden aktualisiert.“ Dies bedeutet, dass Kundenobjekte im Live-Modus, die in der letzten Woche oder im letzten Jahr in Ihrem Konto erstellt, belastet oder aktualisiert wurden, in diese Zählungen aufgenommen werden. Die Zählung wird jedoch nicht sofort aktualisiert und es kann bis zu 72 Stunden dauern, bis sie im System weitergegeben wird, obwohl diese Zähler oft vor Ablauf der 72 Stunden aktualisiert werden.

Operatoren

Der Operator einer Bedingung bezeichnet den Vergleich zwischen dem Zahlungsattribut und dem von Ihnen angegebenen Wert. Es stehen je nach Art des verwendeten Attributs verschiedene Operatoren zur Verfügung.

Listen

Über Listen können Sie auf eine Gruppe von Werten in Ihren Regeln verweisen. Alle Aliasnamen aus Listen, auf die in Regeln verwiesen wird, müssen mit @ beginnen. Um eine Regel zu erstellen, die auf eine Liste verweist, verwenden Sie die folgende Struktur:

{action} [attribute] in [list]

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

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

Alternativ können Sie eine Regel mit einer Inline-Liste erstellen:

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

Sie können außerdem eine Liste zu blockierender Kartenländer erstellen, die den Namen card_countries_to_block erhält. Anschließend können Sie Länder Ihrer Wahl hinzufügen und in einer Regel auf diese Liste verweisen:

Block if :card_country: in @card_countries_to_block

Wenn Sie in einer Regel auf eine Liste verweisen, können Sie eine große Zahl von Elementen gleichzeitig bearbeiten und müssen nicht viele einzelne Regeln pflegen.

Fehlende Attribute

Die meisten Regelbedingungen beziehen sich auf Attribute, die bei jeder Zahlung festgelegt werden, wie zum Beispiel das Attribut :card_country: (das bei jeder Kartenzahlung festgelegt wird) oder ein Metadatenattribut, das immer mit Ihren Zahlungsanforderungen übermittelt wird. In gewissen Szenarien kann zum Beispiel auch ein Attribut fehlen:

• Sie haben verschiedene Bezahlvorgänge auf Ihrer Website, und einige davon erfassen keine E-Mail-Adressen von Kund/innen.

• Sie verwenden Stripe.js erst seit Kurzem. Aus diesem Grund ist :ip_country: bei neuen, aber nicht bei vergangenen Zahlungen verfügbar (nach denen wir bei der Vorschau von Regeln suchen).

• Bei einigen Ihrer Zahlungen führt ein Fehler in Ihrer Integration dazu, dass ein erwarteter Metadatenschlüssel nicht festgelegt wird.

So werten Regelbedingungen fehlende Attribute aus

Betrachten Sie die Regel Block if :email_domain: = 'definitelyfraud.com'. Wenn Sie die E-Mail-Adresse einer Kundin/eines Kunden nicht erfasst haben, existiert das Attribut :email_domain: nicht und die Regelbedingung trifft nicht auf die Zahlung zu.

Betrachten Sie nun die Regel Review if :email_domain: != 'definitelysafe.com'. Wenn das Attribut :email_domain: fehlt, trifft auch diese Regel nicht auf die Zahlung zu. Es mag wie eine Übereinstimmung erscheinen, da kein Wert 'definitelysafe.com' ist. Hier wird != 'definitelysafe.com' jedoch so gedeutet, dass „das Attribut einen anderen Wert als 'definitelysafe.com' hat“, was das fehlende Attribut wiederum nicht erfüllt. Fehlende Attributinformationen werden auch bei Fehlen des Operators NOT übernommen, sodass die Regel Review if NOT (:email_domain: = 'definitelysafe.com') ebenfalls nicht auf die Zahlung zutrifft, wenn das Attribut :email_domain: fehlt.

Boolesche Attribute sind „false“ statt „fehlend“, wenn die Transaktion nicht über das Attribut verfügt. Zum Beispiel ist :is_new_card_on_customer: „false“ statt „fehlend“ für ACH- und SEPA-Transaktionen.

Grundsätzlich gilt: Jeder Vergleich (zum Beispiel =, !=, >, <) einer fehlenden Funktion mit einem anderen statischen Wert bzw. einer anderen statischen Funktion (ob fehlend oder vorhanden) gibt immer den Wert „false“ zurück. Bei Nutzung des Operators NOT mit einem Vergleich, der eine fehlende Funktion enthält, wird immer „false“ zurückgegeben.

Explizite Prüfung mit der Funktion is_missing

Wenn Sie gezielt auf das Vorhandensein eines Attributs bzw. Metadatenattributs prüfen möchten, verwenden Sie die Funktion is_missing. Stellen Sie dieser Funktion das Attribut oder den Metadatenschlüssel bereit, falls nicht vorhanden.

Sie können beispielsweise eine Regel erstellen, um alle Zahlungen abzugleichen, bei denen Sie keinen Zugriff auf die E-Mail-Adresse der Kundin/des Kunden haben:

• Review if is_missing(:email_domain:)

Alternativ können Sie eine Regel erstellen, um alle Zahlungen abzugleichen, die ein bestimmtes Metadatenattribut haben:

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

Sie können die Funktion is_missing auch innerhalb der Konjunktionen OR oder AND verwenden:

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

Komplexe Bedingungen

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 Zusammenfassung von Teilbedingungen innerhalb komplexer Bedingungen wird durch die Verwendung von Klammern ermöglicht. So kann etwa das vorherige Beispiel angepasst werden, um die Auswertungsreihenfolge von Teilprädikaten explizit zu ändern:

({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.

Gültige Bedingungen

Die folgenden Bedingungen sind Beispiele für die richtige Verwendung von Attributen und einem unterstützten Operator:

• :card_brand: = 'amex'
• :card_country: != 'US'
• :amount_in_usd: >= 1000.00
• :is_anonymous_ip:

Ungültige Bedingungen

Beim Erstellen einer Regel erhalten Sie von Radar eine Rückmeldung, sobald Sie versuchen, eine ungültige Bedingung zu verwenden. Zur Verdeutlichung finden Sie nachfolgend Beispiele für ungültige Bedingungen, bei denen der Wert für ein Attribut oder der verwendete Operator nicht unterstützt wird:

• :risk_level: < 'highest' (Zeichenfolgenwerte können nur die Operatoren „=” oder „!=” verwenden)
• :ip_country: = 'Canada' (Länderwerte müssen in einem aus zwei Buchstaben bestehenden Code angegeben werden)
• :amount_in_usd: >= 'one thousand dollars' (numerische Werte müssen in Zahlen angegeben werden)
• :is_anonymous_ip: = 'true' (boolesche Attribute werden nicht mit Operatoren oder Werten verwendet)

Geschwindigkeitsregeln

Viele unterstützte Attribute enthalten Invarianten für verschiedene Zeiträume (zum Beispiel daily in total_charges_per_email_daily). Diese werden als Geschwindigkeitsregeln bezeichnet.

Stripe berechnet Attribute mithilfe von Bucket-Erhöhungen. Die Länge der Erhöhungen variiert je nach Attributintervall. Dies bedeutet, dass die Geschwindigkeit für jedes Attribut Daten enthalten kann, die innerhalb des Intervalls sowie eines Buckets aufgetreten sind. Zum Beispiel könnte ein stündliches Attributintervall 3900 Sekunden (eine Stunde und fünf Minuten) der aktuellen Transaktion betragen, da das Intervall Fünf-Minuten-Buckets verwendet.

Die Attribute sind wie folgt definiert:

• stündlich bedeutet bis zu 3.900 Sekunden (5-Minuten-Buckets)
• täglich bedeutet bis zu 90.000 Sekunden (1-stündige Buckets)
• wöchentlich bedeutet bis zu 608.400 Sekunden (1-stündige Buckets)
• jährlich bedeutet bis zu 31.622.400 Sekunden (1-Tages-Buckets)
• all_time enthält Daten aus 5 Jahren mit einer Geschwindigkeit von bis zu 31.622.400 Sekunden (1-Tages-Buckets)

Ein gängiges Anwendungsszenario für diese Attribute ist die Reduzierung von Kartentests oder die Aufzählung von Angriffsszenarien, wie im Radar 101-Leitfaden beschrieben.