Regelverweis
Erfahren Sie mehr über die Struktur von Regeln und in welcher Reihenfolge Radar sie verarbeitet.
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.
Regeln verarbeiten und anordnen![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
Radar wertet jede Zahlung anhand der von Ihnen erstellten Regeln gemäß dem Aktionstyp mit der folgenden Priorisierung aus:
- 3DS anfordern: Regeln, die bei Verwendung der Payment Intents API oder von Checkout den Aussteller/die Ausstellerin request, die 3D Secure-Authentifizierung durchzuführen, sofern unterstützt. Radar wertet diese Regeln vor etwaigen Block-, Überprüfungs oder Zulassungsregeln aus.
- Allow: Regeln, die die Abwicklung einer Zahlung zulassen. Zahlungen, die unter die Zulassungsregeln fallen, werden nicht mit Sperr- oder Prüfregeln ausgewertet.
- Block: Regeln, die eine Zahlung blockieren und ablehnen. Blockierte Zahlungen werden nicht mit Prüfregeln ausgewertet.
- 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.
Regelstruktur![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
Die Struktur einer Regel besteht aus zwei Komponenten: der auszuführenden Aktion und der auszuwertenden Bedingung:
{action} if {condition}
Zusammen werden sie als Prädikat bezeichnet. 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
Aktionen![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
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
Bei Verwendung mit der Payment Intents API bestimmt diese Regel, ob Stripe den Aussteller auffordert, die 3D Secure-Authentifizierung einzusetzen. Durch die Anforderung von 3DS allein werden noch 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
Die Regel legt fest, wann eine Zahlung, die bestimmte Kriterien erfüllt, immer zugelassen werden soll, und zwar ohne die Bewertung durch Stripe oder andere übereinstimmende Regeln zu berücksichtigen. Wenn eine Zahlung die Kriterien in einer Zulassungsregel erfüllt, wickelt Stripe sie regulär ab und es werden keine weiteren Regeln ausgewertet. Der Kartenaussteller kann eine Zahlung allerdings auch dann noch ablehnen, wenn Stripe die Zahlung durchführt.
Block
Sperrregeln legen fest, 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.
Bedingungen![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
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.
oder00 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 bestimmte 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. Verwenden Sie hierfür das folgende Attribut und den folgenden Wert:
Block if :card_country: != :ip_country:
Eine Liste aller möglichen Bedingungen finden Sie unter den unterstützten Attributen.
Zeichenfolgenattribute![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
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![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
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_value]
:: [operator]
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 < 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 =
'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 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 INCLUDES
'A381'
Vorsicht
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_value]
:: [operator]
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 =
'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 =
'new'
Länderattribute![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
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![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
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, vergleicht Ihre Regel 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![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
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_
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_
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_
. 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_
ist nur dann nicht Null, wenn eine neue Zahlung mit einer bestimmten E-Mail abgewickelt wird.
Begrenzte numerische Attribute![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
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_
, 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.
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.
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![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
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![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
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:
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, sind aber noch nicht geprüft. Der Kartenaussteller der Kundin/des Kunden wird die angegebenen Daten später prüfen. |
not_ | Die Daten wurden nicht an Stripe übermittelt. |
Einige Beispielregeln:
Block if :address_line1_check: =
'fail'
Block if :cvc_check: !=
'pass'
Block if :address_zip_check: in (‘fail’,
'not_
)provided'
Die Anforderung eines strikten pass
für Regeln kann zu restriktiv sein. Beispielsweise bieten Wallets keine CVC, da sie tokenisierte Karteninformationen speichern. CVC-Prüfungen, wie 3D-Secure-Prüfungen sind daher für Zahlungsmethoden wie Apple Pay nicht verfügbar. Stripe empfiehlt die Verwendung der integrierten Regeln von Radar, bei denen diese Grenzfälle berücksichtigt werden.
Unterstützte Attribute![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
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![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
Bei der Verwendung von amount_
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_
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![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
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. Sie sollten sorgfältig abwägen, 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 eine/n gute/n Kund/in 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![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
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![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
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 |
---|---|---|---|---|---|---|---|
= | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | Ist gleich | :card_country: = |
!= | ✔︎ | ✔︎ | ✔︎ | ✔︎ | ✔︎ | Ist nicht gleich | :card_funding: != |
< | ✔︎ | 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 ( |
INCLUDES | ✔ | ✔︎ | ✔ | ✔ | Enthält die Zeichenfolge | :ip_address: INCLUDES | |
LIKE | ✔ | ✔︎ | ✔ | ✔ | 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 |
Listen![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
Ü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.
Vorsicht
EU-Händler 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.
Fehlende Attribute![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
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![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
Betrachten Sie die Regel Block if :email_domain: =
. Wenn Sie die E-Mail-Adresse einer Kundin/eines Kunden nicht erfasst haben, würde das Attribut 'definitelyfraud.
:email_domain:
fehlen, und die Regelbedingung würde erwartungsgemäß nicht auf die Zahlung zutreffen.
Betrachten Sie nun die Regel Review if :email_domain: !=
. Wenn das Attribut 'definitelysafe.
:email_domain:
fehlt, trifft auch diese Regel nicht auf die Zahlung zu. Das Ergebnis erscheint vielleicht überraschend, da ein fehlender Wert nicht das gleiche ist wie
. Hier wird 'definitelysafe.
!=
so gedeutet, dass “das Attribut einen anderen Wert als 'definitelysafe.
hat”, was das fehlende Attribut wiederum nicht erfüllt.'definitelysafe.
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.
Explizite Prüfung mit der Funktion is_ missing
![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
Wenn Sie gezielt auf das Vorhandensein eines Attributs bzw. Metadatenattributs prüfen möchten, verwenden Sie die Funktion is_
. 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( ))
Sie können die Funktion is_
auch innerhalb der Konjunktionen OR
oder AND
verwenden:
Review if is_
missing(:email_domain:) ODER :email_domain: IN ( 'yopmail.
,net' 'yandex.
)ru'
Komplexe Bedingungen![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
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_
wie folgt interpretiert:
{condition_
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_
{condition_
Durch die Verwendung von Klammern an verschiedenen Orten führt jede dieser komplexen Bedingungen zu unterschiedlichen Ergebnissen.
Gültige Bedingungen![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
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![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
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: <
(Zeichenfolgenwerte können nur die Operatoren „=” oder „!=” verwenden)'highest'
:ip_country: =
(Länderwerte müssen in einem aus zwei Buchstaben bestehenden Code angegeben werden)'Canada'
:amount_in_usd: >=
(numerische Werte müssen in Zahlen angegeben werden)'one thousand dollars'
:is_anonymous_ip: =
(boolesche Attribute werden nicht mit Operatoren oder Werten verwendet)'true'
Geschwindigkeitsregeln![](https://b.stripecdn.com/docs-statics-srv/assets/fcc3a1c24df6fcffface6110ca4963de.svg)
Viele unterstützte Attribute enthalten Invarianten für verschiedene Zeiträume (zum Beispiel daily
in total_
). Diese werden als Geschwindigkeitsregeln bezeichnet.
Attribute werden als rollierendes Zeitfenster, basierend auf Sekunden und nicht anhand eines Kalenders berechnet. daily
bedeutet beispielsweise, dass zwischen zwei Zahlungen in einem Regelattribut maximal 24 Stunden oder 86.400 Sekunden liegen dürfen, damit diese einander zugeordnet werden können.
Die Attribute sind wie folgt definiert:
stündlich
bedeutet 3.600 Sekundentäglich
bedeutet 86.400 Sekundenwöchentlich
bedeutet 604.800 Sekundenjährlich
bedeutet 31.536.000 Sekunden
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.