Radar for Fraud Teams: basisinfo over de regels

In dit whitepaper wordt ingegaan op diverse onderwerpen die verband houden met Radar-regels, waaronder meer dan 100 Radar-regels die je kunt gebruiken en beste werkwijzen op het gebied van backtesting, het schrijven van regels en meer.

Radar
Radar

Fight fraud with the strength of the Stripe network.

Learn more 
  1. Inleiding
  2. Het belang van de regelvolgorde en -hiërarchie
  3. Spiekbriefje regeltaal
    1. Regels schrijven in gewone taal
  4. Veelgebruikte regels in Radar
    1. Regels die het testen van creditcards of geld opnemen via creditcards helpen voorkomen
    2. Regels om fraude met SKUs te voorkomen waarvan bekend is dat ze risicovol zijn
    3. Regels om misbruik van proefabonnementen met prepaidkaarten te voorkomen
  5. Fraude analyseren om het opstellen van regels te leiden
    1. Fraude-evaluaties
    2. Meer inzicht krijgen in factoren die fraude veroorzaken
  6. Drie soorten attributen om regels te maken
    1. Type 1
    2. Type 2
    3. Attributen op basis van frequentie
    4. Attributen op basis van kaartgegevens
    5. Attributen op basis van betaalgegevens
    6. Attributen op basis van klantgegevens
    7. Type 3
  7. Opgeslagen lijsten (bijv. toelatingslijsten, blokkeerlijsten) in je regels gebruiken
  8. Complexe regels schrijven met meerdere voorwaarden
  9. Regels voor backtesting
    1. Backtesting in het Dashboard
    2. Uitvoering van backtesting-analyses op maat
  10. Veelvoorkomende fraudevectoren
    1. Testen
    2. Waarde-extractie
  11. Andere aanbevolen werkwijzen
    1. Belang van het gebruik van Stripe.js
  12. Conclusie
    1. Andere opmerkingen

De standaardregels van Stripe maken gebruik van machine-learning om een aanzienlijk percentage van de frauduleuze betalingen te detecteren en blokkeren. Voor bedrijven die meer controle willen over betalingen die moeten worden gecontroleerd, toegestaan of geblokkeerd, zijn regels nuttige tools voor fraudepreventie op maat.

In dit whitepaper wordt ingegaan op diverse onderwerpen die verband houden met Radar-regels, waaronder meer dan 100 Radar-regels die je kunt gebruiken en beste werkwijzen op het gebied van backtesting, het schrijven van regels en meer.

Laten we aan de slag gaan.

Het belang van de regelvolgorde en -hiërarchie

De volgorde waarop regels worden weergegeven op je Radar-pagina doet ertoe. Elke betaling wordt geëvalueerd op basis van de regels die je hebt geformuleerd en op onderstaande volgorde:

  1. Vereist 3DS: regels die 3D Secure-authenticatie vereisen bij gebruik met de Payment Intents-API of Checkout. Los van het resultaat van de toepassing van deze regel, worden erna nog toelatings-, blokkeer- en controleregels geëvalueerd.
  2. Toelatingsregels: regels die toestaan dat een betaling wordt verwerkt. Toelatingsregels moeten zorgvuldig worden toegepast, want ze overschrijven alle andere regels, met uitzondering van 3DS-regels, inclusief de machine-learningmodellen van Stripe. Zij moeten daarom voorzichtig worden gebruikt. Alleen handelaren die meer dan $ 100.000 hebben verwerkt, kunnen toelatingsregels schrijven.
  3. Blokkeerregels: regels die een betaling blokkeren en weigeren. Als een betaling wordt geweigerd, wordt deze niet meer geëvalueerd aan de hand van controleregels.
  4. Controleregels: betalingen die wel worden verwerkt en waarbij het bedrag dus bij de klant in rekening wordt gebracht, maar die worden gesignaleerd zodat je ze nog eens goed onder de loep kunt nemen.

Laten we de volgende regels als voorbeeld nemen om dit in de praktijk toe te passen. Alle betalingen van minder dan $ 10 worden verwerkt. Dit komt doordat de eerste regel de betaling toelaat. Er worden dus verder geen regels meer geëvalueerd. Een betaling van $ 1500 vanuit de VS met een normaal risiconiveau wordt op basis van dezelfde principes ook toegelaten, ondanks de regel dat betalingen boven de $ 1000 geblokkeerd moeten worden. Dit komt door de tweede regel op de lijst, die betalingen vanuit de VS met een normaal risiconiveau toelaat. Zodra een bepaalde regel wordt geactiveerd, worden er geen andere regels meer geëvalueerd.

  • 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

Spiekbriefje regeltaal

Regels zijn vergelijkbaar met SQL en er zijn verschillende operators die je kunt gebruiken afhankelijk van het soort gegevens dat je gebruikt om je regel te maken. Hier heb je een spiekbriefje.

Operator
Tekenreeks
Metadata
Land
Numerieke waarde
Beschrijving
Voorbeeld
=
Gelijk aan

:card_country: = 'us'

!=
Niet gelijk aan

:card_funding: != 'prepaid'

<
Kleiner dan

:amount_in_gbp: < 10.00

>
Groter dan

:amount_in_usd: > 500.00

<=
Kleiner dan of gelijk aan

:amount_in_eur:<= 100.00

>=
Groter dan of gelijk aan

:amount_in_cad: >= 10.00

IN
Is in de groep

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

INCLUDES
Bevat de tekenreeks

:ip_address: INCLUDES '192.168'

LIKE
Komt overeen met het opgegeven patroon

:email: LIKE 'fraud%@stripe.com'

Als je expliciet wilt controleren of een kenmerk of een metadatakenmerk daadwerkelijk bestaat, gebruik dan niet de operator !=, maar de functie is_missing. Voer in deze functie het kenmerk of de metadatasleutel in die mogelijk ontbreekt. Je kunt bijvoorbeeld een regel schrijven om alle betalingen te vinden waar je geen toegang hebt tot het e-mailadres van een klant:

  • Review if is_missing(:email_domain:)

Je kunt ook een regel schrijven om alle betalingen te vinden waar het e-mailadres van een klant NIET ontbreekt:

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

Regels schrijven in gewone taal

Als je op een makkelijkere manier regels wilt schrijven of als je niet zeker weet welke kenmerken je moet gebruiken voor een bepaald fraudescenario, kun je je vragen in gewone taal aan de AI-assistent van Radar stellen. Deze zet ze om in regels met de syntaxis van Radar. Je kunt ook rechtstreeks vanuit Radar Assistant een backtest uitvoeren op de regel, zodat je kunt zien wat de uitkomst in het verleden zou zijn geweest voordat je de regel implementeert.

Veelgebruikte regels in Radar

Dit is een niet uitputtende lijst van veelgebruikte Radar-regels gebaseerd op verschillende doeleinden.

Regels die het testen van creditcards of geld opnemen via creditcards helpen voorkomen

Block if :total_charges_per_ip​_address_hourly: > 1

Deze regel is handig bij het testen van betaalkaarten. Betalingen worden geblokkeerd als een IP-adres meerdere keren op je account is geautoriseerd.

Block if :blocked_charges_per_ip​_address_hourly: > 1

Als je het testen van betaalkaarten nog strikter wilt voorkomen, gebruik je deze regel in combinatie met :total_charges_per_ip_address_hourly:

Block if :total_charges_per​_card_number_hourly: > 1

Deze regel is handig bij het verzilveren van kaartbetalingen. Betalingen worden geblokkeerd als een kaartnummer in het afgelopen uur meerdere keren op je account is geautoriseerd.

Block if :blocked_charges_per_card​_number_hourly: > 1

Als je het verzilveren van kaartbetalingen nog strikter wilt voorkomen, gebruik je deze regel in combinatie met :total_charges_per_card_number_hourly:

Block if :address_zip_check: != 'pass'

Als je deze regel wilt gebruiken moet je postcodes of ZIP-codes verzamelen in je afrekenformulier. Betalingen worden geblokkeerd als de verstrekker van de betaalkaart de opgegeven postcode of ZIP-code niet kan valideren met hun eigen betaalkaartgegevens.

Block if :cvc_check:: != 'pass'

