Stripes standardregler använder maskininlärning för att förutsäga och blockera ett stort antal bedrägliga betalningar. För företag som behöver mer kontroll över vilka betalningar som ska granskas, tillåtas eller blockeras är regler ett kraftfullt verktyg för att anpassa ditt skydd mot bedrägerier.

Denna guide täcker en mängd olika ämnen relaterade till Radar-regler, inklusive över 100 Radar-regler som du kan använda och bästa praxis kring backtestning, regelskrivning och mer.

Låt oss sätta i gång

Vikten av reglernas ordning och hierarki

_Den ordning i vilken reglerna listas på din Radar-sida spelar roll. _ Varje betalning utvärderas mot de regler du har skapat och utfört i följande ordning:

1. Request 3DS: Regler som begär 3D Secure-autentisering när den används med Payment Intents API eller Checkout. Oavsett matchningar på den här regeln utvärderas reglerna Allow, Block och Review efter.
   
2. Allow: Regler som tillåter att en betalning behandlas. Allow-regler bör implementeras noggrant, eftersom de åsidosätter alla andra regler utom 3DS-regler, och bör användas med största försiktighet. Endast handlare som har behandlats mer än 100 000 USD kan skriva allow-regler.
   
3. Block: Regler som blockerar en betalning och avvisar den. Om en betalning avvisas utvärderas den inte mot några regler för granskning.
   
4. Review: Dessa betalningar behandlas fortfarande och kunden debiteras, men dessa betalningar flaggas så att du kan ta en andra titt om du vill.
   

För att omsätta detta i praktiken kan vi använda följande regler som exempel. Alla betalningar som understiger 10 USD behandlas. Detta beror på att den första regeln tillåter betalningen, så inga ytterligare regler utvärderas. På samma sätt, enligt dessa regler, skulle en betalning på 1 500 USD som görs inom USA med en normal risknivå också tillåtas, trots regeln att blockera betalningar över 1 000 USD. Detta beror på den andra regeln i listan, som tillåter betalningar som görs inom USA och med en normal risknivå. När en viss regel har utlösts utvärderas inga ytterligare regler.

• Allow betalningar under 10 USD

• Allow betalningar inom USA och med risknivå normal

• Block betalningar där risknivån är hög

• Block betalningar över 1 000 USD

• Review betalningar med ett kort utfärdat utanför USA

Lathund för språkregler

Regler liknar SQL och det finns olika operatorer som du kan använda baserat på vilken typ av data du använder för att skapa din regel. Här är en lathund.

Om du uttryckligen vill kontrollera att ett attribut eller en metadatanyckel finns, ska du inte använda operatorn != utan använda funktionen is_missing. Förse denna funktion med det attribut eller den metadatanyckel som eventuellt saknas. Du kan t.ex. skriva en regel som matchar alla betalningar där du inte har tillgång till kundens e-postadress:

• Granska om is_missing(:email_domain:)
  

Eller så kan du skriva en regel som matchar alla betalningar där kundens e-postadress INTE saknas:

• Granska om !(is_missing(:email_domain:))
  

Skriva regler med hjälp av naturligt språk

Om du vill skriva regler enklare eller är osäker på vilka attribut du ska använda för att hantera ett specifikt scenario för bedrägeri, översätter den AI-drivna Radar Assistant dina naturliga språkmeddelanden till regler i Radars syntax. Du kan också backtesta regeln direkt från Radar Assistant, så att du kan se hur den skulle ha presterat historiskt innan du implementerar regeln.

Vanligt förekommande regler för Radar

Detta är en icke uttömmande lista över vanligt förekommande Radar-regler baserade på olika mål.

Regler som hjälper till att förhindra carding eller kortinlösen

Regler som hjälper till att förhindra bedrägerier med kända riskfyllda SKU:er

Denna regel kräver metadata eller att SKU-information skickas som beskrivning för att ta betalt. Dessa betalningar behandlas fortfarande och kunden debiteras, men de flaggas så att du kan titta på dem en gång till.

Regler som hjälper till att förhindra missbruk av provperioder från förbetalda kort

Analysera dina bedrägerier för att skapa regler

Granskningar av bedrägerier

För att ta fram de mest effektiva reglerna måste du ha en djup förståelse för bedrägerierna på ditt konto. Det är viktigt att karakterisera de olika typerna av bedrägerier som förekommer. Några frågor att ställa:

• Registrerar sig konton och gör omedelbart bedrägliga köp med hjälp av nya e-postmeddelanden och namn på kortinnehavare?

