กฎเริ่มต้นของ Stripe ใช้แมชชีนเลิร์นนิงในการคาดการณ์และบล็อกการชำระเงินที่เป็นการฉ้อโกงจำนวนมาก ในส่วนของธุรกิจที่อยากจะควบคุมการชำระเงินที่ควรได้รับการตรวจสอบ อนุญาต หรือบล็อกให้ได้มากขึ้น กฎก็จะเป็นเครื่องมือที่มีประสิทธิภาพในการปรับแต่งระบบป้องกันการฉ้อโกง

คู่มือนี้จะพูดถึงเรื่องต่างๆ เกี่ยวกับกฎของ Radar ไม่ว่าจะเป็นกฎของ Radar กว่า 100 แบบที่คุณใช้ได้ และแนวทางปฏิบัติที่ดีที่สุดเกี่ยวกับการทดสอบย้อนหลัง การเขียนกฎ และอื่นๆ

มาเริ่มต้นกันเลย

ความสำคัญของลำดับในกฎและลำดับชั้น

ลำดับการระบุกฎในหน้า Radar ของคุณเป็นเรื่องสำคัญ การชำระเงินแต่ละครั้งจะได้รับการประเมินเทียบกับกฎที่คุณสร้างและดำเนินการตามลำดับต่อไปนี้

1. Request 3DS: กฎที่กำหนดให้ใช้การตรวจสอบสิทธิ์แบบ 3D Secure เมื่อใช้ร่วมกับ Payment Intents API หรือ Checkout ระบบจะประเมินกฎ Allow, Block และ Review หลังกฎนี้ ไม่ว่ากฎนี้จะมีรายการที่ตรงกันเป็นเช่นไรก็ตาม
   
2. Allow: กฎที่อนุญาตให้ประมวลผลการชำระเงินได้ คุณควรใช้กฎ Allow อย่างรอบคอบเนื่องจากกฎเหล่านี้จะแทนที่กฎอื่นๆ ทั้งหมดของคุณ ยกเว้นกฎ 3DS และควรใช้ด้วยความระมัดระวังสูงสุด ทั้งนี้ มีเพียงผู้ขายที่ประมวลผลมากกว่า 100,000 ดอลลาร์สหรัฐเท่านั้นที่เขียนกฎ Allow ได้
   
3. Block: กฎที่บล็อกและปฏิเสธการชำระเงิน หากการชำระเงินถูกปฏิเสธ ระบบก็จะไม่ประเมินการชำระเงินนั้นๆ กับกฎ Review ใดๆ
   
4. Review: ระบบจะยังคงประมวลผลการชำระเงินเหล่านี้อยู่ และจะมีการเรียกเก็บเงินจากลูกค้า แต่ระบบจะตั้งค่าสถานะการชำระเงินเหล่านั้นเพื่อให้คุณกลับมาดูอีกครั้งได้หากต้องการ
   

ก่อนจะนำไปใช้ เรามาลองใช้กฎต่อไปนี้เป็นตัวอย่างกันก่อน ระบบจะประมวลผลการชำระเงินทั้งหมดที่มีมูลค่าน้อยกว่า 10 ดอลลาร์สหรัฐเนื่องจากกฎข้อแรกอนุญาตการชำระเงินดังกล่าว ระบบจึงไม่ประเมินกฎใดๆ เพิ่มเติม ในทำนองเดียวกัน เมื่อพิจารณากฎเหล่านี้ ระบบก็จะอนุญาตให้มีการชำระเงินจำนวน 1,500 ดอลลาร์สหรัฐในสหรัฐอเมริกาซึ่งมีระดับความเสี่ยงเป็นปกติเช่นกัน แม้ว่าจะมีกฎที่บล็อกการชำระเงินที่มีมูลค่ามากกว่า 1,000 ดอลลาร์สหรัฐ ที่เป็นเช่นนี้ก็เพราะกฎข้อที่สองในรายการอนุญาตการชำระเงินภายในสหรัฐอเมริกาที่มีระดับความเสี่ยงปกติ เมื่อระบบใช้กฎข้อใดข้อหนึ่งแล้ว ก็จะไม่มีการประเมินกฎใดๆ เพิ่มเติม

• Allow การชำระเงินที่มีมูลค่าน้อยกว่า $10 (10 ดอลลาร์สหรัฐ)

• Allow การชำระเงินภายในสหรัฐอเมริกาและมีระดับความเสี่ยงเป็น normal (ปกติ)

• Block การชำระเงินที่มีระดับความเสี่ยงเป็น high (สูง)

• Block การชำระเงินที่มีมูลค่า greater than $1,000 (มากกว่า 1,000 ดอลลาร์สหรัฐ)

• Review การชำระเงินด้วยบัตรที่ออกให้ outside the US (นอกสหรัฐอเมริกา)

ข้อมูลสรุปเกี่ยวกับถ้อยคำที่ใช้ในกฎ

กฎก็คล้ายกับ SQL และมีตัวดำเนินการหลายแบบให้คุณใช้ตามประเภทของข้อมูลที่คุณใช้สร้างกฎ และนี่คือข้อมูลสรุป

หากต้องการตรวจสอบให้ชัดเจนว่ามีแอตทริบิวต์หรือแอตทริบิวต์ข้อมูลเมตาอยู่หรือไม่ อย่าใช้ตัวดำเนินการ != แต่ให้ใช้ฟังก์ชัน is_missing ให้ระบุฟังก์ชันนี้ไว้กับแอตทริบิวต์หรือคีย์ข้อมูลเมตาที่อาจขาดหายไป ตัวอย่างเช่น คุณอาจเขียนกฎให้ระบุการชำระเงินทั้งหมดที่คุณไม่มีสิทธิ์เข้าถึงที่อยู่อีเมลของลูกค้าได้ ดังนี้

• Review if is_missing(:email_domain:)
  

หรือคุณอาจเขียนกฎให้ระบุการชำระเงินทั้งหมดที่ "ไม่มี" ที่อยู่อีเมลของลูกค้าได้ ดังนี้

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