Als je deze regel wilt gebruiken moet je CVC-codes verzamelen in je afrekenformulier. Betalingen worden geblokkeerd als de verstrekker van de betaalkaart de opgegeven CVC- of CVV-code niet kan valideren met hun eigen betaalkaartgegevens.

Regels om fraude met SKU's te voorkomen waarvan bekend is dat ze risicovol zijn

Deze regel vereist metadata of er moet SKU-informatie worden doorgegeven in de beschrijving van de betaling. Deze betalingen worden wel verwerkt en het bedrag wordt in rekening gebracht bij de klant. Maar ze worden gesignaleerd zodat je ze nog eens goed onder de loep kunt nemen.

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

Stel dat je een groentewinkel runt en metadata naar ons hebt gestuurd met de SKU-categorie. Je hebt opgemerkt dat bestellingen met artikelen die zijn getagd met de SKU-categorie 'persoonlijke hygiëne' of 'babyvoeding' riskanter zijn. Met deze regel worden dergelijke bestellingen in de lijst Handmatig controleren op je Stripe-dashboard geplaatst, zodat je ze extra kunt controleren. Let op: tenzij je de bestelling handmatig annuleert, worden ze gewoon verwerkt en krijgt de klant een factuur toegezonden.

Review if :charge_description: = 'Trial class'

Stel dat je twee producten verkoopt ('Proefles' en 'Pakket met 10-lessen') en je stuurt Stripe de productnaam als beschrijving voor de betaling. Met deze regel worden alle bestellingen waarbij de beschrijving exact overeenkomt met 'Proefles' in de lijst Handmatig controleren op je Stripe-dashboard geplaatst, zodat je ze extra kunt controleren. Let op: tenzij je de bestelling handmatig annuleert, worden ze gewoon verwerkt en krijgt de klant een factuur toegezonden."

Regels om misbruik van proefabonnementen met prepaidkaarten te voorkomen

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

Stel dat je als winkelier proefversies van producten aanbiedt die mensen thuis kunnen uitproberen. Je merkt een plotselinge toename in oplichters met prepaidkaarten waarbij de betaling later niet kan worden afgeschreven. Met deze regel blokkeer je bestellingen die niet met een creditcard of bankpas worden betaald.

Fraude analyseren om het opstellen van regels te leiden

Fraude-evaluaties

Voor het schrijven van effectieve regels is het belangrijk dat je een goed inzicht krijgt in de gepleegde fraude. Het is belangrijk om de verschillende soorten aanwezige fraudevectoren te duiden. Vragen die je daarbij kunt stellen:

  • Doen accounts direct na aanmelding frauduleuze aankopen met nieuwe e-mailadressen en namen van kaarthouders?

  • Gebruiken fraudeurs verouderde accounts en doen ze aankopen voor abnormaal hoge bedragen?

  • Wordt er vooral gefraudeerd op specifieke kaartnetwerken of in bepaalde landen?

  • Is er sprake van fraude met hoge snelheid, dat wil zeggen worden er in korte tijd meerdere pogingen gedaan met dezelfde creditcard, hetzelfde e-mailadres of IP-adres?

Als je kijkt naar de fraude met hoge snelheid op het screenshot hierboven, kun je deze fraudevector bijvoorbeeld bestrijden met regels die authorized_charges_per_card_number_hourly of authorized_charges_per_ip_address_hourly gebruiken.

Meer inzicht krijgen in factoren die fraude veroorzaken

Als je meer inzicht in fraude hebt, kun je snel de oorzaken van de fraude herkennen en bestrijden en hoef je niet elke keer handmatig transactiegegevens te analyseren. Op het tabblad Inzichten in het dashboard staan de meestvoorkomende kenmerken die in verband staan met frauduleuze transacties. Hier kun je een regel toevoegen om het desbetreffende kenmerk rechtstreeks vanaf het tabblad Inzichten aan te pakken.

Drie soorten attributen om regels te maken

Type 1

post-autorisatie-attributen: Deze kunnen door iedereen worden gebruikt. Wanneer je voor deze attributen kiest, moet je dubbele punten gebruiken voor en na post-autorisatie-attributen. Voorbeeld::cvc_check:.

Kenmerken
Beschrijving

:address_line1_check:

Een controle door de kaartverstrekker waarbij de eerste regel van het opgegeven factuuradres (meestal een straatnaam en huisnummer) wordt vergeleken met de kaarthoudergegevens die eerder aan de kaartverstrekker zijn opgegeven.

:address_zip_check:

Een controle door de kaartverstrekker waarbij de opgegeven postcode wordt vergeleken met de kaarthoudergegevens die eerder aan de kaartverstrekker zijn opgegeven.

:cvc_check​:

Een controle door de kaartverstrekker waarbij de opgegeven CVC-code (ook wel CVV genoemd) wordt vergeleken met de kaarthoudergegevens die eerder aan de kaartverstrekker zijn opgegeven.
Mogelijke waarden
Beschrijving

pass

De verstrekte gegevens zijn correct.

fail

De verstrekte gegevens zijn niet correct.

unavailable

De kaartverstrekker van de klant zal de opgegeven informatie niet controleren. Niet alle kaartverstrekkers of landen bieden ondersteuning voor adresverificatie.

unchecked

De gegevens zijn verstrekt, maar nog niet gecontroleerd. De kaartverstrekker van de klant zal de opgegeven informatie uiteindelijk wel controleren.

not_provided

De gegevens zijn niet aan Stripe verstrekt.
De waarden zijn hoofdlettergevoelig.

Dit is een voorbeeld van hoe post-autorisatie-attributen worden gebruikt:

  • Block if :address_line1_check: != 'pass' Als deze regel actief is, worden alle betalingen geblokkeerd die niet voldoen aan de eis van de kaartverstrekker dat de eerste regel van het opgegeven factuuradres overeen moet komen met de informatie over de kaarthouder die de verstrekker heeft. Dit betekent dat de betaling wordt geblokkeerd als deze controle niet beschikbaar is (‘unavailable’), als de gegevens niet door de verstrekker zijn gecontroleerd (‘unchecked’) of als de verstrekker de gegevens niet heeft verstrekt (‘not_provided’).

Type 2

standaardattributen: deze kunnen door iedereen worden gebruikt. Je moet dubbele punten gebruiken voor en na standaardattributen, bijvoorbeeld: :card_bin: We hebben onze standaardattributen ingedeeld in vier categorieën:

  • Attributen op basis van frequentie: nuttig om kaarttesten en kaart-cashing te voorkomen
  • Attributen op basis van kaartgegevens
  • Attributen op basis van betaalgegevens
  • Attributen op basis van klantgegevens

Voor sommige attributen moeten de waarden tekenreeksen zijn en voor andere nummers. We geven een voorbeeld van elk attribuut om dit te verduidelijken. Als het attribuut een tekenreeks als :card_bin: vereist, zie je in het voorbeeld dat het nummer tussen ‘ ’ staat. Bijvoorbeeld: :card_bin: = ‘424242’. Als een nummer vereist is, staat het nummer niet tussen ‘ ’, bijvoorbeeld :amount_in_usd: > 250.

Attributen op basis van frequentie

Er zijn vier soorten attributen op basis van frequentie die bijzonder handig zijn om fraude met gestolen betaalkaarten, kaarttesten en kaart-cashing te voorkomen.

  1. Autorisatie: gebaseerd op autorisatie door de verstrekker
  2. Betaling: gebaseerd op betalingen
  3. Weigering: gebaseerd op weigeringen door de verstrekker
  4. Blokkering: gebaseerd op blokkeringen door de machine-learning van Radar.

Er zijn ook attributen die zijn gebaseerd op de uitkomst van de betaling, inclusief autorisaties (op basis van geslaagde autorisaties door de verstrekker), betalingen (op basis van betaalpogingen), weigeringen (op basis van weigeringen door de verstrekker), chargebacks (eerdere transacties die zijn betwist wegens fraude) en blokkeringen (op basis van blokkeringen door de machine-learning van Radar). Uitkomsten worden gecombineerd met een informatie-element over de klant (e-mail, IP-adres, naam of klant-ID) om een attribuut te vormen.

