Aturan
Aturan pencegahan penipuan memungkinkan Anda untuk mengambil tindakan kapan pun pembayaran sesuai dengan kriteria tertentu.
Stripe Radar menyediakan aturan bawaan untuk membantu mendeteksi dan menjaga dari risiko penipuan bagi semua pengguna Stripe.
Pengguna Radar for Fraud Teams dapat menggunakan Dashboard untuk membuat aturan custom berdasarkan logika bisnis unik yang spesifik untuk bisnis Anda. Sebagai contoh, Anda dapat:
- Meminta 3D Secure untuk semua pembayaran yang mendukungnya dan dibuat oleh pelanggan baru
- Mengizinkan semua pembayaran dari alamat IP pusat layanan pelanggan Anda
- Memblokir pembayaran yang dibuat dari suatu lokasi atau dari kartu yang diterbitkan dari luar negara Anda
- Menolak semua pembayaran yang lebih besar daripada USD1.000 yang telah dibuat dengan kartu prabayar
Peringatan
Merchant Uni Eropa mungkin terpengaruh oleh Regulasi Pemblokiran Geografis dan larangannya untuk memblokir pembayaran dari pelanggan yang berbasis di negara anggota Uni Eropa.
Aturan bawaan
Aturan berikut ini diaktifkan secara default untuk semua pengguna Radar.
Pemeriksaan risiko oleh pembelajaran mesin
Stripe Radar dan Stripe Radar for Fraud Teams menyediakan seperangkat aturan default berdasarkan pertimbangan model pembelajaran mesin kami, yaitu:
Block if :risk_level: =
'highest'
Aturan ini akan memblokir dan tidak akan memroses pembayaran dengan risiko penipuan tinggi. Aturan ini diaktifkan secara default bagi pengguna Radar atau Radar for Fraud Teams.
Review if :risk_level: =
'elevated'
Perilaku default bagi Stripe Radar untuk Fraud Teams adalah untuk menempatkan pembayaran ke dalam tinjauan yang kita curigai memiliki peningkatan risiko penipuan.
Pemeriksaan kartu tradisional
Pembayaran tetap dapat berhasil sekalipun pemeriksaan CVC atau (AVS) alamat gagal, karena penerbit kartu mempertimbangkan banyak sinyal ketika mengambil keputusan tentang apakah akan menyetujui atau menolak pembayaran. Dalam beberapa peristiwa, penerbit kartu mungkin tetap menyetujui pembayaran yang mereka anggap sah, sekalipun pemeriksaan verifikasi CVC atau kode pos gagal.
Stripe memiliki aturan bawaan agar Anda dapat memblokir pembayaran meskipun jika pembayaran itu telah disetujui oleh penerbit kartu. Aturan ini dapat diaktifkan atau dinonaktifkan menggunakan Dashboard Stripe.
Aturan ini juga berlaku pada proses validasi kartu yang terjadi ketika melampirkan kartu ke pelanggan. Dalam hal Anda membuat kartu dan pelanggan bersama, kegagalan validasi CVC atau kode pos akan mencegah berhasilnya pembuatan catatan pelanggan. Aturan ini mungkin tidak diaktifkan untuk akun Anda secara default. Anda dapat mengaktifkan atau menonaktifkannya kapan saja menggunakan Dashboard Stripe.
Blokir jika verifikasi CVC gagal
Stripe memblokir pembayaran yang gagal dalam pemeriksaan verifikasi CVC dari penerbit kartu. Jika pelanggan tidak menyediakan nomor CVC, misalnya karena menggunakan dompet digital, atau penerbit kartu mereka tidak mendukung verifikasinya, maka aturan tersebut tidak dapat memblokir pembayaran.
Blokir jika verifikasi kode pos gagal
Stripe memblokir pembayaran saat pemeriksaan verifikasi kode pos penerbit gagal. Jika pelanggan tidak memberikan kode pos, atau penerbit kartu tidak mendukung verifikasinya, maka aturan tidak dapat memblokir pembayaran. Aturan ini mungkin tidak diaktifkan untuk akun Anda secara default. Anda dapat mengaktifkan atau menonaktifkannya kapan saja menggunakan Dashboard Stripe.
Aturan bawaan untuk meminta 3D Secure
Menggunakan 3D Secure meminta pelanggan untuk menyelesaikan langkah autentikasi tambahan sebelum mereka dapat menyelesaikan alur pembelian. Jika 3D Secure mengautentikasi pembayaran, pertanggungjawaban untuk setiap sengketa terkait penipuan bagi pembayaran tersebut biasanya beralih dari penjual ke penerbit. Ini berarti bahwa dalam banyak kasus, penjual tidak bertanggung jawab atas biaya penipuan pada pembayaran terautentikasi 3D Secure.
Stripe secara otomatis menangani kode penolakan lunak yang mengindikasikan bahwa 3DS diperlukan oleh penerbit. Kami juga memicu 3DS jika diperlukan, mengikuti peraturan seperti Autentikasi Pelanggan yang Kuat (SCA) yang diamanatkan oleh PSD2. Menonaktifkan Radar tidak mencegah 3D Secure dipicu jika diperlukan.
Stripe menyediakan tiga aturan default nonaktif yang dapat Anda aktifkan untuk meminta 3DS secara dinamis saat menggunakan Radar dengan Payment Intents atau Setup Intents:
Minta 3D Secure jika 3D Secure dibutuhkan untuk kartu
- Dinonaktifkan secara default. Mengaktifkan aturan ini akan meminta pelanggan melakukan autentikasi 3D Secure jika secara historis kartu mewajibkan 3D Secure.
- Stripe secara otomatis menangani kode penolakan lunak yang mengindikasikan bahwa 3DS diperlukan oleh penerbit. Selain itu, kami juga memicu 3DS jika diperlukan, mengikuti peraturan seperti Autentikasi Pelanggan yang Kuat yang diamanatkan oleh PSD2.
Minta 3D Secure jika 3D Secure didukung untuk kartu
- Dinonaktifkan secara default tetapi serupa dengan aturan sebelumnya. Mengaktifkan aturan ini akan meminta pelanggan melakukan autentikasi 3D Secure sepanjang kartu mereka membolehkannya.
- Gunakan aturan ini sebagai ganti aturan sebelumnya jika Anda ingin memaksimalkan jumlah pembayaran yang memiliki pengalihan pertanggungjawaban. Ketahuilah bahwa persyaratan tambahan ini dapat menurunkan rasio konversi.
Minta 3D Secure jika 3D Secure direkomendasikan untuk kartu
- Dinonaktifkan secara default. Mengaktifkan aturan ini akan meminta pelanggan melakukan autentikasi 3D Secure jika Stripe meyakini bahwa autentikasi 3D Secure dapat diimplementasikan dengan dampak minimal pada rasio konversi.
- Aktifkan ini jika Anda ingin memaksimalkan jumlah pembayaran yang memiliki pengalihan pertanggungjawaban.
Karena 3D Secure mewajibkan pelanggan Anda untuk melewati lapisan autentikasi tambahan, penggunaan 3D Secure secara sembarangan dapat menurunkan rasio konversi. Stripe menyarankan agar Anda mengaktifkan aturan Minta 3D Secure default hanya jika Anda perlu mengirim semua pembayaran dari kartu yang didukung melalui 3D Secure.
Meminta 3D Secure tidak selalu berarti penerbit benar-benar melakukan 3D Secure. Untuk detail selengkapnya tentang kemungkinan hasil, lihat dokumentasi 3D Secure.
Aturan khusus untuk meminta 3D Secure dan bertindak berdasarkan hasil tertentu
Setelah mencoba autentikasi 3D Secure, jika Anda memiliki Radar for Fraud Teams, Anda dapat mengevaluasi hasilnya dalam aturan izinkan, blokir, atau tinjau.
Atribut yang paling penting untuk aturan Radar custom adalah:
is_3d_secure
yang bernilai true jika kartu tersebut didukung, 3D Secure telah dicoba oleh penerbit dan pengguna tidak gagal autentikasi. Kami umumnya merekomendasikan penggunaan ini dalam aturan blokir.is_3d_secure_authenticated
yang bernilai true jika 3D Secure dicoba oleh penerbit dan pengguna berhasil melalui autentikasi penuh. Penggunaan atribut ini dalam aturan blokir mengecualikan transaksi sah yang mungkin memiliki pembebasan SCA atau tidak termasuk dalam kegagalan yang jelas atau autentikasi yang berhasil seperti kesalahan pemrosesan.has_liability_shift
yang bernilai true jika Stripe memperkirakan pembayaran tersebut ditanggung berdasarkan aturan pengalihan pertanggungjawaban. Hal ini mungkin tidak selalu sama dengan 3D Secure, misalnya Apple Pay di wilayah tertentu.
Untuk aturan custom, kami merekomendasikan untuk tetap menyelaraskan aturan Minta 3D Secure
dan Blokir
bergantung pada toleransi risiko Anda. Namun, jangan blokir transaksi di mana 3D Secure tidak didukung, seperti sebagian dompet digital.
Berikut ini beberapa contoh yang menunjukkan cara mencapai hal ini untuk kasus penggunaan yang berbeda:
Minta 3D Secure berdasarkan tingkat risiko Radar
Anda ingin menggunakan Radar untuk meminta 3D Secure atas semua charge berdasarkan tingkat risiko Radar dan di atas jumlah tertentu.
Aturan radar | Deskripsi |
---|---|
Request 3D Secure if :risk_level: != | Aturan ini memeriksa tingkat risiko Radar, kemudian meminta 3D Secure atas semua charge dengan tingkat risiko yang meningkat atau tinggi di atas jumlah tertentu. |
Dalam kasus ini, tanpa aturan blokir, kartu atau dompet digital yang tidak mendukung 3D Secure tidak akan diblokir. Upaya 3D Secure dengan autentikasi yang gagal tidak akan terus men-charge otorisasi.
Selalu wajibkan 3D Secure berdasarkan tingkat risiko Radar
Anda ingin menggunakan Radar untuk meminta 3D Secure atas semua charge berdasarkan tingkat risiko Radar yang meningkat atau berisiko tinggi dan di atas jumlah tertentu. Jika kartu tidak mendukung 3D Secure, maka Anda tidak dapat menerimanya.
Aturan radar | Deskripsi |
---|---|
Request 3D Secure if :risk_level: != | Aturan ini memeriksa tingkat risiko Radar, kemudian meminta 3D Secure atas semua charge dengan tingkat risiko yang meningkat atau tinggi di atas jumlah tertentu. |
Block if not :is_3d_secure: and :risk_level: != | Aturan ini memblokir pembayaran tanpa alur 3D Secure untuk charge dengan tingkat risiko yang meningkat atau tinggi di atas jumlah tertentu. Namun, ini menerima transaksi sah yang mungkin memiliki pembebasan SCA atau tidak memiliki kegagalan yang jelas atau autentikasi yang berhasil seperti attempt_acknowledged . Ini menerima pembayaran di-luar sesi seperti charge langganan rutin dan dompet digital seperti Apple Pay atau Google Pay agar berhasil. |
Hanya terima transaksi yang diautentikasi 3D Secure sepenuhnya, jika didukung 3D Secure
Anda mengandalkan Stripe untuk memicu 3D Secure saat diperlukan dalam kasus seperti Autentikasi Pelanggan yang Kuat (SCA), tetapi tidak ingin menerima kasus unik, seperti kesalahan pemrosesan.
Aturan radar | Deskripsi |
---|---|
Blokir if :is_3d_secure: dan bukan :is_3d_secure_authenticated: | Aturan ini memblokir pembayaran yang kartunya terdaftar dalam 3D Secure dan 3D Secure telah dicoba tetapi pengguna tidak berhasil melakukan autentikasi. Kartu yang tidak mendukung 3D Secure, pembebasan SCA, pembayaran di-luar sesi, seperti charge langganan rutin, dan dompet digital, seperti Apple Pay atau Google Pay, dapat diterima. |
Minta 3D Secure berdasarkan Metadata
Anda ingin menggunakan Radar untuk meminta 3D Secure atas semua charge dengan atribut metadata custom.
Aturan radar | Deskripsi |
---|---|
Request 3D Secure if ::foo:: = | Aturan ini memeriksa syarat metadata, kemudian meminta 3D Secure. Untuk memeriksa metadata Pelanggan, ganti ::foo:: = 'bar' dengan nilai seperti ::customer:trusted:: = 'false' . |
Dalam kasus ini, tanpa aturan blokir, kartu atau dompet digital yang tidak mendukung 3D Secure tidak akan diblokir. Upaya 3D Secure dengan autentikasi yang gagal tidak akan terus men-charge otorisasi.
Selalu wajibkan 3D Secure berdasarkan Metadata
Anda ingin menggunakan Radar untuk meminta 3D Secure atas semua charge dengan atribut metadata custom dan memblokir kartu yang tidak mendukungnya.
Aturan radar | Deskripsi |
---|---|
Request 3D Secure if ::foo:: = | Aturan ini memeriksa syarat metadata, kemudian meminta 3D Secure. Untuk memeriksa metadata Pelanggan, ganti ::foo:: = 'bar' dengan nilai seperti ::customer:trusted:: = 'false' . |
Block if ::foo:: = | Aturan ini memblokir pembayaran tanpa alur 3D Secure untuk charge dengan atribut metadata custom. Namun, ini menerima transaksi sah yang mungkin memiliki pembebasan SCA atau tidak memiliki kegagalan yang jelas atau autentikasi yang berhasil seperti attempt_acknowledged . Ini menerima pembayaran di-luar sesi seperti charge langganan rutin dan dompet digital seperti Apple Pay atau Google Pay agar berhasil. |
Minta 3D Secure untuk semua kartu baru dan tinjau apakah 3D Secure tidak didukung
Anda ingin menggunakan Radar untuk meminta 3D Secure atas semua kartu baru dan secara manual meninjau charge dari kartu yang tidak mendukung 3D Secure.
Aturan radar | Deskripsi |
---|---|
Minta 3D Secure jika is_missing(:seconds_since_card_first_seen:) | Aturan ini meminta 3D Secure atas semua kartu yang belum pernah digunakan pada akun Anda. Guna mengurangi friksi terhadap pengguna, Anda dapat menambahkan syarat tambahan untuk hanya meminta 3D secure jika :risk_level: != . |
Minta 3D Secure jika :is_new_card_on_customer: | Sebagai alternatif dari aturan di atas, aturan ini meminta 3D Secure atas semua kartu baru digunakan pada Pelanggan. Guna mengurangi friksi terhadap pengguna, Anda dapat menambahkan syarat tambahan untuk hanya meminta 3D secure jika :risk_level: != . |
Review if not :is_3d_secure and not:is_off_session: and :digital_wallet: != | Aturan ini menandai pembayaran di mana 3D Secure diperkirakan ada tetapi 3D Secure tidak didukung untuk tinjauan manual. Ini mengabaikan pembayaran di-luar sesi seperti charge langganan rutin dan dompet digital seperti Apple Pay atau Google Pay. Pembayaran yang ditandai untuk peninjauan melanjutkan otorisasi dan dapat memberikan sinyal tambahan, seperti pemeriksaan CVC penerbit. |
Dalam kasus ini, tanpa aturan blokir, kartu atau dompet digital yang tidak mendukung 3D Secure tidak akan diblokir. Upaya 3D Secure dengan autentikasi yang gagal tidak akan terus men-charge otorisasi.
Selalu wajibkan 3D Secure untuk sejumlah negara penerbit tertentu
Anda ingin menggunakan Radar untuk meminta 3D Secure atas semua charge dari penerbit kartu yang berasal dari negara-negara pada daftar custom dan memblokir kartu yang tidak mendukungnya.
Aturan radar | Deskripsi |
---|---|
Minta 3D Secure jika :card_country: di @enforce_3ds_list | Aturan ini memeriksa syarat berdasarkan penerbit kartu yang berasal dari sejumlah negara dan membandingkannya dengan daftar custom, jika cocok maka akan ini meminta 3D Secure. |
Block if :card_country: in @enforce_3ds_list and not :is_3d_secure and not :is_off_session: and :digital_wallet: != | Aturan ini memblokir pembayaran tanpa alur 3D Secure untuk charge yang berasal dari negara-negara pada daftar custom. Namun, ini menerima transaksi sah yang mungkin memiliki pembebasan SCA atau tidak memiliki kegagalan yang jelas atau autentikasi yang berhasil seperti attempt_acknowledged . Ini menerima pembayaran di-luar sesi seperti charge langganan rutin dan dompet digital seperti Apple Pay atau Google Pay agar berhasil. |
Selalu wajibkan 3D Secure berdasarkan tingkat risiko Radar dan tinjau kasus unik
Anda ingin menggunakan Radar untuk meminta 3D Secure atas semua charge berdasarkan tingkat risiko Radar dan memblokir kartu yang tidak mendukung 3D Secure, tetapi secara manual meninjau kasus unik.
Aturan radar | Deskripsi |
---|---|
Request 3D Secure if :risk_level: != | Aturan ini memeriksa tingkat risiko Radar, kemudian meminta 3D Secure atas semua charge dengan tingkat risiko yang meningkat atau tinggi di atas jumlah tertentu. |
Block if not :is_3d_secure: and :risk_level: != | Aturan ini memblokir pembayaran tanpa alur 3D Secure untuk charge dengan tingkat risiko yang meningkat atau tinggi di atas jumlah tertentu. Namun, terima transaksi sah yang mungkin memiliki pembebasan SCA. Ini menerima pembayaran di-luar sesi seperti charge langganan rutin dan dompet digital seperti Apple Pay atau Google Pay agar berhasil. |
Review if not :is_3d_secure_authenticated: and :risk_level: != | Aturan ini menandai pembayaran untuk tinjauan manual yang menggunakan 3D Secure, tetapi tidak menghasilkan alur yang diautentikasi sepenuhnya. Ini akan meninjau kasus unik seperti attempt_acknowledged dan juga menandai pembayaran yang sah meski ada pembebasan SCA. Karena aturan tinjau dievaluasi setelah aturan blokir, kartu yang tidak mendukung 3D Secure akan diblokir. |
Kapan membuat aturan
Aturan default Stripe dapat memblokir sejumlah besar pembayaran penipuan. Bisnis yang perlu kendali lebih besar atas pembayaran yang ingin mereka tinjau, izinkan, atau blokir dapat menulis aturan custom melalui Radar for Fraud Teams.
Pertimbangkanlah pertanyaan berikut saat mengambil keputusan apakah akan mengaktifkan aturan custom:
- Apakah Anda menganggap fitur atau perilaku pengguna tertentu lebih berisiko (misalnya penggunaan email sekali pakai)?
- Apakah Anda ingin mengimplementasikan aturan berdasarkan jumlah pembayaran atau tingkat risiko yang dipersepsikan (misalnya ditinjau otomatis jika pembayaran melebihi 500 USD, diizinkan otomatis jika pembayaran di bawah 5 USD)?
- Apakah pembayaran Anda yang saat ini dipersengketakan dan dikembalikan dananya memiliki kesamaan pola (misalnya, kesamaan jumlah, tipe kartu, atau negara)?
- Apakah saat ini Anda memiliki aturan yang ingin Anda migrasikan ke Stripe? Banyak aturan ini mungkin telah dicakup oleh model pembelajaran mesin Stripe, dan tidak ada salahnya untuk melihat kinerja sistem kami bagi bisnis Anda sebelum menyesuaikannya.
Cara membuat aturan yang efektif
Meski aturan dapat membantu Anda mengotomatiskan alur kerja saat ini, aturan juga dapat berdampak negatif pada bisnis Anda jika salah digunakan. Misalnya, suatu aturan dapat otomatis mengizinkan sejumlah besar pembayaran penipuan atau memblokir sejumlah besar pembayaran yang sah jika tidak disiapkan dengan benar.
Beberapa tips bermanfaat untuk diingat saat menyiapkan aturan mencakup:
- Aturan hanya berlaku untuk pembayaran mendatang dan tidak berlaku bagi pembayaran yang sudah diproses.
- Aturan Minta 3D Secure hanya berlaku ketika menggunakan Stripe Checkout, Payment Intents, atau Setup Intents, dan dievaluasi sebelum aturan tinjauan, blokir, atau izinkan.
- Sebelum mengimplementasikan aturan blokir untuk memblokir semua pembayaran yang memenuhi kriterianya, pertimbangkan apakah lebih baik meninjau pembayaran seperti ini.
- Gunakan aturan izinkan secara minimal, karena aturan ini akan mengesampingkan aturan default Stripe bersama dengan aturan khusus lainya yang cocok dengan kriterianya.
- Anda dapat membuat maksimal 200 aturan di seluruh tipe aturan per akun.
Bangun aturan
Anda dapat menambahkan dan mengelola aturan dari tab Aturan di halaman Radar di Dashboard.
Untuk menambah aturan baru:
- Klik + Tambahkan aturan.
- Pilih jenis aturan tipe dari submenu.
- Di editor aturan, buat aturan menggunakan sintaks
{action} if {attribute} {operator} {value}
dengan:- {action}: Cara Radar merespons ketika kriteria aturan terpenuhi. Nilai ini telah diisi sebelumnya berdasarkan pilihan jenis aturan yang Anda pilih.
- {attribute}: Elemen transaksi yang akan dievaluasi, seperti jumlah atau jenis kartu. Mulailah mengetik dengan
:
untuk membuka daftar atribut yang valid. Anda juga dapat mengevaluasi metadata custom dengan mengapitnya dalam tanda titik dua, misalnya,::product_sku::
. - {operator}: Cara membandingkan atribut dengan nilai, seperti
=
,>
,!=
, dan seterusnya. - {value}: Nilai atribut yang akan dievaluasi.
- Klik Coba aturan.
- Perbaiki kesalahan validasi yang terdeteksi, jika perlu.
- Di halaman Tinjau aturan baru, tinjau kinerja aturan ini terhadap transaksi terakhir untuk mengonfirmasi apakah Anda ingin mengaktifkannya.
- Klik Tambahkan aturan untuk mulai menerapkan aturan ini ke semua transaksi di masa mendatang.
Gunakan Radar Assistant
Editor aturan Stripe memiliki asisten LLM bawaan yang membangun aturan Radar dari perintah bahasa alami.
Untuk menggunakan Radar Assistant:
- Dari tab Aturan di halaman Radar di Dashboard, klik + Tambahkan aturan.
- Pilih jenis aturan tipe dari submenu.
- Di editor aturan, klik Radar Assistant.
Penulisan aturan manual
Radar Assistant
- Di kolom pesan, masukkan permintaan aturan. Anda mungkin diminta untuk melakukan:
- Tinjau pembayaran dengan negara kartu dan IP yang berbeda.
- Blokir pembayaran kartu Discover yang lebih dari $1000.
- Izinkan pembayaran dari alamat email stripe.com.
- Ketika Assistant memberikan saran, Anda dapat memasukkan perintah tambahan untuk membuat penyesuaian pada aturan atau mengklik Coba aturan untuk melihat kinerja aturan terhadap riwayat transaksi terbaru Anda.
- Setelah Anda puas dengan aturan tersebut, klik Tambahkan aturan untuk mengaktifkannya untuk semua transaksi di masa mendatang.
Persetujuan data pelatihan: Dengan menggunakan Radar Assistant, Anda setuju bahwa Stripe dapat mencatat dan menggunakan entri obrolan untuk melatih dan meningkatkan kemampuan Radar Assistant. Jika Anda tidak ingin entri obrolan digunakan untuk tujuan ini, tulis aturan secara manual.
Pelajari selengkapnya tentang layanan Stripe AI.
Aturan tinjauan
Stripe masih memproses pembayaran seperti biasa bila pembayaran memenuhi kriteria aturan tinjauan. Namun kami akan menempatkannya dalam antrean tinjauan agar tim Anda dapat melihatnya lebih dekat. Mengatur aturan yang terlalu luas dapat mengakibatkan pembayaran yang dimasukkan ke dalam antrean tinjauan menjadi terlalu banyak, memperlambat pelanggan, dan membebani tim tinjauan Anda.
Antarmuka percobaan aturan Stripe menjalankan simulasi pada charge yang terjadi enam bulan terakhir untuk menentukan jumlah pembayaran sah, penipuan, dan terblokir yang akan terpengaruh oleh aturan ini, seandainya diimplementasikan. Saat mencoba aturan dan memeriksa pembayaran untuk enam bulan terakhir, Anda harus memastikan bahwa:
- Volume pembayaran keseluruhan rendah. Meninjau pembayaran ini tidak seharusnya membebani tim Anda.
- Peninjau manusia memberi nilai tambah. Peninjau manusia umumnya dapat mengidentifikasi apakah suatu pembayaran itu penipuan dengan lebih yakin daripada sistem otomatis.
- Aturan ini menghasilkan campuran pembayaran yang berhasil dan dikembalikan dananya atau dipersengketakan. Ini berarti bahwa pemeriksaan tambahan pada tipe pembayaran seperti ini dapat membantu memisahkan pembayaran yang sah dari pembayaran penipuan.
Berikut adalah contoh cara menyempurnakan aturan tinjauan yang dibuat oleh bisnis yang ingin meninjau kartu kredit prabayar.
Aturan awal | Aturan disempurnakan |
---|---|
Review if :card_funding: = | Review if :is_disposable_email: and :card_funding: = |
Terlalu luas–menghasilkan teralu banyak tinjauan | Lebih fokus—menghasilkan jumlah tinjauan yang lebih sedikit |
Aturan blokir
Anda dapat menggunakan aturan blokir untuk memblokir pembayaran yang cukup Anda yakini sebagai penipuan, atau berdasarkan pembatasan yang diterapkan oleh bisnis Anda (seperti memblokir pembayaran dari kartu prabayar). Jika tidak yakin cara menerapkan aturan blokir, kami menyarankan Anda menempatkan pembayaran dalam tinjauan dengan menggunakan aturan tinjau. Setelah menghabiskan waktu meninjau pembayaran ini dari kemungkinan positif palsu, maka Anda dapat mengonfirmasi jika ingin membuat aturan blokir sebagai gantinya.
Aturan blokir hanya berdampak pada pembayaran penipuan dan pembayaran yang berhasil, sementara pembayaran yang terblokir tidak akan terpengaruh. Saat mencoba aturan, pastikan bahwa Anda:
- Menjaga positif palsu serendah-rendahnya. Selama percobaan, Stripe mengidentifikasi jumlah pembayaran yang berhasil dan bersengketa yang akan disaring oleh aturan. Aturan blokir yang baik secara signifikan akan lebih banyak memblokir pembayaran penipuan daripada pembayaran yang sah.
- Meminimalisir aturan yang tidak perlu. Jika aturan Anda memiliki kinerja yang sangat baik tetapi sudah tercakup dalam aturan yang sudah ada, maka aturan yang lebih baru mungkin tidak perlu. Demikian pula jika hasil selama percobaan tampak tercampur, pertimbangkan mengatur aturan tinjauan agar Anda dapat mengumpulkan lebih banyak informasi tentang tipe pembayaran ini.
Berikut adalah contoh cara meningkatkan aturan blokir yang dibuat oleh bisnis yang mengalami tingkat penipuan yang tinggi dari pembayaran dari luar AS:
Aturan awal | Aturan disempurnakan |
---|---|
Block if :card_country: != | Block if :card_country: != |
Terlalu luas—pembayaran sah yang terblokir terlalu banyak | Lebih fokus—menghasilkan jumlah tinjauan yang lebih sedikit |
Aturan izinkan
Aturan izin mengesampingkan semua aturan lain, termasuk model pembelajaran mesin Stripe, dan Anda harus menggunakannya secara hati-hati. Banyak bisnis mungkin tidak perlu mengimplementasikan aturan izinkan. Jika Anda memiliki masalah yaitu aturan izinkan tidak sedikit pun menjaring pembayaran penipuan, maka Anda harus mempertimbangkan untuk melakukan penyesuaian untuk membatasi aturan ini lebih lanjut sebelum mengimplementasikannya. Karena aturan izinkan mengesampingkan semua aturan lain, termasuk pertimbangan pembelajaran mesin Stripe, Anda harus membuat aturan izinkan yang terus memblokir setiap pembayaran yang mungkin kami yakini sebagai penipuan.
Aturan izinkan diterapkan pada semua pembayaran yang baru segera setelah aturan itu dibuat. Ini termasuk setiap pembayaran yang serupa dengan pembayaran sebelumnya yang telah diblokir. Saat mencoba aturan, pastikan bahwa Anda:
- Mempelajari jumlah pembayaran yang sebelumnya diblokir yang semestinya diizinkan. Aturan izinkan mengesampingkan semua aturan dan penilaian risiko Stripe lainnya. Saat mencoba aturan izinkan yang baru, semua pembayaran yang telah diblokir atau dipersengketakan akan berdampak pada rasio sengketa Anda di masa mendatang.
- Lanjutkan memblokir setiap pembayaran berisiko tinggi. Anda dapat melakukannya dengan menambahkan yang berikut pada aturan izinkan:
and :risk_level: !=
'tertinggi'
- Evaluasi riwayat transaksi yang sah di bisnis Anda. Anda dapat memanfaatkan koneksi antarpelanggan Anda sendiri untuk mengizinkan volume transaksi yang lebih tinggi berdasarkan riwayat pembelian yang sah. Hal ini membantu Anda memblokir lebih sedikit pembayaran dari pelanggan dengan riwayat yang telah terbukti di bisnis Anda. Untuk melakukannya, tinjau daftar atribut dan cari atribut yang berisi kata “customer”.
Daftar berikut adalah contoh cara menyempurnakan aturan izinkan bagi bisnis yang umumnya (tetapi tidak selalu) melihat pembayaran yang baik dari pelanggan yang berasal dari Inggris:
Aturan awal | Aturan disempurnakan |
---|---|
Allow if :ip_country: = | Allow if :ip_country: = |
Terlalu luas—sejumlah pembayaran tipuan diizinkan | Lebih fokus-–-sejumlah kecil pembayaran tipuan diizinkan |
Memelihara aturan Anda
Saat bisnis Anda terus bertumbuh, Anda ingin memastikan bahwa aturan Anda terus mencerminkan tipe pelanggan yang diinginkan bisnisnya. Berikut adalah beberapa praktik terbaik agar aturan tetap mengikuti situasi bisnis Anda.
Memantau aturan secara berkala agar tetap efektif
Metrik aturan
Pola penipuan terus berubah, jadi kami menyediakan metrik untuk menunjukkan cara kerja aturan ini. Metrik ini bervariasi menurut tipe aturan, karena tipe aturan melakukan tindakan yang berbeda.
Gunakan bagan kinerja aturan untuk memahami perilaku aturan Radar Anda. Cari lonjakan atau penolakan tak terduga dalam jumlah pembayaran yang sesuai dengan aturan Anda, seperti aturan izinkan yang membiarkan pembayaran terlalu banyak atau aturan blokir yang memblokir terlalu banyak. Lonjakan ini dapat menunjukkan perubahan tipe pembayaran yang diterima oleh bisnis Anda atau yang mungkin memerlukan pembaruan pada aturan itu sendiri. Pembaruan yang dibuat pada aturan akan ditampilkan sebagai segitiga pada grafik dan dapat membantu Anda membandingkan dampak perubahan sebelum dan sesudah membuatnya.
Garis berkode warna melacak jumlah pembayaran yang sesuai dengan aturan 3D Secure, aturan izinkan, aturan blokir, dan aturan tinjau. Simbol segitiga pada garis grafik ini mewakili pembaruan aturan untuk tipe yang bersangkutan.
Anda dapat menemukan informasi efektivitas aturan dan melihat jumlah pembayaran yang telah ditindaklanjuti. Anda juga dapat melihat dan mengunduh daftar yang telah disaring dari setiap pembayaran yang memberlakukan aturan. Evaluasilah informasi ini untuk membantu Anda mengambil keputusan jika perlu membuat perubahan pada aturan atau menghapusnya sama sekali.
Untuk melihat perintah tambahan, klik ikon elips (•••). Perintah tambahan meliputi: Nonaktifkan, Aktifkan, Edit atau Hapus untuk aturan.
Secara opsional, Anda dapat menggunakan produk pelaporan kami Sigma dan Data Pipeline untuk data penipuan dan sengketa query, termasuk keputusan aturan dan atribut bagi masing-masing pembayaran perorangan.
Lakukan evaluasi keefektifan aturan
Anda dapat menemukan informasi tentang keefektifan aturan dan melihat berapa banyak pembayaran yang terpengaruh oleh masing-masing aturan. Anda juga dapat melihat serta mengunduh daftar yang difilter dari setiap pembayaran yang aturannya telah diterapkan. Tinjau sampel pertanyaan dalam tabel berikut untuk membantu Anda memutuskan apakah perlu mengubah aturan atau menghapus seluruhnya.
Tipe Aturan | Evaluasi | Tindakan untuk dipertimbangkan |
---|---|---|
Umum | Apakah aturan ini tidak lagi cocok sama sekali dengan pembayaran? | Hapus aturan. |
Apakah aturan ini memiliki perilaku tak normal, seperti mengizinkan lebih banyak pembayaran daripada periode waktu sebelumnya? | Tinjau pembayaran secara manual yang cocok dengan aturan ini untuk menentukan apakah perilaku ini yang Anda inginkan. | |
3DS | Apakah rasio penyelesaian 3DS tinggi, tetapi jumlah sengketa/EFW rendah? | Hapus aturan karena Anda mungkin memberikan hambatan kepada pengguna yang baik. |
Apakah penipuan tinggi untuk transaksi yang melewati 3DS? | Pertimbangkan untuk mengubah aturan 3DS Anda menjadi aturan blokir guna mencegah pengguna tersebut melewati alur tanpa hambatan (dikendalikan oleh penerbit) atau melakukan penipuan pihak pertama. | |
Apakah rasio konversi untuk 3DS rendah? | Ini mungkin aturan yang baik karena sebagian besar dapat memblokir penipu, tetapi pertimbangkan untuk menyelidiki pembayaran yang cocok secara manual guna memastikan pengguna Anda yang baik tidak terbengkalai karena hambatan tambahan. | |
Izinkan | Apakah jumlah sengketa, EFW, Pengembalian Dana, atau Pembayaran yang Gagal tinggi? | Hapus aturan yang mengizinkan pemrosesan pembayaran buruk. |
Blokir | Apakah jumlah blokiran turun, tetapi penipuan Anda masih stabil atau meningkat? | Ubah aturan Anda karena mungkin lagi tidak efektif. |
Apakah jumlah blokiran naik, tetapi penipuan Anda masih stabil atau meningkat? | Ubah aturan Anda karena mungkin memblokir pengguna yang baik. | |
Apakah jumlah blokiran naik dan penipuan Anda turun? | Ini menunjukkan bahwa aturan Anda efektif, tetapi pertimbangkan untuk meninjau beberapa transaksi secara manual guna memastikan bahwa Anda tidak memblokir terlalu banyak pengguna yang baik. | |
Tinjauan Manual | Apakah persentase pembayaran yang ditinjau rendah? | Buat aturan lebih restriktif karena mungkin terlalu luas. |
Apakah jumlah pembayaran yang berhasil atau disetujui tinggi? | Hapus seluruh aturan tinjau manual atau tulis aturan izinkan untuk menargetkan pembayaran tersebut. | |
Apakah jumlah pengembalian dana atau sengketa & Peringatan Penipuan Dini tinggi? | Konversikan ke aturan blokir. |
Aturan minta 3DS
Untuk aturan minta 3DS, kami menampilkan:
- 3DS Diminta — berapa kali aturan memicu permintaan 3DS.
Klik aturan 3DS untuk melihat metrik berikut:
Aturan izinkan
Untuk aturan izinkan, pengguna Radar for Fraud Teams dapat melihat:
- Pembayaran yang diizinkan — jumlah total pembayaran yang diizinkan oleh aturan Anda.
- Volume, pembayaran yang diizinkan — jumlah total, dalam mata uang setempat, dikaitkan dengan pembayaran yang diizinkan oleh aturan Anda.
- Skor risiko — hasil risiko bersangkutan yang ditetapkan oleh model pembelajaran mesin Stripe pada set pembayaran yang diizinkan oleh aturan Anda.
- Sengketa dari pengesampingan — jumlah total pembayaran diizinkan yang dipersengketakan.
- Volume, sengketa dari pengesampingan — jumlah total, dalam mata uang setempat, dikaitkan dengan sengketa dari pembayaran yang diizinkan.
Klik aturan Izinkan untuk melihat metrik berikut:
Aturan blokir
Untuk aturan blokir, kami menampilkan:
- Pembayaran yang diblokir — jumlah total pembayaran yang diblokir oleh aturan Anda.
- Volume, pembayaran yang diblokir — jumlah total, dalam mata uang setempat, dikaitkan dengan pembayaran yang diblokir oleh aturan Anda.
Pengguna Radar for Fraud Teams juga dapat melihat:
- Skor risiko — hasil risiko bersangkutan yang ditetapkan oleh model pembelajaran mesin Stripe pada set pembayaran yang diizinkan oleh aturan Anda.
- Est. rasio positif palsu — estimasi persentase pembayaran nonpenipuan yang diblokir karena aturan blokir Anda sebagai satu set aturan maupun masing-masing aturan. (Estimasi ini dibuat menggunakan perkiraan rasio positif palsu dari skor risiko pembelajaran mesin bersangkutan, yang kami hitung dengan sejumlah eksperimen di seluruh jaringan Stripe.)
- Est. sengketa yang dihindari — estimasi jumlah sengketa yang dicegah oleh aturan blokir Anda. Estimasi ini menggunakan presisi skor risiko pembelajaran mesin bersangkutan, yang kami hitung dengan sejumlah eksperimen di seluruh jaringan Stripe.
Klik aturan Blokir untuk melihat metrik berikut:
Aturan tinjau
Untuk aturan tinjau, pengguna Radar for Fraud Teams dapat melihat:
- Pembayaran yang dikirim untuk ditinjau — jumlah total pembayaran yang dikirim untuk ditinjau secara manual oleh aturan Anda.
- Volume, tinjauan yang disetujui — jumlah total, dalam mata uang setempat, yang dikaitkan dengan tinjauan pembayaran yang disetujui.
- Rasio pengembalian dana — persentase tinjauan yang dikembalikan dananya.
- Sengketa dari tinjauan yang disetujui — jumlah total pembayaran yang disetujui dalam tinjauan Anda, namun akhirnya dipersengketakan.
- Volume, sengketa dari tinjauan yang disetujui — jumlah total, dalam mata uang setempat, yang dikaitkan dengan sengketa dari tinjauan pembayaran yang disetujui.
Klik aturan Tinjau untuk melihat metrik berikut:
Memantau antrean tinjauan manual secara berkala
Jika antrean tinjauan Anda sudah terlalu banyak untuk dapat dikelola, periksa apakah Anda telah menerapkan aturan yang tepat. Jika sebagian besar tinjauan berakhir dengan dikembalikannya dana karena penipuan, pertimbangkan aturan tambahan untuk memblokir pembayaran. Demikian pula, bila kebanyakan pembayaran disetujui, pertimbangkan untuk membuat aturan tinjauan yang lebih fokus.
Menganalisis pembayaran yang disengketakan dan dikembalikan dananya
Sengketa melekat erat dengan penipuan, jadi semakin banyak Anda mengurangi penipuan, semakin rendah tingkat sengketa. Anda harus memeriksa untuk mengetahui apakah pembayaran yang dipersengketakan memiliki karakteristik serupa (misalnya dari lokasi yang sama atau berjumlah sama). Anda juga dapat melakukan tipe penyelidikan ini dengan melihat pembayaran yang telah dikembalikan dananya selama tinjauan. Jika Anda melihat adanya tren, Anda dapat mencoba dan membuat aturan yang sesuai. Jika pembayaran tampak sebagai penipuan, kembalikan dananya dan laporkan sebagai penipuan untuk menghindari potensi sengketa.
Secara opsional, Anda dapat menggunakan produk pelaporan kami Sigma dan Data Pipeline untuk data penipuan dan sengketa query.
Anda dapat merespons setiap sengketa yang masuk menggunakan Dashboard atau melalui API, dan dokumentasi sengketa kami akan menyertakan beberapa saran tentang cara menyajikan kasus yang terdokumentasikan dengan baik.
Mengantisipasi perubahan besar pada bisnis Anda yang mungkin berdampak pada rasio sengketa
Jika Anda merencanakan rilis produk utama atau perubahan pada layanan (misalnya produk baru yang bernilai tinggi atau memperluas layanan ke negara-negara baru), maka Anda mungkin ingin memantau pembayaran ini sejak awal. Untuk perubahan seperti ini, sebaiknya siapkan beberapa aturan peninjauan agar Anda dapat memeriksa pembayaran baru. Meninjau pembayaran ini dan mengidentifikasi polanya dapat membantu Anda menyiapkan aturan baru untuk melindungi bisnis dari penipuan.