• Får bedrägliga aktörer tillgång till konton med historik och gör inköp för onormalt stora belopp?

• Är bedrägerier riktade mot specifika kortbetalningsnätverk eller kortländer?

• Förekommer det bedrägerier med hög hastighet, dvs. flera försök från samma kort, e-post eller IP-adress under en kort tidsperiod?

Om man granskar det snabba bedrägeri som förekommer i skärmdumpen ovan kan regler som använder authorized_charges_per_card_number_hourly eller authorized_charges_per_ip_address_hourly potentiellt hantera denna bedrägerivektor.

Få större insikt i orsakerna till bedrägerier

Fraud Insights hjälper dig att snabbt identifiera och åtgärda orsakerna till bedrägerier utan att du behöver analysera transaktionerna manuellt. Fliken Insights i Dashboard visar de främsta attributen som är förknippade med bedrägliga transaktioner. Därefter kan du lägga till en regel för att hantera det attributet direkt från fliken Insights.

Tre typer av attribut för att skapa regler

Typ 1

attribut efter auktorisering: Dessa är tillgängliga för alla att använda. När du använder dessa attribut måste du använda kolon före och efter attributen efter auktorisering som :cvc_check:.

Här är ett exempel på hur man använder attribut efter auktorisering:

• Blockera om :address_line1_check: != 'pass' Med denna regel kommer alla debiteringar att blockeras om de inte specifikt klarar kortinnehavarens kontroll av att matcha den första raden i den angivna faktureringsadressen mot den information som kortinnehavaren har registrerad. Detta innebär att om denna kontroll är otillgänglig, om dessa uppgifter avmarkeras av utfärdaren, eller om dessa uppgifter inte tillhandahålls av utfärdaren, kommer betalningen att blockeras.
  

Typ 2

standardattribut: Dessa är tillgängliga för alla att använda. Du måste använda kolon före och efter standardattributen, till exempel :card_bin: Vi har delat in våra standardattribut i fyra kategorier:

• Attribut baserade på frekvens – användbara för att förhindra carding eller kortinlösen
  
• Attribut baserade på kortinformation
  
• Attribut baserade på betalningsuppgifter
  
• Attribut baserade på kunduppgifter
  

Vissa attribut kräver värden i form av strängar, medan andra kräver värden i form av siffror. Vi har gett ett exempel för varje attribut för att förtydliga detta. Om attributet kräver en sträng, som :card_bin: gör, ser du i exemplet att talet ligger inom ' '. Till exempel, :card_bin: = '424242', även om det kräver ett nummer, kommer det inte att ha ' ' som :amount_in_usd: > 250.

Attribut baserade på frekvens

Det finns fyra typer av attribut baserade på frekvens som är särskilt användbara för att förhindra bedrägeri med stulna kort, carding och kortinlösen.

1. Auktorisering: baserad på godkännanden från utfärdaren
   
2. Avgift: baserad på avgifter
   
3. Nekad betalning: baserad på utfärdarens nekade betalningar
   
4. Blockering: baserat på blockeringar som utförs av Radars maskininlärning
   

Det finns också attribut baserade på debiteringsutfall, inklusive auktoriseringar (baserade på framgångsrika godkännanden från utfärdaren), betalningar (baserade på avgiftsförsök), nekade betalningar (baserade på avslag från utfärdaren), tvister (tidigare transaktioner som bestridits som bedrägliga) och blockeringar (baserade på blockeringar som utförs av Radars maskininlärning). Utfallet kombineras med en uppgift om kunden (e-post, IP-adress, namn eller kund-ID) för att bilda ett attribut.

Dessutom kan du kombinera frekvensen för en kunduppgift (e-post, namn) med det kort eller den IP-adress som används vid en transaktion. Med andra ord finns det två typer av frekvensregler:

1. Baserat på resultatet av betalningen (t.ex. authorized_charges_per_email_hourly, blocked_charges_per_email_hourly) där resultatet är lyckad auktorisering, försök att ta betalt, nekad betalning, bestridande, blockering
   
2. Baserat på länkar mellan information om kunden och ett kort eller en IP (t.ex. name_count_for_card_weekly, email_count_for_ip_hourly)
   

Frekvensregler utesluter den betalning som du för närvarande behandlar. Till exempel representerar authorized_charges_per_email_hourly antalet tidigare försök att ta betalt från ett e-postmeddelande under den föregående timmen. Så för det första försöket att ta betalt för ett e-postmeddelande under en viss timme har authorized_charges_per_email_hourly värdet 0. Om det första försöket lyckas får det andra försöket att ta betalt för samma e-postmeddelande under samma timme värdet 1, och så vidare.