การเขียนกฎโดยใช้ภาษาธรรมชาติ

หากคุณต้องการเขียนกฎให้ง่ายขึ้นหรือไม่แน่ใจว่าจะใช้แอตทริบิวต์ใดในการจัดการกับกรณีการฉ้อโกงนั้นๆ เป็นการเฉพาะ Radar Assistant ที่ขับเคลื่อนด้วย AI จะแปลพร้อมท์ภาษาธรรมชาติของคุณเป็นกฎตามรูปแบบของ Radar คุณยังทดสอบย้อนหลังกับกฎได้โดยตรงจาก Radar Assistant ด้วย ดังนั้น คุณจึงดูได้ว่ากฎน่าจะมีประสิทธิภาพเช่นไรในช่วงที่ผ่านมาก่อนที่จะใช้กฎนั้นๆ

กฎของ Radar ที่ใช้กันทั่วไป

นี่คือรายการกฎของ Radar บางส่วนที่ใช้กันทั่วไปตามเป้าหมายต่างๆ

กฎที่ช่วยป้องกันการทดสอบบัตรหรือการรับเงินสดผ่านบัตร

กฎที่ช่วยป้องกันการฉ้อโกงด้วย SKU ที่ทราบว่ามีความเสี่ยง

กฎนี้ต้องใช้ข้อมูลเมตาหรือการส่งข้อมูล SKU เป็นคำอธิบายการเรียกเก็บเงิน ระบบจะยังคงประมวลผลการชำระเงินเหล่านี้อยู่และเรียกเก็บเงินจากลูกค้า แต่ระบบจะตั้งค่าสถานะการชำระเงินเหล่านี้เพื่อให้คุณกลับมาดูอีกครั้งได้

กฎที่ช่วยป้องกันการละเมิดผ่านการทดลองใช้จากบัตรเติมเงิน

วิเคราะห์การฉ้อโกงของคุณเพื่อใช้เป็นแนวทางในการสร้างกฎ

การตรวจสอบการฉ้อโกง

หากจะสร้างกฎให้มีประสิทธิภาพที่สุด คุณก็ต้องเข้าใจกิจกรรมการฉ้อโกงในบัญชีของคุณเป็นอย่างดี คุณจำเป็นต้องแยกแยะวิธีการฉ้อโกงประเภทต่างๆ ที่มีอยู่ให้ได้ โดยคุณควรตั้งคำถามบางข้อดังนี้

• บัญชีมีการลงทะเบียนและทำการซื้อในลักษณะที่เป็นการฉ้อโกงโดยทันทีด้วยอีเมลและชื่อเจ้าของบัตรใหม่หรือไม่

• มิจฉาชีพเข้าถึงบัญชีเก่าและทำการซื้อเป็นจำนวนมากผิดปกติหรือไม่

• การฉ้อโกงเน้นไปทางเครือข่ายบัตรหรือประเทศของบัตรอย่างใดอย่างหนึ่งโดยเฉพาะหรือไม่

• มีการฉ้อโกงความเร็วสูงเกิดขึ้นหรือไม่ ซึ่งหมายถึงการดำเนินการหลายๆ รอบจากบัตร อีเมล หรือที่อยู่ IP เดียวกันในช่วงเวลาสั้นๆ

ในการตรวจสอบการฉ้อโกงแบบความเร็วสูงที่เกิดขึ้นในภาพหน้าจอด้านบน กฎที่ใช้ authorized_charges_per_card_number_hourly หรือ authorized_charges_per_ip_address_hourly อาจช่วยรับมือกับการฉ้อโกงประเภทนี้ได้

รับข้อมูลเชิงลึกมากขึ้นเกี่ยวกับปัจจัยขับเคลื่อนการฉ้อโกง

ข้อมูลเชิงลึกเกี่ยวกับการฉ้อโกงช่วยให้คุณระบุและจัดการกับต้นตอของการฉ้อโกงได้อย่างรวดเร็วโดยไม่ต้องวิเคราะห์ข้อมูลธุรกรรมด้วยตนเอง แท็บข้อมูลเชิงลึกในแดชบอร์ดจะแสดงแอตทริบิวต์ยอดนิยมที่เกี่ยวข้องกับธุรกรรมที่เป็นการฉ้อโกง จากตรงนี้ คุณสามารถเพิ่มกฎเพื่อระบุแอตทริบิวต์นั้นๆ ได้โดยตรงจากแท็บข้อมูลเชิงลึก

แอตทริบิวต์ 3 ประเภทในการสร้างกฎ

ประเภท 1

แอตทริบิวต์หลังการอนุมัติ: ทุกคนใช้แอตทริบิวต์เหล่านี้ได้ เมื่อใช้แอตทริบิวต์เหล่านี้ คุณจะต้องใช้เครื่องหมายทวิภาค (:) ขึ้นต้นและลงท้ายแอตทริบิวต์หลังการอนุมัติ เช่น :cvc_check:

ตัวอย่างวิธีใช้แอตทริบิวต์หลังการอนุมัติมีดังนี้

• Block if :address_line1_check: != 'pass' เมื่อใช้กฎนี้ ระบบจะบล็อกการเรียกเก็บเงิน หากการเรียกเก็บเงินนั้นๆ ไม่ผ่านการตรวจสอบโดยบริษัทผู้ออกบัตรในการเทียบที่อยู่ในการเรียกเก็บเงินบรรทัดแรกที่ระบุไว้กับข้อมูลที่มีอยู่ในระบบสำหรับเจ้าของบัตรรายนั้นๆ ซึ่งหมายความว่า หากการตรวจสอบนี้มีค่าเป็น "unavailable" (ไม่พร้อมใช้งาน) หากข้อมูลนี้มีสถานะ "unchecked" (ไม่ได้รับการตรวจสอบ) โดยบริษัทผู้ออกบัตร หรือหากข้อมูลนี้มีสถานะ "not_provided" (ไม่ได้ระบุไว้) โดยบริษัทผู้ออกบัตร ระบบก็จะบล็อกการชำระเงินนั้น
  