Daarnaast kun je de frequentie van een informatie-element over de klant (e-mail, naam) combineren met het kaart- of IP-adres van een transactie. In andere woorden kunnen frequentieregels twee vormen aannemen:

  1. op basis van de uitkomst van de betaling (bijv. authorized_charges_per_email_hourly, blocked_charges_per_email_hourly) waarbij de uitkomst geslaagde autorisatie, betaalpoging, weigering, chargeback of blokkering is
  2. op basis van verbanden tussen klantinformatie en een betaalkaart of IP (bijv. name_count_for_card_weekly, email_count_for_ip_hourly)

Frequentieregels zijn exclusief de betaling die je op dat moment verwerkt. Zo staat authorized_charges_per_email_hourly bijvoorbeeld voor het aantal eerdere geslaagde betaalpogingen met het e-mailadres in het voorgaande uur. Voor de eerste betaalpoging in een bepaald uur met een e-mailadres heeft authorized_charges_per_email_hourly dus een waarde van 0. Als de eerste poging slaagt, heeft de tweede betaalpoging in datzelfde uur met dat e-mailadres een waarde van 1, enzovoort.

Kenmerk
Beschrijving

:authorized_charges_per​_card_number_all_time:

Het aantal betalingen dat voor deze betaalkaart is geautoriseerd op je account. Dit geldt voor betalingen vanaf 2020. (Opmerking: bovenlimiet is begrensd op <= 25)

:authorized_charges_per​_card_number_weekly:

Het aantal betalingen dat in de afgelopen week voor deze betaalkaart is geautoriseerd op je account. (Opmerking: bovenlimiet is begrensd op <= 25)

:authorized_charges_per​_card_number_daily:

Het aantal betalingen op deze kaart dat tijdens de afgelopen dag is geautoriseerd op je account. (Opmerking: bovenlimiet is begrensd op <= 25)

:authorized_charges_per​_card_number_hourly:

Het aantal betalingen op deze kaart dat in het afgelopen uur is geautoriseerd op je account. (Opmerking: bovenlimiet is begrensd op <= 25)

:authorized_charges_per​_email_all_time:

Het aantal betalingen dat voor dit e-mailadres is geautoriseerd op je account. Dit geldt voor betalingen vanaf 2020. (Opmerking: bovenlimiet is begrensd op <= 25)

:authorized_charges_per​_email_weekly:

Het aantal betalingen voor dit e-mailadres dat in de afgelopen week is geautoriseerd op je account. (Opmerking: bovenlimiet is begrensd op <= 25)

:authorized_charges_per​_email_daily:

Het aantal betalingen voor dit e-mailadres dat tijdens de afgelopen dag is geautoriseerd op je account. (Opmerking: bovenlimiet is begrensd op <= 25)

:authorized_charges_per​_email_hourly:

Het aantal betalingen voor dit e-mailadres dat in het afgelopen uur is geautoriseerd op je account. (Opmerking: bovenlimiet is begrensd op <= 25)

:authorized_charges_per​_ip_address_all_time:

Het aantal betalingen dat voor dit IP-adres is geautoriseerd op je account. Dit geldt voor betalingen vanaf 2020. (Opmerking: bovenlimiet is begrensd op <= 25)

:authorized_charges_per​_ip_address_weekly:

Het aantal betalingen dat in de afgelopen week vanaf dit IP-adres is geautoriseerd op je account. (Opmerking: bovenlimiet is begrensd op <= 25)

:authorized_charges_per​_ip_address_daily:

Het aantal betalingen dat tijdens de afgelopen dag vanaf dit IP-adres is geautoriseerd op je account. (Opmerking: bovenlimiet is begrensd op <= 25)

:authorized_charges_per​_ip_address_hourly:

Het aantal betalingen dat in het afgelopen uur vanaf dit IP-adres is geautoriseerd op je account. (Opmerking: bovenlimiet is begrensd op <= 25)

:authorized_charges_per​_customer_daily:

Het aantal keer dat een klant in de afgelopen 24 uur is geautoriseerd op je account. (Dit aantal is exclusief de betaling die nu wordt geëvalueerd.)

:authorized_charges_per​_customer_hourly:

Het aantal keer dat een klant in het afgelopen uur is geautoriseerd op je account. (Dit aantal is exclusief de betaling die nu wordt geëvalueerd.)

:blocked_charges_per​_card_number_daily:

Het aantal keer dat een kaartnummer in de afgelopen 24 uur voor je account is geblokkeerd door de machine-learningmodellen van Stripe. Dit aantal is exclusief de betaling die nu wordt geëvalueerd (bijvoorbeeld 4).

:blocked_charges_per​_card_number_hourly:

Het aantal keer dat een kaartnummer in het afgelopen uur voor je account is geblokkeerd door de machine-learningmodellen van Stripe. Dit aantal is exclusief de betaling die nu wordt geëvalueerd (bijvoorbeeld 4).

:blocked_charges_per​_customer_daily:

Het aantal keer dat een klant in de afgelopen 24 uur voor je account is geblokkeerd door de machine-learningmodellen van Stripe. Dit aantal is exclusief de betaling die nu wordt geëvalueerd (bijvoorbeeld 4).

:blocked_charges_per​_customer_hourly:

Het aantal keer dat een klant in het afgelopen uur voor je account is geblokkeerd door de machine-learningmodellen van Stripe. Dit aantal is exclusief de betaling die nu wordt geëvalueerd (bijvoorbeeld 4).

:blocked_charges_per​_ip_address_daily:

Het aantal keer dat een IP-adres in de afgelopen 24 uur voor je account is geblokkeerd door de machine-learningmodellen van Stripe. Dit aantal is exclusief de betaling die nu wordt geëvalueerd (bijvoorbeeld 4).

:blocked_charges_per​_ip_address_hourly:

Het aantal keer dat een IP-adres in het afgelopen uur voor je account is geblokkeerd door de machine-learningmodellen van Stripe. Dit aantal is exclusief de betaling die nu wordt geëvalueerd (bijvoorbeeld 4).

:total_charges_per​_card_number_daily:

Het aantal keer dat er is geprobeerd om in de afgelopen 24 uur geld af te schrijven van een betaalkaart van je account. Dit aantal is exclusief de betaling die nu wordt geëvalueerd (bijvoorbeeld 4).

:total_charges_per​_card_number_hourly:

Het aantal afschrijfpogingen in het afgelopen uur op een betaalkaart van je account. Dit aantal is exclusief de betaling die nu wordt geëvalueerd (bijvoorbeeld 4).

:total_charges_per​_customer_daily:

Het aantal keer dat een klant heeft geprobeerd om in de afgelopen 24 uur geld van je account af te schrijven. Dit aantal is exclusief de betaling die nu wordt geëvalueerd (bijvoorbeeld 4).

:total_charges_per​_customer_hourly:

Het aantal keer dat een klant heeft geprobeerd om in het afgelopen uur geld van je account af te schrijven. Dit aantal is exclusief de betaling die nu wordt geëvalueerd (bijvoorbeeld 4).

:total_charges_per​_ip_address_daily:

Het aantal keer dat een IP-adres heeft geprobeerd om in de afgelopen 24 uur geld van je account af te schrijven. Dit aantal is exclusief de betaling die nu wordt geëvalueerd (bijvoorbeeld 4).

:total_charges_per​_ip_address_hourly:

Het aantal keer dat een IP-adres heeft geprobeerd om in het afgelopen uur geld van je account af te schrijven. Dit aantal is exclusief de betaling die nu wordt geëvalueerd (bijvoorbeeld 4).

:declined_charges_per​_card_number_daily:

Het aantal keer dat een kaartnummer in de afgelopen 24 uur is geweigerd door de kaartverstrekker voor je account. Dit aantal is exclusief de betaling die nu wordt geëvalueerd (bijvoorbeeld 4).

:declined_charges_per​_card_number_hourly:

Het aantal keer dat een kaartnummer in het afgelopen uur is geweigerd door de kaartverstrekker voor je account. Dit aantal is exclusief de betaling die nu wordt geëvalueerd (bijvoorbeeld 4).

:declined_charges_per​_customer_daily:

Het aantal keer dat een klant in de afgelopen 24 uur is geweigerd door de kaartverstrekker voor je account. Dit aantal is exclusief de betaling die nu wordt geëvalueerd (bijvoorbeeld 4).

:declined_charges_per​_customer_hourly:

