# Regelverweis Erfahren Sie mehr über die Struktur von Regeln und in welcher Reihenfolge Radar sie verarbeitet. Weitere Informationen dazu, wie Radar-Transaktionsregeln mit Stripe *Connect* (Connect is Stripe's solution for multi-party businesses, such as marketplace or software platforms, to route payments between sellers, customers, and other recipients) funktionieren, finden Sie unter [Radar mit Connect verwenden](https://docs.stripe.com/connect/radar.md). 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](https://docs.stripe.com/radar/rules/reference.md#supported-attributes) lassen sich auch Regeln speziell für Ihr Unternehmen einrichten. ## Verarbeitung und Sortierung von Transaktionsregeln *Radar* (Stripe Radar helps detect and block fraud for any type of business using machine learning that trains on data across millions of global companies. It’s built into Stripe and requires no additional setup to get started) 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](https://docs.stripe.com/payments/payment-intents.md) oder von [Checkout](https://docs.stripe.com/payments/checkout.md) den Aussteller *auffordern*, die *3D Secure-Authentifizierung* (3D Secure (3DS) provides an additional layer of authentication for credit card transactions that protects businesses from liability for fraudulent card payments) durchzuführen, sofern unterstützt. Radar wertet diese Regeln vor Block-, Überprüfungs- oder Zulassungsregeln aus. 1. **Allow**: Regeln, die die Abwicklung einer Zahlung *zulassen*. Zahlungen, die unter die Zulassungsregeln fallen, werden nicht mit Sperr- oder Prüfregeln ausgewertet. 1. **Block**: Regeln, die eine Zahlung *blockieren* und ablehnen. Blockierte Zahlungen werden nicht mit Prüfregeln ausgewertet. 1. **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](https://docs.stripe.com/radar/radar-for-platforms.md) 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* (3D Secure (3DS) provides an additional layer of authentication for credit card transactions that protects businesses from liability for fraudulent card payments) einzusetzen. Durch die Anforderung von 3DS allein werden nicht alle möglichen [3D Secure Ergebnisse](https://docs.stripe.com/radar/rules.md#request-3d-secure) 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 unabhängig von Ihren sonstigen Übereinstimmungsregeln zulässig ist, wenn sie bestimmte Kriterien erfüllt. Wenn eine Zahlung die Kriterien in einer Zulassungsregel erfüllt, führt Radar keine weitere Bewertung anhand anderer Regeln durch. Stripe verarbeitet die Zahlung auf normale Weise, aber der Aussteller 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](https://docs.stripe.com/radar/reviews.md). 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 oder ein Konto die Bedingung einer Regel erfüllt, wird die entsprechende Aktion ausgeführt. Eine einfache Bedingung besteht grundsätzlich aus drei Teilen: `[attribute] [operator] [value]` - **Attribut**: Das Attribut einer Zahlung (zum Beispiel der *Betrag* oder die *Zahlungsmethode*) - **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](https://docs.stripe.com/radar/rules/reference.md#supported-attributes). #### 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](https://docs.stripe.com/payments/charges-api.md#storing-information-in-metadata) oder [Konten](https://docs.stripe.com/api/accounts/object.md?api-version=2026-03-25.preview&rds=1#account_object-metadata) zugeordnet sind. Metadatenattribute 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. Payments-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: | **Metadatenname** | **Metadatenwert** | | ----------------- | ----------------- | | **Customer Age** | 22 | | **Item ID** | 5A381D | | **Category ID** | Lebensmittel | 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](https://docs.stripe.com/radar/rules/reference.md#supported-attributes) 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'` > Wenn Metadatenattribute als Zeichenfolgen verwendet werden, wird die Groß-/Kleinschreibung berücksichtigt. Stellen Sie sicher, dass die in den Regeln angegebenen Metadatenwerte genau mit den Ihren Zahlungen zugeordneten Werten übereinstimmen. **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: | **Metadatenname** | **Metadatenwert** | | ----------------- | ----------------- | | **Trusted** | wahr | 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: | **Metadatenname** | **Metadatenwert** | | ----------------- | ----------------- | | **Category** | neu | 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'` **Metadaten zum Konto-Objekt** Sie können auch auf Metadaten für das Konto zugreifen, wenn Sie Regeln erstellen, um Maßnahmen für Ihre verbundenen Konten zu ergreifen. Metadaten, die mit dem Konto verknüpft sind, verwenden die folgende Struktur: `::Konto:[Metadatenattributname]:: [Operator] [metadata_value]` Angenommen, Sie haben ein verbundenes Konto mit folgenden Metadaten: | **Metadatenname** | **Metadatenwert** | | ---------------------------- | ----------------- | | **Interne Risikoeinstufung** | hoch | Sie könnten eine Regel erstellen, die Konten zur Prüfung aufruft, wenn das Metadatenfeld für die `interne Risikobewertung` des Kontos `hoch` ist. `Review if ::account:Internal Risk Rating: = 'hoch'` #### Länderattribute Diese Attribute verwenden zur Darstellung eines Landes einen [aus zwei Buchstaben bestehenden Ländercode](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2), 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](https://en.wikipedia.org/wiki/ISO_3166-2), wie z. B. `CA` für Kalifornien in den [Vereinigten Staaten](https://en.wikipedia.org/wiki/ISO_3166-2:US), `ENG` steht für England, das zu [Großbritannien](https://en.wikipedia.org/wiki/ISO_3166-2:GB) gehört oder `L` für La Pampa in [Argentinien](https://en.wikipedia.org/wiki/ISO_3166-2:AR). 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](https://docs.stripe.com/radar/rules/reference.md#missing-attributes) 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* (The address verification system (AVS) is used to pass billing address information to issuers to verify the data if available)) und *CVC* (The card verification code (CVC) or card verification value (CVV) is a three- or four-digit number printed directly on a card used to verify the entered card number)-Attribute haben fünf mögliche Werte: | **Attributwert** | **Erklärung** | | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | `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, aber der Kartenaussteller der Kundin/des Kunden hat die angegebenen Daten noch nicht geprüft. | | `not_provided` | Die Daten wurden nicht an Stripe übermittelt. | 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* (A digital wallet is a contactless payment method that stores payment options, such as credit and debit cards, allowing customers to use a smart device to make a purchase) normalerweise keine CVC, da sie tokenisierte Karteninformationen speichern. Aus diesem Grund sind *CVC* (The card verification code (CVC) or card verification value (CVV) is a three- or four-digit number printed directly on a card used to verify the entered card number)-Prüfungen wie *3D Secure*-Prüfungen für Zahlungsmethoden wie Apple Pay nicht verfügbar. Stripe empfiehlt die Verwendung der [integrierten Regeln](https://docs.stripe.com/radar/rules.md#built-in-rules) 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](https://docs.stripe.com/radar/rules/supported-attributes.md). #### 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 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 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. | Operator | Zeichenfolge | Metadaten | Land | Bundesstaat | Numerisch | Beschreibung | Beispiel | | ------------ | ------------------- | ------------- | ------------------- | ------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------- | | **=** | ✓ Unterstützt | ✓ Unterstützt | ✓ Unterstützt | ✓ Unterstützt | ✓ Unterstützt | Ist gleich | `:card_country: = 'us'` | | **!=** | ✓ Unterstützt | ✓ Unterstützt | ✓ Unterstützt | ✓ Unterstützt | ✓ Unterstützt | Ist nicht gleich | `:card_funding: != 'prepaid'` | | **<** | - Nicht unterstützt | ✓ Unterstützt | - Nicht unterstützt | - Nicht unterstützt | ✓ Unterstützt | Kleiner als | `:amount_in_gbp: < 10.00` | | **>** | - Nicht unterstützt | ✓ Unterstützt | - Nicht unterstützt | - Nicht unterstützt | ✓ Unterstützt | Größer als | `:amount_in_usd: > 500.00` | | **<=** | - Nicht unterstützt | ✓ Unterstützt | - Nicht unterstützt | - Nicht unterstützt | ✓ Unterstützt | Kleiner als oder ist gleich | `:amount_in_eur: <= 100.00` | | **>=** | - Nicht unterstützt | ✓ Unterstützt | - Nicht unterstützt | - Nicht unterstützt | ✓ Unterstützt | Größer als oder ist gleich | `:amount_in_cad: >= 10.00` | | **IN** | ✓ Unterstützt | ✓ Unterstützt | ✓ Unterstützt | ✓ Unterstützt | ✓ Unterstützt | Gehört zur Gruppe | `:card_country: IN ('gb', 'ie')` | | **INCLUDES** | ✓ Unterstützt | ✓ Unterstützt | ✓ Unterstützt | ✓ Unterstützt | - Nicht unterstützt | Enthält die Zeichenfolge | `:ip_address: INCLUDES '192.168'` | | **LIKE** | ✓ Unterstützt | ✓ Unterstützt | ✓ Unterstützt | ✓ Unterstützt | - Nicht unterstützt | Stimmt mit dem angegebenen Muster überein. Verwenden Sie das Platzhalterzeichen `%`, um null oder eine beliebige Anzahl von Buchstaben, Ziffern oder Symbolen zu finden. | `:email: LIKE 'fraud%@stripe.com'` | ### Listen Über [Listen](https://docs.stripe.com/radar/lists.md) 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](https://docs.stripe.com/radar/lists.md#custom-lists) 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. > #### EU-Unternehmen > > EU-Unternehmen müssen die Geoblocking-Verordnung beachten, die es verbietet, Zahlungen von Kund/innen mit Wohnsitz in EU-Mitgliedsstaaten zu blockieren. [Erfahren Sie mehr über diese Verordnung](https://support.stripe.com/questions/eu-geo-blocking-regulation-changes). ### 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](https://docs.stripe.com/radar/rules/supported-attributes.md) 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](https://docs.stripe.com/disputes/prevention/card-testing.md#prevent-card-testing) oder die Aufzählung von Angriffsszenarien, wie im [Radar 101-Leitfaden](https://stripe.com/guides/radar-rules-101#rules-that-help-prevent-card-testing-or-card-cashing) beschrieben. ## See also - [Beispiele für 3DS-Regeln](https://docs.stripe.com/radar/rules.md#request-3d-secure) - [Leitfaden zum kontinuierlichen Betrugsmanagement](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data) - [Daten zu angefochtenen Zahlungen und Betrug abfragen](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md) - [Übersicht über Regeln](https://docs.stripe.com/radar/rules.md) - [Unterstützte Attribute](https://docs.stripe.com/radar/rules/supported-attributes.md)