ประเภท 2

แอตทริบิวต์มาตรฐาน: ทุกคนใช้แอตทริบิวต์เหล่านี้ได้ คุณต้องใช้เครื่องหมายทวิภาค (:) ขึ้นต้นและลงท้ายแอตทริบิวต์มาตรฐาน เช่น :card_bin: ทั้งนี้ เราได้แบ่งแอตทริบิวต์มาตรฐานออกเป็น 4 ประเภทดังนี้

• แอตทริบิวต์ตามความถี่ - มีประโยชน์ในการป้องกันการทดสอบบัตรหรือการรับเงินสดผ่านบัตร
  
• แอตทริบิวต์ตามรายละเอียดของบัตร
  
• แอตทริบิวต์ตามรายละเอียดการชำระเงิน
  
• แอตทริบิวต์ตามรายละเอียดของลูกค้า
  

แอตทริบิวต์บางรายการต้องมีค่าเป็นสตริง ส่วนแอตทริบิวต์อื่นๆ ก็ต้องมีค่าเป็นตัวเลข เราได้ให้ตัวอย่างสำหรับแอตทริบิวต์แต่ละรายการเพื่อชี้แจงเรื่องนี้ไว้แล้ว หากแอตทริบิวต์ต้องใช้สตริง เช่น :card_bin: คุณจะเห็นได้ในตัวอย่างว่าตัวเลขจะอยู่ภายใน ‘ ’ ตัวอย่างเช่น :card_bin: = ‘424242’ ส่วนแอตทริบิวต์ที่ต้องใช้ตัวเลข ก็จะไม่มี ‘ ’ เช่น :amount_in_usd: > 250

แอตทริบิวต์ตามความถี่

แอตทริบิวต์มีอยู่ 4 ประเภทโดยแบ่งตามความถี่ ซึ่งมีประโยชน์อย่างยิ่งในการป้องกันการฉ้อโกงด้วยบัตรที่ถูกขโมยไป การทดสอบบัตร และการรับเงินสดผ่านบัตร

1. การอนุมัติ: ตามการอนุมัติโดยบริษัทผู้ออกบัตร
   
2. ค่าใช้จ่าย: ตามค่าใช้จ่าย
   
3. การปฏิเสธ: ตามการปฏิเสธโดยบริษัทผู้ออกบัตร
   
4. บล็อก: ตามการบล็อกโดยแมชชีนเลิร์นนิงของ Radar
   

นอกจากนี้ยังมีแอตทริบิวต์ตามผลลัพธ์ในการเรียกเก็บเงิน ได้แก่ การอนุมัติ (ตามการอนุมัติที่สำเร็จโดยบริษัทผู้ออกบัตร) การเรียกเก็บเงิน (ตามจำนวนครั้งในการเรียกเก็บเงิน) การปฏิเสธ (ตามการปฏิเสธโดยบริษัทผู้ออกบัตร) การโต้แย้งการชำระเงิน (ธุรกรรมก่อนหน้านี้ที่ถูกโต้แย้งว่าเป็นการฉ้อโกง) และการบล็อก (ตามการบล็อกโดยแมชชีนเลิร์นนิงของ Radar) ระบบจะรวมผลลัพธ์เข้ากับรายละเอียดของลูกค้า (อีเมล, ที่อยู่ IP, ชื่อ หรือ ID ลูกค้า) เพื่อสร้างแอตทริบิวต์

นอกจากนี้ คุณสามารถรวมความถี่ของรายละเอียดลูกค้า (อีเมล ชื่อ) เข้ากับบัตรหรือที่อยู่ IP ที่ใช้ในการทำธุรกรรมได้ ซึ่งกล่าวได้ว่า กฎความถี่จะมีอยู่ 2 ประเภทดังนี้

1. ตามผลลัพธ์ในการเรียกเก็บเงิน (เช่น authorized_charges_per_email_hourly, blocked_charges_per_email_hourly) ที่มีการอนุมัติเป็นผลสำเร็จ จำนวนครั้งในการเรียกเก็บเงิน การปฏิเสธ การโต้แย้งการชำระเงิน การบล็อก
   
2. ตามความเชื่อมโยงระหว่างข้อมูลลูกค้ากับบัตรหรือ IP (เช่น name_count_for_card_weekly, email_count_for_ip_hourly)
   

กฎความถี่จะไม่รวมการชำระเงินที่คุณกำลังประมวลผลอยู่ เช่น authorized_charges_per_email_hourly แสดงถึงจำนวนครั้งในการเรียกเก็บเงินที่สำเร็จก่อนหน้านี้จากอีเมลนั้นๆ ในช่วง 1 ชั่วโมงก่อนหน้า ดังนั้น หากอีเมลมีการเรียกเก็บเงินเป็นครั้งแรกในชั่วโมงนั้นๆ authorized_charges_per_email_hourly ก็จะมีค่าเป็น 0 หากครั้งแรกสำเร็จ การเรียกเก็บเงินครั้งที่สองภายในชั่วโมงเดียวกันจากอีเมลเดิมก็จะมีค่าเป็น 1 และเป็นเช่นนั้นไปเรื่อยๆ

แอตทริบิวต์ตามรายละเอียดของบัตร

แอตทริบิวต์ตามรายละเอียดการชำระเงิน

แอตทริบิวต์ตามรายละเอียดของลูกค้า

ต่อไปนี้คือตัวอย่างวิธีใช้แอตทริบิวต์มาตรฐาน

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

เมื่อใช้กฎนี้ ระบบจะบล็อกการเรียกเก็บเงินใดๆ จากบัตรที่ออกในแคนาดา เยอรมนี หรือสหรัฐอาหรับเอมิเรตส์

ประเภท 3