Het aantal keer dat een klant in het afgelopen uur is geweigerd door de kaartverstrekker voor je account. Dit aantal is exclusief de betaling die nu wordt geëvalueerd (bijvoorbeeld 4).

:declined_charges_per​_ip_address_daily:

Het aantal keer dat een IP-adres in de afgelopen 24 uur is geweigerd door de kaartverstrekker voor je account. Dit aantal is exclusief de betaling die nu wordt geëvalueerd (bijvoorbeeld 4).

:declined_charges_per​_ip_address_hourly:

Het aantal keer dat een IP-adres in het afgelopen uur is geweigerd door de kaartverstrekker voor je account. Dit aantal is exclusief de betaling die nu wordt geëvalueerd (bijvoorbeeld 4).

:declined_charges_per​_email_all_time:

Het aantal betalingen dat voor dit e-mailadres is geweigerd op je account. Dit geldt voor betalingen vanaf 2020. (Opmerking: bovenlimiet is begrensd op <= 25)

:declined_charges_per​_email_weekly:

Het aantal betalingen dat de afgelopen week voor dit e-mailadres is geweigerd op je account. Dit geldt voor betalingen vanaf 2020. (Opmerking: bovenlimiet is begrensd op <= 25)

:declined_charges_per​_email_daily:

Het aantal betalingen dat tijdens de afgelopen dag voor dit e-mailadres is geweigerd op je account. Dit geldt voor betalingen vanaf 2020. (Opmerking: bovenlimiet is begrensd op <= 25)

:declined_charges_per​_email_hourly:

Het aantal betalingen dat in het afgelopen uur voor dit e-mailadres is geweigerd op je account. Dit geldt voor betalingen vanaf 2020. (Opmerking: bovenlimiet is begrensd op <= 25)

:dispute_count_on_ip_all_time:

Het aantal frauduleuze chargebacks dat is gerelateerd aan betalingen van dit IP-adres op je account. Dit geldt voor betalingen vanaf 2020. (Opmerking: bovenlimiet is begrensd op <= 25)

:dispute_count_on_ip_weekly:

Het aantal frauduleuze chargebacks dat is gerelateerd aan betalingen van dit IP-adres op je account in de afgelopen week. (Opmerking: bovenlimiet is begrensd op <= 25)

:dispute_count_on_ip_daily:

Het aantal frauduleuze chargebacks dat is gerelateerd aan betalingen van dit IP-adres op je account tijdens de afgelopen dag. (Opmerking: bovenlimiet is begrensd op <= 25)

:dispute_count_on_ip_hourly:

Het aantal frauduleuze chargebacks dat is gerelateerd aan betalingen van dit IP-adres op je account in het afgelopen uur. (Opmerking: bovenlimiet is begrensd op <= 25)

:email_count_for​_card_all_time:

Het aantal e-mailberichten dat is gerelateerd aan deze betaalkaart via transacties op je account. Dit geldt voor betalingen vanaf 2020. (Opmerking: bovenlimiet is begrensd op <= 25)

:email_count_for​_card_weekly:

Het aantal e-mailberichten dat is gerelateerd aan deze betaalkaart via transacties op je account in de afgelopen week. (Opmerking: bovenlimiet is begrensd op <= 25)

:email_count_for​_card_daily:

Het aantal e-mailberichten dat is gerelateerd aan deze betaalkaart via transacties op je account tijdens de afgelopen dag. (Opmerking: bovenlimiet is begrensd op <= 25)

:email_count_for​_card_hourly:

Het aantal e-mailberichten dat is gerelateerd aan deze betaalkaart via transacties op je account in het afgelopen uur. (Opmerking: bovenlimiet is begrensd op <= 25)

:email_count_for​_ip_all_time:

Het aantal e-mailberichten dat is gerelateerd aan dit IP-adres via transacties op je account. Dit geldt voor betalingen vanaf 2020. (Opmerking: bovenlimiet is begrensd op <= 25)

:email_count_for​_ip_weekly:

Het aantal e-mailberichten dat is gerelateerd aan dit IP-adres via transacties op je account in de afgelopen week. (Opmerking: bovenlimiet is begrensd op <= 25)

:email_count_for​_ip_daily:

Het aantal e-mailberichten dat is gerelateerd aan dit IP-adres via transacties op je account tijdens de afgelopen dag. (Opmerking: bovenlimiet is begrensd op <= 25)

:email_count_for​_ip_hourly:

Het aantal e-mailberichten dat is gerelateerd aan dit IP-adres betaalkaart via transacties op je account in het afgelopen uur. (Opmerking: bovenlimiet is begrensd op <= 25)

:name_count_for​_card_all_time:

Het aantal namen dat is gerelateerd aan deze betaalkaart via transacties op je account. Dit geldt voor betalingen vanaf 2020. (Opmerking: bovenlimiet is begrensd op <= 25)

:name_count_for​_card_weekly:

Het aantal namen dat is gerelateerd aan deze betaalkaart via transacties op je account in de afgelopen week. (Opmerking: bovenlimiet is begrensd op <= 25)

:name_count_for​_card_daily:

Het aantal namen dat is gerelateerd aan deze betaalkaart via transacties op je account tijdens de afgelopen dag. (Opmerking: bovenlimiet is begrensd op <= 25)

:name_count_for​_card_hourly:

Het aantal namen dat is gerelateerd aan deze betaalkaart via transacties op je account in het afgelopen uur. (Opmerking: bovenlimiet is begrensd op <= 25).

:total_charges_per​_card_number_all_time:

Het totale aantal betalingen voor deze betaalkaart op je account. Dit geldt voor betalingen vanaf 2020. (Opmerking: bovenlimiet is begrensd op <= 25)

:total_charges_per​_card_number_weekly:

Het totale aantal betalingen voor deze betaalkaart op je account in de afgelopen week. (Opmerking: bovenlimiet is begrensd op <= 25)

:total_charges_per​_card_number_daily:

Het totale aantal betalingen voor deze betaalkaart op je account tijdens de afgelopen dag. (Opmerking: bovenlimiet is begrensd op <= 25)

:total_charges_per​_card_number_hourly:

Het totale aantal betalingen voor deze betaalkaart op je account in het afgelopen uur. (Opmerking: bovenlimiet is begrensd op <= 25)

:total_charges_per​_email_all_time:

Het totale aantal betalingen voor dit e-mailadres op je account. Dit geldt voor betalingen vanaf 2020. (Opmerking: bovenlimiet is begrensd op <= 25)

:total_charges_per​_email_weekly:

Het totale aantal betalingen voor dit e-mailadres op je account in de afgelopen week. (Opmerking: bovenlimiet is begrensd op <= 25)

:total_charges_per​_email_daily:

Het totale aantal betalingen voor dit e-mailadres op je account tijdens de afgelopen dag. (Opmerking: bovenlimiet is begrensd op <= 25)

:total_charges_per​_email_hourly:

Het totale aantal betalingen voor dit e-mailadres op je account in het afgelopen uur. (Opmerking: bovenlimiet is begrensd op <= 25)

:total_charges_per​_ip_address_all_time:

Het totale aantal betalingen voor dit IP-adres op je account. Dit geldt voor betalingen vanaf 2020. (Opmerking: bovenlimiet is begrensd op <= 25)

:total_charges_per​_ip_address_weekly:

Het totale aantal betalingen voor dit IP-adres op je account in de afgelopen week. (Opmerking: bovenlimiet is begrensd op <= 25)

:total_charges_per​_ip_address_daily:

Het totale aantal betalingen voor dit IP-adres op je account tijdens de afgelopen dag. (Opmerking: bovenlimiet is begrensd op <= 25)

:total_charges_per​_ip_address_hourly:

Het totale aantal betalingen voor dit IP-adres op je account in het afgelopen uur. (Opmerking: bovenlimiet is begrensd op <= 25)

Attributen op basis van kaartgegevens

Kenmerk
Beschrijving

:card_bin:

De BIN-code (Bank Identification Number) van de betaalkaart waarmee de betaling wordt uitgevoerd. Dit zijn de eerste 6 cijfers van het kaartnummer (bijvoorbeeld '424242').

:card_brand:

Het merk van de betaalkaart waarmee de betaling wordt uitgevoerd. Ondersteunde waarden zijn: 'amex' (American Express), 'visa' (Visa), 'mc' (Mastercard), 'dscvr' (Discover), 'diners' (Diners Club), 'interac' (Interac), 'jcb' (JCB) en 'cup' (UnionPay).