Attribut baserade på kortinformation

Attribut baserade på uppgifter om betalningen

Attribut baserade på uppgifter om kunden

Här är ett exempel på hur man använder standardattribut:

• Blockera om :card_country: IN ('CA', 'DE', 'AE')
  

Med denna regel på plats kommer alla debiteringar från ett kort utfärdat i Kanada, Tyskland eller Förenade Arabemiraten att blockeras.

Typ 3

Metadataattribut: Dessa attribut beror på vilka metadata du skickar till Stripe. Med dessa attribut måste du använda dubbla kolon före och efter standardattributen, som ::Customer Age::. Metadataattribut kan fungera som antingen strängar eller siffror. När de används som strängar är metadataattribut skiftlägeskänsliga.

Metadata kan användas för att skapa mycket kraftfulla regler, som att tillämpa manuell granskning av debiteringar baserat på den SKU som köpts eller minska friktionen för återkommande kunder. Om du vill lära dig hur du skickar mer metadata kan du läsa den här guiden.

Metadataattribut skrivs i följande struktur:

• ::[metadataattributets namn]:: [operator] [metadata_värde]
  

Anta att vi har betalningar med följande nyckelvärdesdata sparade i metadatafältet:

En regel kan skrivas för att granska betalningar som uppfyller följande kriterier.

• Granska om ::Kundens ålder:: < 30
  

Du kan också skriva regler som använder både metadataattribut och andra stödjande attribut som nämns i det här dokumentet. Du kan t.ex. skriva en regel som bara granskar en betalning om objektets ID matchar 5A381D och betalningens belopp överstiger 1 000 USD.

• Granska om ::ID för objekt:: = '5A381D' och :amount_in_usd: > 1000
  

Metadataattribut stöder också operatorn IN för att matcha mot flera värden. Du kan t.ex. skriva en regel som innebär att en betalning granskas om kategori-ID:t är något av "livsmedel", "elektronik" eller "kläder".

• Granska om ::Kategori-ID:: IN ('livsmedel', 'elektronik', 'kläder')
  

Operatorn INCLUDES kan användas med regler för metadataattribut och andra strängattribut för att matcha delsträngar. Du kan t.ex. skriva en regel som placerar en betalning i granskning om radpostens ID innehåller strängen A381. Detta matchar "A381", "5A381D", "A381D", "5A381" med flera.

• Granska om ::ID för objekt:: INCLUDES 'A381'
  

Metadata kan också hämtas för kund- och destinationsobjekt (om dessa används för en viss betalning). Dessa attribut är skrivna med följande struktur:

• ::[kund|destination]:[metadataattributets namn]::[operator][metadata_värde]:
  

Anta att du har en kund med följande metadata:

Du kan skriva en regel som alltid tillåter betalningar om kundens metadatafält Trusted är true.

• Tillåtet om ::customer:Trusted:: = 'true'
  

Eller om du hade en destination med följande metadata:

Du kan skriva en regel som tar en betalning till granskning om destinationens metadatafält Category är new.

• Granska om ::destination:Category:: = 'new'
  

Använda sparade listor i dina regler (t.ex. tillåten-listor, blockeringslistor)

Du kan hänvisa till en grupp värden i dina regler genom listor som du tidigare har skapat (t.ex. tillåten-listor eller blockeringslistor). Om du försöker blockera en lista med e-postmeddelanden bör du skapa en blockeringslista i stället för att skapa flera regler för varje e-postmeddelande som du vill blockera.

Alla listalias som refereras till i regler måste börja med @. För att konstruera en regel som refererar till en lista måste du följa strukturen:

• {action} [attribut] i [lista]
  

Säg till exempel att du har en lista med kortländer som du vill blockera. Du kan skriva en regel med flera OR-fraser:

• Blockera om :card_country: = 'CA' OR :card_country: = 'DE' OR :card_country: = 'AE'
  

Du kan också skriva en regel med hjälp av en inline-lista:

• Blockera om :card_country: IN ('CA', 'DE', 'AE')
  

Du kan också skapa en lista med länder på kort som du vill blockera, med namnet card_countries_to_block. Du kan sedan lägga till de länder du vill blockera i listan och hänvisa till listan i en regel:

• Blockera om :card_country: i @card_countries_to_block
  