แอตทริบิวต์ข้อมูลเมตา: แอตทริบิวต์เหล่านี้จะขึ้นอยู่กับข้อมูลเมตาที่คุณส่งให้กับ Stripe เมื่อใช้แอตทริบิวต์เหล่านี้ คุณจะต้องใช้เครื่องหมายทวิภาคคู่ (::) ขึ้นต้นและลงท้ายแอตทริบิวต์มาตรฐาน เช่น ::Customer Age:: แอตทริบิวต์ข้อมูลเมตาสามารถทำงานเป็นสตริงหรือตัวเลขก็ได้ ซึ่งเมื่อใช้เป็นสตริง แอตทริบิวต์ข้อมูลเมตาก็จะคำนึงถึงอักษรตัวพิมพ์เล็กและตัวพิมพ์ใหญ่

คุณสามารถใช้ข้อมูลเมตาเพื่อสร้างกฎที่มีประสิทธิภาพสูงได้ เช่น การกำหนดให้มีเจ้าหน้าที่ตรวจสอบการเรียกเก็บเงินตาม SKU ที่ซื้อ หรือลดความยุ่งยากให้กับลูกค้าที่กลับมาใช้บริการ หากต้องการดูวิธีส่งข้อมูลเมตาเพิ่มเติม โปรดอ่านคำแนะนำนี้

แอตทริบิวต์ข้อมูลเมตาจะอยู่ในโครงสร้างต่อไปนี้

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

สมมติว่าเรามีการชำระเงินที่มีข้อมูลคีย์-ค่าต่อไปนี้จัดเก็บไว้ในช่องข้อมูลเมตา

คุณสามารถเขียนกฎให้ตรวจสอบการชำระเงินที่ตรงตามเกณฑ์ต่อไปนี้ได้

• Review if ::Customer Age:: < 30
  

คุณยังเขียนกฎโดยใช้ทั้งแอตทริบิวต์ข้อมูลเมตาและแอตทริบิวต์ที่รองรับอื่นๆ ที่กล่าวถึงในเอกสารนี้ได้ด้วย เช่น คุณสามารถเขียนกฎให้ตรวจสอบการชำระเงินก็ต่อเมื่อ Item ID (รหัสรายการ) ตรงกับ 5A381D และยอดการชำระเงินเกิน 1,000 ดอลลาร์สหรัฐได้

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

แอตทริบิวต์ข้อมูลเมตายังรองรับตัวดำเนินการ IN เพื่อจับคู่กับค่าหลายๆ ค่าอีกด้วย เช่น คุณสามารถเขียนกฎให้ตรวจสอบการชำระเงินหาก Category ID (รหัสหมวดหมู่) เป็น "groceries" "electronics" หรือ "clothing" อย่างใดอย่างหนึ่งได้

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

คุณสามารถใช้ตัวดำเนินการ INCLUDES กับกฎต่างๆ สำหรับแอตทริบิวต์ข้อมูลเมตาและแอตทริบิวต์สตริงอื่นๆ เพื่อหารายการที่ตรงกับสตริงย่อยได้ด้วย เช่น คุณสามารถเขียนกฎให้ตรวจสอบการชำระเงินหาก Item ID (รหัสรายการ) มีสตริง A381 ปรากฏอยู่ ได้แก่ "A381", "5A381D", "A381D", "5A381" เป็นต้น

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

คุณยังเข้าถึงข้อมูลเมตาบนออบเจ็กต์ customer และ destination (หากใช้ในการชำระเงินนั้นๆ) ได้ด้วย โดยแอตทริบิวต์เหล่านี้จะอยู่ในโครงสร้างต่อไปนี้

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

สมมติว่าคุณมี customer ที่มีข้อมูลเมตาต่อไปนี้

คุณสามารถเขียนกฎให้อนุญาตการชำระเงินเสมอหากช่องข้อมูลเมตา Trusted ของลูกค้ามีค่าเป็น true ได้

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

หรือหากคุณมี destination ที่มีข้อมูลเมตาต่อไปนี้

คุณสามารถเขียนกฎให้ตรวจสอบการชำระเงินหากช่องข้อมูลเมตา Category ของ destination มีค่าเป็น new

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

การใช้รายการที่บันทึกไว้ในกฎของคุณ (เช่น รายการที่อนุญาต รายการที่บล็อก)

คุณสามารถอ้างอิงค่าต่างๆ ในกฎผ่านรายการที่สร้างไว้ก่อนหน้านี้ได้ (เช่น รายการที่อนุญาตหรือรายการที่บล็อก) หากคุณต้องการจะบล็อกรายชื่ออีเมล คุณก็ควรสร้างรายการที่บล็อกขึ้นมา แทนที่จะสร้างกฎขึ้นมาหลายๆ ข้อสำหรับแต่ละอีเมลที่ต้องการบล็อก

นามแฝงของรายการทั้งหมดที่ใช้ในกฎจะต้องขึ้นต้นด้วย @ ในการสร้างกฎที่อ้างอิงถึงรายการ คุณจะต้องใช้โครงสร้างดังนี้

• {action} [attribute] in [list]
  

เช่น สมมติว่าคุณมีรายชื่อประเทศของบัตรที่คุณต้องการจะบล็อก คุณสามารถเขียนกฎโดยใช้เงื่อนไข OR หลายๆ ข้อ ดังนี้

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

คุณยังเขียนกฎโดยใช้รายการแบบอินไลน์ได้ด้วย ดังนี้

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

นอกจากนี้ คุณยังสร้างรายชื่อประเทศของบัตรที่คุณต้องการจะบล็อกโดยตั้งชื่อว่า card_countries_to_block ได้อีกด้วย จากนั้นคุณก็เพิ่มประเทศที่ต้องการลงในรายการและอ้างอิงถึงรายการนี้ในกฎได้ ดังนี้

• Block if :card_country: in @card_countries_to_block
  

กฎที่ใช้รายการไม่เพียงแต่จะสั้นกระชับมากขึ้น แต่ยังแก้ไขและเพิ่มรายการจำนวนมากลงไปได้ง่ายขึ้นมากๆ อีกด้วย