:card_country:

De code die uit twee letters bestaat en die overeenkomt met het land van uitgifte van de betaalkaart (bijvoorbeeld 'US'). Deze pagina bevat de lijst met landcodes. Gebruik de operator IN om meerdere landen op te geven: IN ('GB', 'DE', 'AE').

:card_fingerprint:

De vingerafdruk van de betaalkaart waarmee de betaling wordt uitgevoerd. Dit is een unieke ID van een bepaald kaartnummer dat je kunt vinden door naar Betalingen te gaan en een betaling in het gedeelte Betaalmethode te controleren (bijvoorbeeld 'VfE3rx3VlaQhS8Lp'). Deze code is hoofdlettergevoelig.

:card_funding:

Hiermee wordt aangegeven of de betaalkaart prepaid is, of dat het om een betaalkaart of creditcard gaat. Ondersteunde waarden zijn: 'credit', 'debit', 'prepaid', 'unknown'.

:card_3d_secure_support:

Het niveau van 3D Secure-ondersteuning voor de betaalkaart waarmee de betaling wordt uitgevoerd. Ondersteunde waarden zijn: 'required', 'recommended', 'optional' en 'not_supported'.

Attributen op basis van betaalgegevens

Kenmerk
Beschrijving

:amount_in_xyz:

Het bedrag van de betaling omgezet naar de valuta die is opgegeven door xyz (bijvoorbeeld amount_in_usd). Als je een van de volgende ondersteunde valuta's opgeeft, berekent Stripe automatisch welk omgezet bedrag je moet gebruiken: aud, brl, cad, chf, dkk, eur, gbp, hkd, inr, jpy, mxn, nok, nzd, ron, sek, sgd of usd. Gebruik geen onderliggende eenheden (gebruik euro en geen centen) (bijvoorbeeld :amount_in_usd: > 250)

:average_usd_amount​_attempted_on_card_all_time:

Het gemiddelde bedrag (in USD) aan gepoogde transacties voor de betaalkaart op je account. Dit geldt voor betalingen vanaf 2020.

:average_usd_amount​_successful_on_card_all_time:

Het gemiddelde bedrag (in USD) aan transacties die zijn geautoriseerd voor de betaalkaart op je account. Dit geldt voor betalingen vanaf 2020.

:risk_level:

Het risiconiveau van een betaling, zoals bepaald door Stripe. Ondersteunde waarden zijn: ‘normal’, ‘elevated’, ‘highest’ en ‘not_assessed’.

:risk_score:

De risicoscore van een betaling, zoals bepaald door Stripe (bijvoorbeeld > 50). De waarden liggen tussen 0 (laagste risico) en 100 (hoogste risico). Een score van 65 of hoger komt overeen met het verhoogde risiconiveau ‘elevated’, en een score van 75 of hoger staat voor het hoogste risiconiveau ‘highest’.

:charge_description:

De beschrijving die bij de betaling is verstrekt (bijvoorbeeld ‘Proefles’).

:is_recurring:

Hiermee wordt aangegeven of het gaat om een terugkerende betaling, zoals bij abonnementen. (Dit is een boolean en daarom moet je :is_recurring: gebruiken als dit waar is, en NOT :is_recurring: als dit onwaar is. Let op: != kan niet worden gebruikt.)

:is_off_session:

Hiermee wordt aangegeven wanneer een Stripe Billing-betaling niet wordt geactiveerd door een rechtstreekse handeling van de gebruiker, of wanneer de markering off_session is ingesteld tijdens de bevestiging van de PaymentIntent. (Dit is een boolean en daarom moet je :is_off_session: gebruiken als dit waar is, en NOT :is_off_session: als dit onwaar is. Let op: != kan niet worden gebruikt.)

:digital_wallet:

Het type digitale wallet waarmee de betaalgegevens worden bewaard. Ondersteunde waarden zijn: ‘android_pay’, ‘amex_express_checkout’, ‘apple_pay’, ‘masterpass’, ‘samsung_pay’, ‘unknown’, ’visa_checkout’, ‘none’.

:destination:

Voor gebruikers van Connect die bestemmingsbetalingen maken is dit het bestemmingsaccount waarvoor de betaling wordt gemaakt (bijvoorbeeld‘acct_19KCB9AlaaEw6AgR’). Deze code is hoofdlettergevoelig.

:is_checkout:

Hiermee wordt aangegeven of de betaling via Checkout is verwerkt. Dit kenmerk is alleen van toepassing op betalingen die via de nieuwe versie van Checkout zijn verwerkt, en niet op betalingen via de verouderde versie van Checkout. (Dit is een boolean en daarom moet je :is_checkout: gebruiken als dit waar is, en NOT :is_checkout: als dit onwaar is. Let op: != kan niet worden gebruikt.)

:is_3d_secure​_authenticated:

Hiermee wordt aangegeven of de betaling volledig is geauthenticeerd via 3D Secure-verificatie. Authenticatie is ofwel gebaseerd op risico, of een uitdaging. (Dit is een boolean en daarom moet je :is_3d_secure_authenticated: gebruiken als dit waar is, en NOT :is_3d_secure_authenticated: als dit onwaar is. Let op: != kan niet worden gebruikt.)

:is_3d_secure:

Hiermee wordt aangegeven of de betaling een 3D Secure-bron gebruikt. (Dit is een boolean en daarom moet je :is_3d_secure: gebruiken als dit waar is, en NOT :is_3d_secure: als dit onwaar is. Let op: != kan niet worden gebruikt.)

:has_liability_shift:

Is 'waar' als de fraudeaansprakelijkheid voor deze betaling is verschoven. (Dit is een boolean en daarom moet je :has_liability_shift: gebruiken als dit waar is, en NOT :has_liability_shift als dit onwaar is. Let op: != kan niet worden gebruikt.)

:seconds_since_card​_first_seen:

Het aantal seconden sinds de betaalkaart van de betaling voor het eerst op je account te zien was. Dit geldt voor betalingen vanaf 2020.

:seconds_since_first_successful​_auth_on_card:

Het aantal seconden sinds de eerste auth-bewerking voor de betaalkaart van de betaling op je account succesvol werd uitgevoerd. Dit geldt voor betalingen vanaf 2020.

:total_usd_amount_failed​_on_card_all_time:

Het totale bedrag (in USD) aan mislukte (geblokkeerde of geweigerde) transacties met deze betaalkaart op je account. Dit geldt voor betalingen vanaf 2020.

:total_usd_amount_successful​_on_card_all_time:

Het totale bedrag (in USD) aan transacties die zijn geautoriseerd voor de betaalkaart op je account. Dit geldt voor betalingen vanaf 2020.

Attributen op basis van klantgegevens

Kenmerk
Beschrijving

:ip_country:

De code die uit twee letters bestaat en die overeenkomt met de landspecifieke geolocatie van het IP-adres waar de betaling vandaan komt (bijvoorbeeld 'GB'). Deze pagina bevat de lijst met landcodes. Gebruik de operator IN om meerdere landen op te geven: IN ('GB', 'DE', 'AE').

:ip_address:

Het IP-adres van herkomst van de betaling (bijvoorbeeld '192.168.0.1' om een enkel IP-adres op te geven. Als je een groter vangnet wilt instellen, kun je INCLUDES '192.168' gebruiken om alle IP-adressen met dezelfde zes begincijfers op te nemen).

:is_anonymous_ip:

Hiermee wordt aangegeven of het IP-adres van herkomst van de betaling een bekend proxy- of Tor-afsluitknooppunt is. Deze informatie wordt dagelijks bijgewerkt. (Dit is een boolean en daarom moet je :is_anonymous_ip: gebruiken als dit waar is, en NOT :is_anonymous_ip: als dit onwaar is. Let op: != kan niet worden gebruikt.)

:is_my_login_ip:

Hiermee wordt aangegeven of het IP-adres van herkomst van de betaling ooit eerder is gebruikt voor aanmelding bij je Stripe-account. Dit kenmerk kan als proxy worden gebruikt voor “is my IP address.” (Dit is een boolean en daarom moet je :is_my_login_ip: gebruiken als dit waar is, en NOT :is_my_login_ip: als dit onwaar is. Let op: != kan niet worden gebruikt.)