Regeln med en lista är inte bara mer kortfattad, den är också mycket lättare att redigera och lägga till ett stort antal radposter i.

Skriva komplexa regler med flera villkor

Du kan skapa komplexa villkor genom att sammanfoga grundläggande villkor med hjälp av operatorerna AND, OR och NOT. Du kan också använda deras symboliska motsvarigheter: &&, || respektive !. I likhet med programmeringsspråk som C, Python och SQL stöder Stripe standardoperator prioritet (operationers ordning). Till exempel det komplexa villkoret:

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

tolkas som:

• {condition_X} ELLER ((INTE {condition_Y}) OCH {condition_Z})
  

Gruppering av undervillkor inom komplexa villkor stöds också med hjälp av parenteser. Det föregående exemplet kan t.ex. ändras så att ordningen av undervillkor uttryckligen ändras:

• ({condition_X} ELLER (INTE {condition_Y})) OCH {condition_Z}

• {condition_X} ELLER INTE ({condition_Y} OCH {condition_Z})

Genom att använda parenteser på olika platser leder vart och ett av dessa komplexa villkor till olika resultat.

Funktionen is_missing kan också användas i konjunktioner av typen OR eller AND:

• Granska om is_missing(:email_domain:) OR :email_domain: IN ('yopmail.net', 'yandex.ru')
  

Eller så kan du använda funktionen is_missing när den inte saknas, i det här fallet om den blockerar betalningar om :ip_country: INTE saknas och IP-adressen är från antingen USA eller PR.

• Blockera om !(is_missing(:ip_country:))AND :ip_country: IN ('USA', 'PR')
  

Regler för backtestning

En allmän filosofi för regelanalys är att det finns en avvägning mellan att förhindra bedrägeribekämpning och att blockera bra transaktioner eller falska positiva resultat. Backtester hjälper till att identifiera regler som faller inom din riskacceptans eller ger rätt balans mellan förhindrade bestridanden och en eventuell ökning av falska positiva resultat. För att uppskatta effekten av en regel kan du backtesta kombinationer med hjälp av transaktionsdata från de senaste sex månaderna via Radar Dashboard och genomföra mer riktade analyser för att förstå hur regeln skulle ha fungerat om den nyligen hade införts.

Backtesta i Dashboard

Definitionerna av vad som utgör bedrägliga och andra framgångsrika betalningar skiljer sig åt baserat på den regeltyp du testar:

Blockeringsregel

• __ Bestridda, fick tidig bedrägerivarning eller återbetalades som bedrägeri:__ lyckade betalningar som bestreds eller återbetalades på grund av bedrägeri eller lyckade betalningar som granskades och bestreds eller återbetalades på grund av bedrägeri

• Övriga lyckade betalningar: lyckade betalningar som inte bestridits eller återbetalats på grund av bedrägeri eller lyckade betalningar som granskats och inte bestridits eller återbetalats på grund av bedrägeri

• Misslyckade försök till betalning: nekad betalning av utfärdare eller blockerad av Radar

Granskningsregel

• __ Bestridda, fick tidig bedrägerivarning eller återbetalades som bedrägeri:__ lyckade betalningar som bestreds eller återbetalades som bedrägeri

• Andra lyckade betalningar: lyckade debiteringar som inte bestridits eller återbetalats på grund av bedrägeri

• __ Misslyckad eller redan granskad:__ nekad betalning av utfärdare, blockerad av Radar, eller lyckade betalningar som granskas (oavsett status för bestridande eller återbetalning)

Tillåt-regel

• Blockerad av Stripe eller dina anpassade regler: Debiteringar blockerade av Radar

• __ Bestridda, fick tidig bedrägerivarning eller återbetalades som bedrägeri:__ lyckade betalningar som bestreds eller återbetalades på grund av bedrägeri eller lyckade betalningar som granskades och bestreds eller återbetalades på grund av bedrägeri

• Övriga lyckade eller bankavvisade betalningar: avvisade av utfärdaren, lyckade betalningar som inte bestridits eller återbetalats på grund av bedrägeri eller lyckade betalningar som granskats och inte bestridits eller återbetalats på grund av bedrägeri

Utföra anpassade analyser av backtest

Funktionen för backtest i Radar Dashboard fokuserar på de senaste sex månadernas transaktioner och inkluderar tvister, tidiga bedrägerivarningar och betalningar som återbetalats som bedrägeri.