เขียนกฎที่ซับซ้อนซึ่งมีเงื่อนไขหลายอย่าง

คุณสร้างเงื่อนไขที่ซับซ้อนได้ด้วยการนำเงื่อนไขพื้นฐานต่างๆ มารวมเข้าด้วยกัน โดยใช้ตัวดำเนินการต่างๆ ได้แก่ AND, OR และ NOT คุณยังใช้สัญลักษณ์ที่ใช้แทนกันได้ด้วย ซึ่งก็คือ &&, || และ ! ตามลำดับ Stripe มีการจัดลำดับความสำคัญ (ลำดับการดำเนินการ) ของตัวดำเนินการตามมาตรฐานเช่นเดียวกับภาษาต่างๆ ในการเขียนโปรแกรม เช่น C, Python และ SQL เช่น เงื่อนไขที่ซับซ้อนว่า

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

จะได้รับการตีความในรูปแบบ

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

ระบบยังรองรับการใช้วงเล็บเพื่อจัดกลุ่มเงื่อนไขย่อยภายในเงื่อนไขที่ซับซ้อนอีกด้วย เช่น คุณสามารถแก้ไขตัวอย่างก่อนหน้านี้ให้เปลี่ยนลำดับการประเมินคำสั่งรองต่างๆ อย่างชัดเจนได้ ดังนี้

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

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

เมื่อใช้วงเล็บคนละที่กัน เงื่อนไขที่ซับซ้อนเหล่านี้ก็จะให้ผลลัพธ์ที่แตกต่างกัน

คุณยังใช้ฟังก์ชัน is_missing ในคำเชื่อม OR หรือ AND ได้ด้วย ดังนี้

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

หรือคุณจะใช้ฟังก์ชัน is_missing เมื่อมีการระบุข้อมูลดังกล่าวก็ได้ ซึ่งในกรณีนี้ ระบบจะบล็อกหาก "ไม่" ได้ระบุ :ip_country: และ IP มาจาก US หรือ PR

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

กฎการทดสอบย้อนหลัง

ตามหลักทั่วไปในการวิเคราะห์กฎแล้ว เราจะต้องหาจุดกึ่งกลางระหว่างการป้องกันการฉ้อโกงกับการบล็อกธุรกรรมที่ไม่ได้ผิดอะไรหรือการรายงานทั้งที่ไม่ได้เกิดปัญหา การทดสอบย้อนหลังจะช่วยกำหนดกฎให้มีความเสี่ยงเท่าที่คุณยอมรับได้ หรือหาจุดลงตัวได้อย่างพอดิบพอดีระหว่างการโต้แย้งการชำระเงินที่ป้องกันได้กับการรายงานทั้งที่ไม่ได้เกิดปัญหาที่เพิ่มขึ้น หากต้องการประเมินผลลัพธ์ของกฎ คุณสามารถทดสอบย้อนหลังกับกฎต่างๆ ได้โดยใช้ข้อมูลธุรกรรมในช่วง 6 เดือนที่ผ่านมาผ่านแดชบอร์ด Radar และทำการวิเคราะห์ที่ตรงเป้ามากขึ้นเพื่อทำความเข้าใจว่ากฎน่าจะให้ผลเช่นไรหากนำไปใช้ในช่วงที่ผ่านมา

การทดสอบย้อนหลังในแดชบอร์ด

คำจำกัดความของการฉ้อโกงและการชำระเงินที่สำเร็จอื่นๆ จะแตกต่างกันไปตามประเภทกฎที่คุณกำลังทดสอบ

กฎ Block

• มีการโต้แย้งการชำระเงิน ได้รับคำเตือนว่าอาจเป็นการฉ้อโกง หรือมีการคืนเงินเนื่องจากเป็นการฉ้อโกง: การเรียกเก็บเงินที่สำเร็จซึ่งมีการโต้แย้งหรือคืนเงินเนื่องจากเป็นการฉ้อโกงหรือการเรียกเก็บเงินที่สำเร็จซึ่งได้รับการตรวจสอบและมีการโต้แย้งหรือคืนเงินเนื่องจากเป็นการฉ้อโกง

• การชำระเงินที่สำเร็จอื่นๆ: การเรียกเก็บเงินที่สำเร็จซึ่งไม่มีการโต้แย้งหรือคืนเงินเนื่องจากเป็นการฉ้อโกงหรือการเรียกเก็บเงินที่สำเร็จซึ่งได้รับการตรวจสอบและไม่มีการโต้แย้งหรือคืนเงินเนื่องจากเป็นการฉ้อโกง

• การพยายามชำระเงินที่ไม่สำเร็จ: ถูกปฏิเสธโดยบริษัทผู้ออกบัตรหรือถูกบล็อกโดย Radar

กฎ Review

• มีการโต้แย้งการชำระเงิน ได้รับคำเตือนว่าอาจเป็นการฉ้อโกง หรือมีการคืนเงินเนื่องจากเป็นการฉ้อโกง: การเรียกเก็บเงินที่สำเร็จซึ่งมีการโต้แย้งหรือคืนเงินเนื่องจากเป็นการฉ้อโกง

• การชำระเงินที่สำเร็จอื่นๆ: การเรียกเก็บเงินที่สำเร็จซึ่งไม่มีการโต้แย้งหรือคืนเงินเนื่องจากเป็นการฉ้อโกง

• ไม่สำเร็จหรือเข้ารับการตรวจสอบแล้ว: ถูกปฏิเสธโดยบริษัทผู้ออกบัตร บล็อกโดย Radar หรือการเรียกเก็บเงินที่สำเร็จซึ่งได้รับการตรวจสอบ (โดยไม่คำนึงถึงสถานะการโต้แย้งการชำระเงินหรือการคืนเงิน)

กฎ Allow

• ถูกบล็อกโดย Stripe หรือกฎที่กำหนดเองของคุณ: การเรียกเก็บเงินที่ถูกบล็อกโดย Radar