:email:

Het e-mailadres dat bij de betaling is verstrekt (bijvoorbeeld 'gebruiker@voorbeeld.com').

:email_domain:

Het domein van het e-mailadres dat bij de betaling is verstrekt (bijvoorbeeld 'voorbeeld.com').

:is_disposable_email:

Hiermee wordt aangegeven of het e-mailadres dat bij de betaling is verstrekt komt van een bekende provider voor eenmalige e-mailadressen. Stripe houdt een lijst bij met domeinen voor dergelijke e-mailadressen om dit kenmerk aan te bieden. (Dit is een boolean en daarom moet je :is_disposable_email: gebruiken als dit waar is, en NOT is_disposable_email: als dit onwaar is. Let op: != kan niet worden gebruikt.)

:billing_address:

Het volledige factuuradres van de kaarthouder dat is opgegeven (bijvoorbeeld 'Dapperstraat 1, Amsterdam, 1234 AB').

:billing_address_line1:

De eerste regel van het verstrekte factuuradres van de kaarthouder. Meestal een straatnaam en huisnummer (bijvoorbeeld 'Dapperstraat 1').

:billing_address_line2:

De tweede regel van het verstrekte factuuradres van de kaarthouder. Dit is meestal een appartement of wooneenheid (bijvoorbeeld 'Apt 5b').

:billing_address_postal_code:

De postcode of ZIP-code van het verstrekte factuuradres van de kaarthouder (bijvoorbeeld '1234 AB').

:billing_address_city:

De plaats van het verstrekte factuuradres van de kaarthouder (bijvoorbeeld 'Amsterdam').

:billing_address_state:

De Amerikaanse staat van het verstrekte factuuradres van de kaarthouder (bijvoorbeeld 'CA').

:billing_address_country:

De code die uit twee letters bestaat en die overeenkomt met het land van het factuuradres van de kaarthouder (bijvoorbeeld 'US'). Deze pagina bevat de lijst met landcodes. Gebruik de operator IN om meerdere landen op te geven: IN ('US', 'DE', 'AE').

:seconds_since​_email_first_seen:

Het aantal seconden sinds het opgegeven e-mailadres van de betaling voor het eerst op je account te zien was. Dit geldt voor betalingen vanaf 2020.

:seconds_since​_email_first_seen_on_stripe:

Het aantal seconden sinds het opgegeven e-mailadres van de betaling voor het eerst algemeen op Stripe te zien was. Dit geldt voor betalingen vanaf 2020.

:shipping_address:

Het volledige verzendadres dat is opgegeven (bijvoorbeeld 'Dapperstraat 1, Amsterdam, 1234 AB').

:shipping_address_line1:

De eerste regel van het verstrekte factuuradres. Meestal een straatnaam en huisnummer (bijvoorbeeld 'Dapperstraat 1').

:shipping_address_line2:

De tweede regel van het verstrekte verzendadres van de kaarthouder. Dit is meestal een appartement of wooneenheid (bijvoorbeeld 'Apt 5b').

:shipping_address_postal_code:

De postcode of ZIP-code van het verstrekte verzendadres (bijvoorbeeld '1234 AB').

:shipping_address_city:

De plaats van het verstrekte verzendadres (bijvoorbeeld 'Amsterdam').

:shipping_address_state:

De Amerikaanse staat van het verstrekte verzendadres (bijvoorbeeld 'CA').

:shipping_address_country:

De code die uit twee letters bestaat en die overeenkomt met het land van het opgegeven verzendadres (bijvoorbeeld 'US'). Deze pagina bevat de lijst met landcodes. Gebruik de operator IN om meerdere landen op te geven: IN ('US', 'DE', 'AE').

Dit is een voorbeeld van hoe standaardkenmerken kunnen worden gebruikt:

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

Als deze regel actief is, worden alle betalingen met betaalkaarten die zijn uitgegeven in Canada, Duitsland of de Verenigde Arabische Emiraten geblokkeerd.

Type 3

Metadatakenmerken: deze kenmerken zijn afhankelijk van de metadata die je naar Stripe verstuurt. Bij deze kenmerken moet je twee dubbele punten gebruiken voor en na standaardkenmerken. Voorbeeld:::Customer Age::. Metadatakenmerken kunnen de vorm aannemen van tekenreeksen of nummers. Wanneer ze worden gebruikt als tekenreeksen zijn kenmerken hoofdlettergevoelig.

Metadata kunnen worden gebruikt om buitengewoon nuttige regels te maken, bijvoorbeeld om betalingen aan een handmatige controle te onderwerpen als er een bepaalde SKU wordt aangeschaft of om de frictie voor terugkerende klanten te verminderen. In deze whitepaper lees je hoe je meer metadata kunt doorgeven.

Metadatakenmerken worden met de volgende opmaak genoteerd:

  • ::[naam metadatakenmerk]:: [operator] [waarde_metadata]

Stel dat we betalingen met de volgende sleutel-waardegegevens hebben opgeslagen in het metadataveld:

Metadatanaam
Metadatawaarde
Customer age
22
Item ID
5A381D
Category ID
groceries

Er kan een regel worden geschreven om betalingen die voldoen aan de volgende criteria aan een controle te onderwerpen.

  • Review if ::Customer Age:: < 30

Je kunt ook regels schrijven met zowel metadata-attributen als andere in dit document genoemde ondersteunde attributen. Zo kun je een regel schrijven waardoor betalingen alleen aan controle worden onderworpen als de item-ID 5A381D is en het bedrag hoger is dan US $ 1000.

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

Met metadata-attributen kan de operator IN ook worden gecombineerd met meerdere waarden. Zo kun je bijvoorbeeld een regel schrijven waardoor een betaling aan controle worden onderworpen als de categorie-ID “groceries”, “electronics” of “clothing” is.

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

De operator INCLUDES kan worden gebruikt met regels voor metadata-attributen en andere tekenreeksattributen die overeen moeten komen met subtekenreeksen. Zo kun je bijvoorbeeld een regel schrijven waardoor betalingen aan controle worden onderworpen als de item-ID de tekenreeks A381 bevat. Onder meer 'A381', '5A381D', 'A381D' en '5A381' voldoen aan die criteria.

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

Metadata kunnen ook worden geraadpleegd op klant- en bestemmingsobjecten (als deze worden gebruikt voor een bepaalde betaling). Deze attributen worden met de volgende opmaak genoteerd:

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

Stel je hebt een klant met de volgende metadata:

Metadatanaam
Metadatawaarde
Trusted
true

Je kunt een regel schrijven waardoor betalingen altijd worden toegestaan als het metadataveld Trusted van de klant true is.

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

Of als je een bestemming zou hebben met de volgende metadata:

Metadatanaam
Metadatawaarde
Category
new

Je kunt een regel schrijven waardoor een betaling aan controle wordt onderworpen als het metadataveld Category van de bestemming new is.

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

Opgeslagen lijsten (bijv. toelatingslijsten, blokkeerlijsten) in je regels gebruiken

Je kunt in je regels verwijzen naar een groep waarden met behulp van lijsten die je eerder hebt samengesteld (bijv. toelatingslijsten of blokkeerlijsten). Als je probeert een lijst e-mailadressen te blokkeren, moet je een blokkeerlijst maken in plaats van een afzonderlijke regel op te stellen voor elk e-mailadres dat je wilt blokkeren.

Alle lijstaliassen waarnaar in de regels wordt verwezen moeten beginnen met @. Om een regel samen te stellen waarin wordt verwezen naar een lijst, moet je de volgende structuur volgen:

  • {action} [attribute] in [list]

Stel dat je bijvoorbeeld een lijst met kaartlanden hebt die je wilt blokkeren. Je zou dan een regel kunnen schrijven met diverse OR-clausules:

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

Je kunt de regel ook schrijven aan de hand van een inline-lijst:

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

Je kunt ook een lijst opstellen met kaartlanden die je wilt blokkeren, getiteld card_countries_to_block. Je kunt de landen van je keuze dan toevoegen aan de lijst en in een regel naar die lijst verwijzen:

  • Block if :card_country: in @card_countries_to_block

Een regel die gebruikmaakt van een lijst is niet alleen exacter, maar het is ook eenvoudiger om zo'n lijst te bewerken en er een groot aantal elementen aan toe te voegen.