Du kanske vill utföra en mer riktad analys om du till exempel riskerar att identifieras i ett Visa Fraud Monitoring Program (fokuserat exklusive skatt på tidiga bedrägerivarningar) eller om du märker en nyligen inträffad ökning av bedrägerier från ett visst IP-land eller en viss typ av plånbok. För att göra det kan du bygga en SQL-fråga i Stripe Sigma eller exportera och analysera rapporter med betalningsdata i Dashboard. Anpassad backtestning möjliggör flexibilitet i tidsramar (längre än sex månader) och mer riktade analyser (till exempel kan du fokusera på bara bestridanden eller EFW:er). I frågan nedan backtestas tidiga bedrägerivarningar (EFW:er) från Visa på transaktioner > 100 USD om du hypotetiskt fann att bedrägerivolymen nyligen ökade på högre värde och att transaktioner med förhöjd riskpoäng skapade risk för övervakningsprogrammet:

Använda fält och tabeller som finns tillgängliga i Stripe Sigma

med bas som (
    välj
        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
    där card_brand = ‘visa’
    och (c.amount / 100) >= 100
    och c.captured >= dateadd(‘day’, -180, current_date)
)

välj 
    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

från basen

Backtestning av de senaste 60 dagarna efter EFW-skapandedatum inriktar sig på de senaste bedrägerierna, medan backtestning av de senaste 60–120 dagarna av icke-bedräglig försäljning gör det möjligt för bedrägerier att mogna mer fullständigt.

Vanliga bedrägerivektorer

De flesta bedrägliga aktörer följer ett gemensamt bedrägerimönster. Först validerar de den stulna informationen om betalningen (t.ex. kort). När de har bekräftat att de fungerar använder de dessa uppgifter för att utvinna värde i form av fysiska varor för personligt bruk eller återförsäljning (lyxvaror eller elektronik), tjänster för personligt bruk eller återförsäljning (matleveranstjänster) eller tjänster och produkter som hjälper till att begå ytterligare bedrägerier (t.ex. webbhotellstjänster, tjänster för skräppost osv.).

Läs vidare för mer information om några av de vanligaste formerna av bedrägeri och förslag på hur du kan använda Radar-regler för att motverka dem.

Testning

Carding sker när bedrägliga aktörer använder skript eller manuella processer för att testa om stulna kort fortfarande är aktiva. Denna fas av bedrägeri handlar inte om att få en fysisk vara eller tjänst; det är för att validera att korten är aktiva. Dessa tar i allmänhet betalt för transaktioner eller auktoriseringar på lägre belopp. Testning sker i allmänhet i snabb följd och med hög hastighet. Attribut som kan vara till hjälp är grupperings- och hastighetsfunktioner, t.ex:

• total_charges_per_customer

• card_count_for_email

• card_count_for_ip_address

• total_charges_per_ip

Bedrägliga aktörer försöker vanligtvis komma runt dessa genom att skapa falska e-postmeddelanden och använda olika e-postadresser. Mer avancerade bedrägliga aktörer kommer att maskera IP-adresser eller till och med ha flera enheter för att tillhandahålla unika enhetsdata. Då är det viktigt att känna till bra och typiska beteenden hos kunderna. Funktioner som e-post-domän och IP-land, bland andra bredare kategorier, kan hjälpa till att identifiera transaktioner med högre risk. Många bedrägliga kunder använder populära e-postdomäner från etablerade e-postleverantörer, som gmail.com. Du kan se domäner som gmail.comms eller gomail.co, som försöker maskera bedrägliga aktörers identitet. Land för kort och IP-land kan också användas för att segmentera kunder och säkerställa att transaktioner kommer från områden som är typiska för din användarbas. Transaktioner utanför dessa platser kan vara av intresse att granska eller blockera.

En sista funktionalitet för att stävja detta testbeteende är att införa CAPTCHA.

I Stripe Checkout visas CAPTCHA-autentiseringsfrågor automatiskt när vår maskininlärningstjänst upptäcker en attack med carding. För att mildra carding använder Stripe-kort en serie automatiserade och manuella kontroller, inklusive frekvensbegränsningar, varningar och pågående granskningar tillsammans med utbildning av carding-modeller för att automatiskt upptäcka attacker. Dessa modeller används endast för autentiseringsfrågor när en attack med carding pågår, så att riktiga användare nästan aldrig ser en CAPTCHA, bara robotarna. Detta har minskat carding för företag som använder Stripe Checkout med hela 80 % med nästan ingen detekterbar inverkan på konverteringen.