• มีการโต้แย้งการชำระเงิน ได้รับคำเตือนว่าอาจเป็นการฉ้อโกง หรือมีการคืนเงินเนื่องจากเป็นการฉ้อโกง: การเรียกเก็บเงินที่สำเร็จซึ่งมีการโต้แย้งหรือคืนเงินเนื่องจากเป็นการฉ้อโกงหรือการเรียกเก็บเงินที่สำเร็จซึ่งได้รับการตรวจสอบและมีการโต้แย้งหรือคืนเงินเนื่องจากเป็นการฉ้อโกง

• การชำระเงินที่สำเร็จหรือถูกธนาคารปฏิเสธอื่นๆ: ถูกปฏิเสธโดยบริษัทผู้ออกบัตร การเรียกเก็บเงินที่สำเร็จซึ่งไม่มีการโต้แย้งหรือคืนเงินเนื่องจากเป็นการฉ้อโกง หรือการเรียกเก็บเงินที่สำเร็จซึ่งได้รับการตรวจสอบและไม่มีการโต้แย้งหรือคืนเงินเนื่องจากเป็นการฉ้อโกง

การดำเนินการวิเคราะห์การทดสอบย้อนหลังแบบกำหนดเอง

ฟีเจอร์การทดสอบย้อนหลังในแดชบอร์ด Radar จะเน้นที่ธุรกรรมในช่วง 6 เดือนที่ผ่านมา และมีการโต้แย้งการชำระเงิน คำเตือนว่าอาจเป็นการฉ้อโกง และการเรียกเก็บเงินที่มีการคืนเงินเนื่องจากเป็นการฉ้อโกง

คุณอาจต้องการวิเคราะห์ให้ตรงเป้ามากขึ้นหากคุณเสี่ยงที่จะได้รับการระบุอยู่ในโปรแกรมตรวจสอบการฉ้อโกงของ Visa (ซึ่งเน้นที่คำเตือนว่าอาจเป็นการฉ้อโกงเท่านั้น) หรือคุณสังเกตเห็นว่ามีการฉ้อโกงเพิ่มสูงขึ้นในช่วงไม่นานมานี้จากประเทศ IP หรือประเภทกระเป๋าเงินอย่างใดอย่างหนึ่งเป็นพิเศษ ในการวิเคราะห์ให้ตรงเป้ามากขึ้น คุณสามารถสร้างคำขอ SQL ใน Stripe Sigma หรือส่งออกและวิเคราะห์รายงานข้อมูลการชำระเงินในแดชบอร์ดได้ การทดสอบย้อนหลังแบบกำหนดเองจะช่วยให้กรอบเวลาที่ยืดหยุ่น (เกินหกเดือน) และมีการวิเคราะห์ที่ตรงเป้ามากขึ้น (เช่น คุณสามารถมุ่งเน้นที่การโต้แย้งการชำระเงินหรือ EFW เป็นการเฉพาะได้) ตัวอย่างคำขอด้านล่างนี้จะเป็นการทดสอบย้อนหลังกับคำเตือนว่าอาจเป็นการฉ้อโกง (EFW) ของ Visa จากธุรกรรมที่มีมูลค่ามากกว่า 100 ดอลลาร์สหรัฐ หากคุณพบว่าช่วงนี้การฉ้อโกงมีจำนวนเพิ่มขึ้นในส่วนที่มีมูลค่าสูงขึ้นและธุรกรรมที่มีคะแนนความเสี่ยงสูงขึ้นนั้นนำมาซึ่งความเสี่ยงในโปรแกรมการตรวจสอบ

Using fields and tables available in Stripe 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

การทดสอบย้อนหลังในช่วง 60 วันที่ผ่านมาตามวันที่สร้าง EFW จะช่วยในการตรวจจับการฉ้อโกงที่เกิดขึ้นล่าสุด ส่วนการทดสอบย้อนหลังกับการขายที่ไม่เข้าข่ายฉ้อโกงหลังผ่านไปแล้ว 60-120 วันก็จะช่วยให้เห็นภาพรวมของการฉ้อโกงได้ชัดเจนยิ่งขึ้น

วิธีการฉ้อโกงที่พบได้ทั่วไป

มิจฉาชีพส่วนใหญ่จะใช้วิธีการฉ้อโกงแบบเดียวกัน ก่อนอื่น มิจฉาชีพจะตรวจสอบข้อมูลการชำระเงินที่ขโมยมา (เช่น บัตร) เมื่อตรวจสอบแล้วว่าใช้งานได้จริง ก็จะใช้ข้อมูลประจำตัวเหล่านี้เพื่อหาประโยชน์ในรูปของสินค้าที่จับต้องได้สำหรับใช้ส่วนตัวหรือนำไปขายต่อ (สินค้าหรูหราหรืออิเล็กทรอนิกส์) บริการสำหรับใช้ส่วนตัวหรือนำไปขายต่อ (บริการจัดส่งอาหาร) หรือบริการและผลิตภัณฑ์ที่ช่วยในการฉ้อโกงเพิ่มเติม (เช่น บริการเว็บโฮสติ้ง บริการสแปมข้อความ ฯลฯ)

อ่านรายละเอียดเพิ่มเติมเกี่ยวกับวิธีการฉ้อโกงที่พบบ่อยที่สุดและวิธีที่แนะนำในการใช้กฎของ Radar เพื่อลดปัญหาเหล่านี้

การทดสอบ

การทดสอบบัตรจะเกิดขึ้นเมื่อมิจฉาชีพใช้สคริปต์หรือกระบวนการที่ลงมือทำด้วยตนเองแบบต่างๆ เพื่อทดสอบว่าหมายเลขบัตรที่ขโมยมาและยังไม่ผ่านการตรวจสอบนั้นยังคงใช้ได้อยู่หรือไม่ การฉ้อโกงในขั้นตอนนี้ยังไม่ใช่การเอาสินค้าที่จับต้องได้หรือบริการ แต่เป็นการตรวจสอบว่าบัตรใบนั้นๆ ยังใช้ได้อยู่ การทดสอบเหล่านี้มักจะใช้กับธุรกรรมที่มีจำนวนเงินน้อยๆ หรือการอนุมัติ โดยการทดสอบมักจะเกิดขึ้นติดๆ กันอย่างรวดเร็ว แอตทริบิวต์ที่อาจเป็นประโยชน์ก็คือฟีเจอร์ในการจัดกลุ่มและความเร็ว เช่น