Opmerking: Handelaren uit de EU moeten bekend zijn met de verordening inzake geoblocking en de daarin opgenomen verboden op het blokkeren van betalingen van klanten die in de EU-lidstaten zijn gevestigd. Meer informatie over deze verordening.

Complexe regels schrijven met meerdere voorwaarden

Je kunt complexe voorwaarden bouwen door basisvoorwaarden samen te voegen met behulp van the operators AND, OR en NOT. Je kunt ook hun symbolische equivalenten gebruiken: &&, || en !. Vergelijkbaar met programmeertalen zoals C, Python en SQL, ondersteunt Stripe standaard operator precedence (bewerkingsvolgorde). Bijvoorbeeld de complexe voorwaarde:

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

wordt geïnterpreteerd als:

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

Het groeperen van subvoorwaarden binnen complexe voorwaarden wordt ook ondersteund door haakjes te gebruiken. Het voorgaande voorbeeld kan bijvoorbeeld worden aangepast om de evaluatievolgorde van subpredicaten expliciet te wijzigen:

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

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

Door haakjes op verschillende plaatsen te gebruiken, leiden al deze complexe voorwaarden tot verschillende resultaten.

De functie is_missing kan ook worden gebruikt in OR- of AND-conjuncties:

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

Of je kunt de functie is_missing gebruiken als deze niet ontbreekt, in dit geval als het betalingen blokkeert als de :ip_country: NIET ontbreekt en het IP-adres afkomstig is uit de Verenigde Staten of Puerto Rico.

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

Regels voor backtesting

Als algemene filosofie voor regelanalyse is er een afweging tussen het voorkomen van fraude en het blokkeren van goede transacties of fout-positieven. Met behulp van backtesting kun je regels identificeren die binnen je risicobereidheid vallen of de juiste balans vinden tussen voorkomen chargebacks en een toename van valse positieven. Om de impact van een regel in te schatten, kun je combinaties backtesten met behulp van transactiegegevens van de afgelopen zes maanden via het Radar Dashboard en meer gerichte analyses uitvoeren om te begrijpen hoe de regel zou hebben gepresteerd als deze onlangs was ingesteld.

Backtesting in het Dashboard

De definities van frauduleuze en andere geslaagde betalingen variëren afhankelijk van het soort regel dat je test:

Blokkeerregel

  • Chargeback, vroegtijdige fraudewaarschuwing ontvangen of terugbetaald wegens fraude: geslaagde betalingen die zijn betwist of terugbetaald wegens fraude of geslaagde betalingen die aan controle zijn onderworpen en die zijn betwist of terugbetaald wegens fraude

  • Andere geslaagde betalingen: geslaagde betalingen die niet zijn betwist of terugbetaald wegens fraude of geslaagde betalingen die aan controle zijn onderworpen en niet zijn betwist of terugbetaald wegens fraude -

Mislukte betaalpogingen: geweigerd door verstrekker of geblokkeerd door Radar

Controleregel

  • Chargeback, vroegtijdige fraudewaarschuwing ontvangen of terugbetaald wegens fraude: geslaagde betalingen die zijn betwist of terugbetaald wegens fraude

  • Andere geslaagde betalingen: geslaagde betalingen die niet zijn betwist of terugbetaald wegens fraude

  • Mislukt of al aan controle onderworpen: geweigerd door verstrekker, geblokkeerd door Radar of geslaagde betalingen die aan controle zijn onderworpen (ongeacht chargeback- of terugbetalingsstatus)

Toelatingsregel

  • Geblokkeerd door Stripe of je regels op maat: door Radar geblokkeerde betalingen

  • Chargeback, vroegtijdige fraudewaarschuwing ontvangen of terugbetaald wegens fraude: geslaagde betalingen die zijn betwist of terugbetaald wegens fraude of geslaagde betalingen die aan controle zijn onderworpen en die zijn betwist of terugbetaald wegens fraude

  • Andere geslaagde of door de bank geweigerde betalingen: geweigerd door verstrekker, geslaagde betalingen die niet zijn betwist of terugbetaald wegens fraude of geslaagde betalingen die aan controle zijn onderworpen en niet zijn betwist of terugbetaald wegens fraude

Uitvoering van backtesting-analyses op maat

De backtesting-functie op het Radar-dashboard gebruikt de transacties van de voorgaande zes maanden en bevat informatie over chargebacks, vroegtijdige fraudewaarschuwingen en wegens fraude terugbetaalde betalingen.

Het kan een goed idee zijn om een meer gerichte analyse uit te voeren als je risico loopt te worden opgenomen in het programma voor fraudemonitoring van Visa (uitsluitend gericht op vroegtijdige fraudewaarschuwingen) of als je hebt opgemerkt dat het aantal fraudegevallen voor een specifiek IP-land of soort wallet sterk is gestegen. Om dat te doen kun je een SQL-query in Sigma ontwikkelen of rapporten met betaalgegevens op het dashboard exporteren en analyseren. Bij backtesting op maat kun je flexibele perioden gebruiken (meer dan zes maanden) en meer gerichte analyses uitvoeren (je kunt je bijvoorbeeld uitsluitend richten op chargebacks of vroegtijdige fraudewaarschuwingen). In de voorbeeld-query hieronder wordt een backtest uitgevoerd op vroegtijdige fraudewaarschuwingen van Visa voor transacties van meer dan $ 100 in het hypothetische geval dat je hebt geconstateerd dat je fraudevolume bij hogere bedragen de laatste tijd sterk is gestegen en dat transacties met een verhoogde risicoscore hebben geleid tot een risico dat je in het monitoringprogramma word opgenomen:

Using fields and tables available in Sigma

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 base

Backtesting op de laatste 60 dagen op EFW-aanmaakdatum richt zich op de meest recente fraude, terwijl bij backtesting op de laatste 60-120 dagen van niet-frauduleuze verkopen de kans op fraude toeneemt.

Veelvoorkomende fraudevectoren

De meeste fraudeurs volgen een vast patroon voor het plegen van fraude. Eerst valideren ze de gestolen betalingsgegevens (bijvoorbeeld kaarten). Als ze hebben vastgesteld dat ze werken, gebruiken ze deze referenties om waarde te onttrekken in de vorm van fysieke goederen voor persoonlijk gebruik of wederverkoop (luxegoederen of elektronica), diensten voor persoonlijk gebruik of wederverkoop (voedselbezorgdiensten) of diensten en producten die helpen bij het plegen van verdere fraude (bijvoorbeeld webhostingdiensten, berichtspamdiensten enzovoort).

Lees verder voor meer informatie over enkele van de meest voorkomende fraudevectoren en suggesties voor het gebruik van Radar-regels om ze te beperken.

Testen

Testen van creditcards houdt in dat fraudeurs scripts of handmatige processen gebruiken om te testen of onbewerkte gestolen kaartnummers nog steeds actief zijn. In deze fraudefase gaat het niet om het verkrijgen van een fysiek goed of dienst, maar om te valideren of de kaarten actief zijn. Deze kosten zijn over het algemeen voor transacties van lagere bedragen of autorisaties. Testen worden over het algemeen snel achter elkaar uitgevoerd. Kenmerken die nuttig kunnen zijn, zijn groeps- en snelheidskenmerken, zoals:

  • total_charges_per_customer

  • card_count_for_email

  • card_count_for_ip_address

  • total_charges_per_ip

Fraudeurs proberen deze meestal te omzeilen door valse e-mails op te stellen en specifieke e-mailadressen te gebruiken. Meer geavanceerde fraudeurs maskeren IP-adressen of hebben zelfs meerdere apparaten om unieke apparaatgegevens te verstrekken. Op dat moment is het belangrijk om goed en typisch klantgedrag te herkennen. Functies zoals e-maildomein en IP-land, naast andere bredere categorieën, kunnen helpen bij het identificeren van transacties met een hoger risico. Veel frauduleuze klanten gebruiken populaire e-maildomeinen van bekende e-mailproviders, zoals gmail.com. Je ziet misschien domeinen als gmail.comms of gomail.co, die de identiteit van fraudeurs proberen te maskeren. Het land van de kaart en het IP-land kunnen ook worden gebruikt om klanten te segmenteren en ervoor te zorgen dat de transacties afkomstig zijn uit gebieden die kenmerkend zijn voor je gebruikersbestand. Transacties buiten deze locaties worden mogelijk eerder gecontroleerd of geblokkeerd.