Observera att du också kan skriva anpassade regler som "Blockera om betalning nekas mer än 3 gånger från en viss IP-adress" för att minska attacker med carding.

Värdeutvinning

Stulna kreditkort (nytt beteende)

I denna bedrägerivektor använder den bedrägliga aktören det validerade stulna kortet på sin personliga enhet eller en enhet som används för att begå bedrägeri.

Denna vektor missbrukas vanligtvis antingen genom skriptade massattacker eller i mindre skala upp med mer riktade bedrägerier och fickor. Oavsett vilket, genom att använda regelattribut som mäter hur nytt ett Stripe-konto är, som hours_since_email_first_seen_on_stripe, i kombination med risk_score och andra funktioner, kan dessa varumärkta kortinnehavare hållas borta. Dessutom kan hastighetsbegränsningar för IP, e-post och kort ytterligare skydda handlare från volymattacker där bedrägliga aktörer försöker tjäna pengar på stulna inloggningsuppgifter så snabbt som möjligt.

Stulna kreditkort (maskeringsbeteende)

I denna bedrägerivektor använder den bedrägliga aktören det validerade stulna kortet på sin personliga enhet eller en enhet som används för att begå bedrägeri eller den bedrägliga aktören har äventyrat ett konto för abonnemang och fått tillgång till kreditkortsinformationen som sparats på kontot.

Den bedrägliga aktören kommer att göra sitt bästa för att maskera sin närvaro genom att:

• Använda samma namn som tidigare genomförda transaktioner

• Använda samma adress för fakturering som vid tidigare genomförda transaktioner

• Använda ett VPN för att försöka få det att se ut som om de är den ursprungliga kortinnehavaren. De kan koppla VPN till samma stad och ibland till och med samma kvarter

• Ändra endast en mindre detalj, som e-postadress eller telefonnummer

• Ändring av leveransadress från tidigare transaktioner, för en fysisk vara, med potentiellt ett stort delta i avståndet mellan fakturering och leveransadress. Detta är en lös signal

Det maskeringsbeteende som beskrivs ovan gör det svårt att urskilja vem som faktiskt genomför transaktionen – den ursprungliga kortinnehavaren eller en bedräglig aktör som har äventyrat kontot. Detta innebär ofta att den här typen av bedrägeri inte upptäcks under en längre tid, varken av handlaren eller av den ursprungliga kortinnehavaren.

Strategin här är densamma: den bedrägliga aktören försöker få ut så mycket värde som möjligt från de stulna inloggningsuppgifterna. Regler som använder hastighetsbegränsande funktioner, tillsammans med riskscore, cvccheck fails eller zip check fails, kan hjälpa till att skydda mot detta beteende.

Andra bästa praxis

Här följer ytterligare bästa praxis som hjälper dig att optimera regelskrivningen i Radar.

Vikten av att använda Stripe.js

• Inkludera stripe.js på hela betalningen för maximal signalering av bedrägerier
  
• För att få ut mesta möjliga av Radar utan att påverka sidans laddningstid, ladda stripe.js async på sidor som inte är betalningssidor
  
• Enklast att placera bredvid Google Analytics script-taggar
  
• Fullständig storlek på Stripe.js-paketet är 29,6 kb gzippat
  
  • Framtida tillstånd: radar.js kommer att kunna inkluderas separat från stripe.js
    

Slutsats

Regler kan vara ett utomordentligt kraftfullt verktyg för att hjälpa dig att anpassa skyddet mot bedrägeri. Genom att implementera unik logik, med hjälp av några av de bästa praxisprinciper som beskrivs i den här guiden, kan du skapa bedrägeribekämpning i Radar som är specifik för dina affärsbehov.

Om du vill lära dig mer om Radar for Fraud Teams, se här.

Om du redan är användare av Radar for Fraud Teams kan du gå till kassan på regelsidan i din Dashboard för att börja skriva regler.

Övriga anmärkningar

Radar för plattformar

Använder du plattformen Stripe Connect? Om så är fallet gäller alla regler du skapar endast betalningar som skapas på plattformens konto (i Connect är dessa destinationsbetalningar eller betalningar för annans
räkning). Betalningar som skapas direkt på det anslutna kontot omfattas av det kontots regler.

Radar for Terminal

Terminals avgifter granskas inte av Radar. Det innebär att om du använder Terminal kan du skriva regler baserade på IP-frekvens utan att behöva oroa dig för att blockera betalningar i fysisk miljö.