• total_charges_per_customer

• card_count_for_email

• card_count_for_ip_address

• total_charges_per_ip

มิจฉาชีพมักจะพยายามหลบเลี่ยงการตรวจจับเหล่านี้โดยการสร้างอีเมลปลอมและใช้อีเมลที่ต่างออกไป มิจฉาชีพที่ชำนาญขึ้นก็จะปกปิดที่อยู่ IP หรือแม้กระทั่งใช้อุปกรณ์หลายเครื่องเพื่อให้ข้อมูลอุปกรณ์ที่ไม่ซ้ำกัน เมื่อถึงจุดนั้น การเข้าใจพฤติกรรมของลูกค้าที่ดีและเป็นปกติทั่วไปจึงเป็นเรื่องสำคัญ ฟีเจอร์ต่างๆ เช่น โดเมนอีเมลและประเทศ IP รวมถึงหมวดหมู่อื่นๆ ที่กว้างขึ้น จะช่วยระบุธุรกรรมที่มีความเสี่ยงสูงขึ้นได้ ลูกค้าที่ฉ้อโกงจำนวนมากจะใช้โดเมนอีเมลยอดนิยมจากผู้ให้บริการอีเมลซึ่งเป็นที่ยอมรับ เช่น gmail.com คุณจึงอาจพบเห็นโดเมนต่างๆ เช่น gmail.comms หรือ gomail.co ซึ่งพยายามปกปิดตัวตนของมิจฉาชีพ คุณยังใช้ประเทศของบัตรและประเทศ IP เพื่อช่วยแบ่งกลุ่มลูกค้าและช่วยทำให้แน่ใจว่าธุรกรรมมาจากพื้นที่ซึ่งพบได้ทั่วไปในหมู่ฐานผู้ใช้ของคุณได้ ธุรกรรมที่เกิดขึ้นนอกสถานที่เหล่านี้อาจจำเป็นต้องได้รับการตรวจสอบหรือบล็อกไป

ฟังก์ชันสุดท้ายอย่างหนึ่งในการควบคุมพฤติกรรมการทดสอบนี้ก็คือการใช้ CAPTCHA

ใน Stripe Checkout ระบบจะแสดงคำถามตรวจสอบสิทธิ์แบบ CAPTCHA ขึ้นมาโดยอัตโนมัติเมื่อแมชชีนเลิร์นนิงตรวจพบการโจมตีด้วยการทดสอบบัตร ในการลดการทดสอบบัตร Stripe จะใช้การควบคุมจากระบบอัตโนมัติและเจ้าหน้าที่ร่วมกัน ได้แก่ ขีดจำกัดอัตรา การแจ้งเตือน และการตรวจสอบอย่างต่อเนื่องควบคู่ไปกับการฝึกโมเดลการทดสอบบัตรให้ตรวจจับการโจมตีโดยอัตโนมัติ โมเดลเหล่านี้จะแสดงคำถามตรวจสอบสิทธิ์ก็ต่อเมื่อมีการโจมตีด้วยการทดสอบบัตรเท่านั้น ผู้ใช้ที่มีตัวตนจริงจึงแทบไม่เคยเห็น CAPTCHA เลย มีเพียงบอทเท่านั้นที่จะได้เห็น วิธีนี้ช่วยลดการทดสอบบัตรให้กับธุรกิจที่ใช้ Stripe Checkout ได้มากถึง 80% โดยพบผลกระทบต่ออัตราการเปลี่ยนเป็นลูกค้าน้อยมากหรือไม่มีเลย

โปรดทราบว่า คุณยังเขียนกฎที่กำหนดเองได้เช่นกัน เช่น "บล็อกหากถูกปฏิเสธมากกว่า 3 ครั้งจากที่อยู่ IP นั้นๆ" เพื่อลดการโจมตีด้วยการทดสอบบัตร

การหาประโยชน์

บัตรเครดิตที่ถูกขโมยไป (พฤติกรรมแบบใหม่)

ในการฉ้อโกงลักษณะนี้ มิจฉาชีพจะใช้บัตรที่ขโมยมาและผ่านการตรวจสอบแล้วบนอุปกรณ์ส่วนตัวของตนหรืออุปกรณ์ที่ใช้ในการฉ้อโกง

คนร้ายมักใช้วิธีนี้ผ่านการโจมตีแบบวงกว้างด้วยสคริปต์หรือการโจมตีในวงแคบลงโดยมีการกำหนดกลุ่มและพื้นที่ของเหยื่อแบบตรงเป้ามากขึ้น แต่ไม่ว่าคนร้ายจะมาด้วยวิธีไหน การใช้แอตทริบิวต์กฎที่วัดความใหม่ของบัญชีบน Stripe เช่น hours_since_email_first_seen_on_stripe ร่วมกับ risk_score และฟีเจอร์อื่นๆ ก็จะช่วยให้ตรวจจับผู้ถือบัตรรายใหม่ๆ เหล่านี้ได้ นอกจากนี้ การจำกัดความเร็วของ IP, อีเมล และบัตรยังช่วยปกป้องผู้ค้าจากการโจมตีต่อเนื่องหลายครั้งอีกด้วย ซึ่งเป็นรูปแบบที่มิจฉาชีพพยายามเอาเงินจากข้อมูลประจำตัวที่ขโมยมาให้ได้เร็วที่สุด

บัตรเครดิตที่ถูกขโมยไป (พฤติกรรมในการปกปิด)