Een laatste functionaliteit om dit testgedrag in te perken, is het instellen van CAPTCHA.

In Stripe Checkout worden CAPTCHA-uitdagingen automatisch aangepakt wanneer onze machine learning een aanval voor het testen van creditcards detecteert. Om het testen van creditcards te beperken, gebruikt Stripe een reeks geautomatiseerde en handmatige controles, waaronder limietbegrenzers, waarschuwingen en voortdurende controles naast het trainen van kaarttestmodellen om aanvallen automatisch te detecteren. Deze modellen pakken alleen uitdagingen aan wanneer er een kaarttestaanval aan de gang is, zodat echte gebruikers bijna nooit een CAPTCHA zien, alleen de bots. Hierdoor is het aantal kaarttesten bij ondernemingen die Stripe Checkout gebruiken met maar liefst 80% gedaald, met een verwaarloosbaar effect op de conversie.

Het toevoegen van door Stripe beheerde CAPTCHA voor alle Checkout-gebruikers heeft het testen van kaarten met 80% verminderd, met een effect van minder dan 2 basispunten
(0,02%) op de autorisatiepercentages.

Je kunt overigens ook regels schrijven als ”Blokkeren indien meer dan 3 keer geweigerd vanaf een bepaald IP-adres” om dit soort aanvallen te beperken.

Waarde-extractie

Gestolen creditcards (nieuw gedrag)

Bij deze fraudevector gebruikt de fraudeur de gevalideerde gestolen kaart op zijn eigen apparaat of op een apparaat dat voor fraude wordt gebruikt.

Deze vector wordt doorgaans gebruikt in gescripte massa-aanvallen of op kleinere schaal met meer gerichte fraudenetwerken en -bendes. Hoe dan ook, als je regelkenmerken gebruikt waarin de nieuwheid van een account op Stripe wordt gemeten, bijvoorbeeld hours_since_email_first_seen_on_stripe, in combinatie met een risicoscore en andere kenmerken, kun je deze splinternieuwe kaarthouders op afstand houden. Bovendien kunnen snelheidsbeperkingen op IP, e-mails en kaarten handelaren verder beschermen tegen grootschalige aanvallen waarbij fraudeurs zo snel mogelijk willen profiteren van gestolen inloggegevens.

Gestolen creditcards (maskeergedrag)

Bij deze fraudevector gebruikt de fraudeur de gevalideerde gestolen kaart op zijn eigen apparaat of op een apparaat dat voor fraude wordt gebruikt of heeft de fraudeur het account van een abonnee gehackt en toegang gekregen tot de creditcardgegevens die in het account worden bewaard.

De fraudeur zal zijn best doen om zijn aanwezigheid te maskeren door:

  • Dezelfde naam te gebruiken als bij eerdere voltooide transacties

  • Hetzelfde factuuradres te gebruiken als bij eerdere voltooide transacties

  • Een VPN te gebruiken om zich voor te doen als de oorspronkelijke kaarthouder. Ze kunnen proberen de VPN af te stemmen op dezelfde plaats en soms zelfs dezelfde straat

  • Slechts een klein detail te veranderen, bijvoorbeeld in het e-mailadres of het telefoonnummer

  • Een ander bezorgadres op te geven dan bij eerdere transacties, voor een fysiek artikel, mogelijk met een grote afstand tussen het factuur- en bezorgadres. Dit is een onduidelijk signaal

Het hierboven beschreven maskeergedrag maakt het moeilijk om precies te zien wie nu eigenlijk de transactie heeft uitgevoerd, de oorspronkelijke kaarthouder of een fraudeur die het account heeft gehackt. Dit betekent doorgaans dat dit soort fraude langer ongemerkt blijft, zowel door de handelaar als door de oorspronkelijke kaarthouder.

De strategie is dezelfde: de fraudeur probeert zoveel mogelijk waarde te halen uit de gestolen inloggegevens. Regels die gebruikmaken van snelheidsbeperkende functies, naast risicoscore, mislukte cvc-controles of mislukte postcodecontroles, kunnen je helpen beschermen tegen dit soort gedrag.

Andere aanbevolen werkwijzen

Hier zijn nog enkele aanbevolen werkwijzen om je te helpen het schrijven van regels in Radar te optimaliseren.

Afrekenproces
Neem een expliciete verwijzing naar je servicevoorwaarden op in het afrekenproces
In het geval van chargebacks moet je een duidelijk gelabeld screenshot van de servicevoorwaarden verstrekken zoals deze in het afrekenproces worden getoond. Leg duidelijk uit waarom dit zo belangrijk is. Hierdoor verhoog je de kans om het argument te winnen.
Validatie van CVS en postcode
Hiermee kan de kaarthouder worden gecontroleerd door de verstrekker van de betaalkaart. Dit verhoogt de kans op het winnen van chargebacks en zorgt vaak ook voor een beter autorisatiepercentage. Overweeg om mislukte controles te blokkeren.
Verzamel zo veel mogelijk klantgegevens
Als je deze gegevens verzamelt, kunnen de verstrekkers van de betaalkaart jouw case beter beoordelen bij chargebacks. Zo vergroot je de kans dat je het geschil wint. Deze worden gezien als due diligence.
De Gold-standaard omvat: CVC en postcode, klantnaam, e-mailadres, volledig factuuradres, IP-adres, apparaatgegevens, enz.
Door Stripe.js te implementeren krijgt Radar toegang tot het IP-adres, het apparaat en gedragsgegevens waarmee de fraudedetectie kan worden verbeterd.
Klantinteracties
Betaalkaarten met chargebacks in de categorie “fraudulent” op de blokkeerlijst plaatsen
Als een klant een betaling als frauduleus aanmerkt en een chargeback aanvraagt, gebeurt dat waarschijnlijk ook voor toekomstige betalingen.
Teruggave van verdachte en/of frauduleuze betalingen
70-85% van alle TC40-transacties wordt chargebacks, en een chargeback kan alleen worden voorkomen door een volledige terugbetaling.
Implementeer een eenduidige omschrijving voor op het bankafschrift
Verkleint het aantal niet-herkende chargebacks.

Belang van het gebruik van Stripe.js

  • Neem stripe.js op in het volledige betaaltraject voor maximale signalering van fraude
  • Om het maximale uit Radar te halen zonder gevolgen voor de paginalaadtijd, laad je stripe.js asynchroon op niet-betaalpagina's
  • Het eenvoudigst is om dit naast de Google Analytics-scripttags te plaatsen
  • Volledige stripe.js-bundelgrootte is 29,6 kB (gzip-formaat)
    • In de toekomst zal het mogelijk zijn radar.js los van stripe.js op te nemen

Conclusie

Regels kunnen een buitengewoon nuttig instrument zijn voor fraudebescherming op maat. Door een unieke logica toe te passen op basis van een aantal van de beste werkwijzen die in dit whitepaper worden beschreven, kun je in Radar een configuratie voor fraudepreventie opzetten die aansluit op de behoeften van je bedrijf.

Voor meer informatie over Radar for Fraud Teams kun je hier terecht.

Als je al gebruikmaakt van Radar for Fraud Teams, ga dan naar de pagina Regels op je dashboard om te beginnen met het schrijven van regels.

Andere opmerkingen

Radar voor platforms

Heb je een platform dat gebruikmaakt van Stripe Connect? Dan worden de regels die je opstelt alleen toegepast op betalingen die worden gemaakt op het platformaccount (in Connect-termen zijn dit bestemmings- of namens-betalingen).
Voor betalingen die direct in het gekoppelde account worden gemaakt, gelden de regels van dat account.

Radar voor Terminal

Terminal-betalingen worden niet gescreend door Radar. Als je Terminal gebruikt, kun je daarom regels schrijven op basis van IP-frequentie zonder je zorgen te maken dat fysieke betalingen worden geblokkeerd.

Klaar om aan de slag te gaan?

Maak een account en begin direct met het ontvangen van betalingen. Contracten of bankgegevens zijn niet vereist. Je kunt ook contact met ons opnemen om een pakket op maat voor je onderneming samen te stellen.