ในการฉ้อโกงลักษณะนี้ มิจฉาชีพจะใช้บัตรที่ขโมยมาและผ่านการตรวจสอบแล้วบนอุปกรณ์ส่วนตัวของตนหรืออุปกรณ์ที่ใช้ในการฉ้อโกงหรือมิจฉาชีพได้บุกรุกเข้าไปในบัญชีที่มีการชำระเงินตามรอบบิล และเข้าถึงข้อมูลบัตรเครดิตที่จัดเก็บไว้ในบัญชีนั้นๆ

มิจฉาชีพจะพยายามปกปิดตัวตนของตัวเองอย่างเต็มที่ด้วยวิธีการต่างๆ ดังนี้

• การใช้ชื่อเดียวกับธุรกรรมที่ทำไปก่อนหน้านี้

• การใช้ที่อยู่ในการเรียกเก็บเงินเดียวกับธุรกรรมที่ทำไปก่อนหน้านี้

• การใช้ VPN เพื่อพยายามให้ดูเหมือนว่าตนเป็นเจ้าของบัตรตัวจริง มิจฉาชีพอาจใช้ VPN เพื่อสวมรอยว่าอยู่ในเมืองเดียวกัน และในบางครั้งก็อยู่บนถนนเดียวกันเลยด้วย

• การเปลี่ยนเฉพาะรายละเอียดเล็กๆ น้อยๆ เช่น ที่อยู่อีเมลหรือหมายเลขโทรศัพท์

• การเปลี่ยนที่อยู่สำหรับจัดส่งจากธุรกรรมก่อนหน้านี้สำหรับสินค้าที่จับต้องได้ โดยที่อยู่ในการเรียกเก็บเงินกับที่อยู่สำหรับจัดส่งอาจอยู่ห่างไกลกันมาก ซึ่งข้อมูลนี้ก็ช่วยเป็นสัญญาณเตือนได้คร่าวๆ

พฤติกรรมการปกปิดที่อธิบายมาข้างต้นทำให้ระบุตัวผู้ทำธุรกรรมที่แท้จริงได้ยาก ซึ่งอาจจะเป็นเจ้าของบัตรตัวจริงหรือมิจฉาชีพที่บุกรุกเข้าบัญชีมาก็ได้ การฉ้อโกงประเภทนี้จึงมักจะเล็ดลอดการตรวจจับไปได้เป็นเวลานาน ทั้งจากผู้ค้าและเจ้าของบัตรตัวจริง

กลยุทธ์ในส่วนนี้ก็เหมือนเดิม นั่นคือ มิจฉาชีพจะพยายามหาประโยชน์จากข้อมูลประจำตัวที่ขโมยมาให้ได้มากที่สุด กฎที่ใช้ฟีเจอร์จำกัดความเร็วร่วมกับ riskscore, การทำ cvccheck ไม่สำเร็จ หรือการตรวจสอบ zip ไม่สำเร็จก็จะช่วยป้องกันการฉ้อโกงรูปแบบนี้ได้

แนวทางปฏิบัติที่ดีที่สุดอื่นๆ

แนวทางปฏิบัติที่ดีที่สุดเพิ่มเติมที่จะช่วยให้คุณเขียนกฎใน Radar ได้มีประสิทธิภาพสูงสุดมีดังนี้

ความสำคัญของการใช้ Stripe.js

• ใส่ stripe.js เอาไว้ตลอดเส้นทางการชำระเงิน เพื่อให้มีการแจ้งเตือนการฉ้อโกงอย่างเต็มรูปแบบ
  
• หากต้องการใช้ Radar ให้เกิดประโยชน์สูงสุดโดยไม่ส่งผลกระทบต่อเวลาในการโหลดหน้า ให้โหลด stripe.js async ในหน้าต่างๆ ที่ไม่ใช่การชำระเงิน
  
• วางถัดจากแท็กสคริปต์ Google Analytics ได้ง่ายที่สุด
  
• ขนาดบันเดิล stripe.js แบบเต็มอยู่ที่ 29.6 kb ในรูปแบบ gzip
  
  • สถานะในอนาคต: คุณจะสามารถใส่ radar.js แยกต่างหากจาก stripe.js ได้
    

บทสรุป

กฎอาจเป็นเครื่องมือที่มีประสิทธิภาพยอดเยี่ยมในการช่วยคุณปรับแต่งระบบป้องกันการฉ้อโกง เมื่อใช้ตรรกะที่ไม่เหมือนใครจากแนวทางปฏิบัติที่ดีที่สุดบางประการที่ระบุไว้ในคู่มือนี้ คุณก็จะสามารถสร้างการตั้งค่าการป้องกันการฉ้อโกงใน Radar ที่เหมาะกับความต้องการทางธุรกิจของคุณโดยเฉพาะได้

หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับ Radar for Fraud Teams โปรดดูที่นี่

หากคุณใช้ Radar for Fraud Teams อยู่แล้ว โปรดดูหน้ากฎในแดชบอร์ดของคุณเพื่อเริ่มการเขียนกฎ

หมายเหตุอื่นๆ

Radar สำหรับแพลตฟอร์ม

คุณเป็นแพลตฟอร์มที่ใช้ Stripe Connect หรือไม่ หากใช่ กฎที่คุณสร้างขึ้นจะมีผลกับการชำระเงินที่เกิดขึ้นบนบัญชีแพลตฟอร์มเท่านั้น (Connect เรียกการเรียกเก็บเงินเหล่านี้ว่าเป็นแบบปลายทางหรือในนาม)
การชำระเงินที่เกิดขึ้นในบัญชีที่เชื่อมโยงโดยตรงจะต้องเป็นไปตามกฎของบัญชีนั้น

Radar สำหรับ Terminal

Radar จะไม่คัดกรองการเรียกเก็บเงินจาก Terminal ซึ่งหมายความว่าหากคุณใช้ Terminal คุณก็สามารถเขียนกฎตามความถี่ของ IP ได้โดยไม่ต้องกังวลเรื่องการบล็อกการชำระเงินที่จุดขาย