Aturan pencegahan penipuan
Gunakan aturan pencegahan penipuan untuk melindungi bisnis Anda.
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 (3DS) 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 tersedia 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 masih dapat berhasil bahkan bila pemeriksaan CVC atau alamat (AVS) gagal karena penerbit mengevaluasi banyak sinyal ketika memutuskan untuk mengotorisasi pembayaran. Penerbit kartu mungkin masih menganggap sah pembayaran yang gagal dalam verifikasi CVC atau kode pos, sehingga menyetujuinya.
Anda dapat mengaktifkan aturan bawaan Radar untuk memblokir pembayaran tertentu yang disetujui oleh penerbit kartu. Bila diaktifkan, aturan ini juga memengaruhi pelampiran kartu ke pelanggan, serta pembuatan pelanggan, jika Anda membuat kartu dan pelanggan bersama-sama.
Aturan bawaan untuk meminta 3D Secure
Penggunaan 3DS akan meminta pelanggan menyelesaikan langkah autentikasi tambahan sebelum mereka dapat menyelesaikan alur pembelian. Jika 3DS mengautentikasi pembayaran, pertanggungjawaban atas sengketa terkait penipuan untuk pembayaran tersebut biasanya beralih dari penjual ke penerbit. Ini berarti bahwa dalam sebagian besar kasus, penjual tidak bertanggung jawab atas biaya penipuan pada pembayaran yang diautentikasi 3DS.
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 3DS 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 direkomendasikan untuk kartu- Dinonaktifkan secara default. Mengaktifkan aturan ini akan meminta pelanggan melakukan autentikasi 3DS jika Stripe meyakini bahwa autentikasi 3DS dapat diimplementasikan dengan dampak minimal pada rasio konversi.
- Aktifkan ini jika Anda ingin memaksimalkan jumlah pembayaran yang memiliki pengalihan pertanggungjawaban.
Minta 3D Secure jika 3D Secure didukung untuk kartu- Disabled by default. Enabling this rule prompts the customer for 3DS authentication as long as their card supports it.
- 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.
Request 3D Secure if 3D Secure is required for cardTidak lagi digunakan- Enabling this rule prompts the customer for 3DS authentication if the card historically required 3DS.
- Regardless of this rule, Stripe automatically triggers 3DS:
- If a soft decline code indicates the issuer requires 3DS.
- In adherence to regulations such as PSD2’s Strong Customer Authentication mandate.
Because 3DS requires your customer to go through an additional layer of authentication, indiscriminate use of 3DS might lower conversion rates.
Meminta 3DS tidak selalu berarti penerbit benar-benar melakukan 3DS. Untuk detail selengkapnya tentang kemungkinan hasil, lihat dokumentasi 3D Secure.
Aturan khusus untuk meminta 3D Secure dan bertindak berdasarkan hasil tertentu
Setelah mencoba autentikasi 3DS, 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_secureyang bernilai true jika kartu tersebut didukung, 3DS telah dicoba oleh penerbit dan pengguna tidak gagal autentikasi. Kami umumnya merekomendasikan penggunaan ini dalam aturan blokir.is_3d_secure_authenticatedyang bernilai true jika 3DS 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_shiftyang bernilai true jika Stripe memperkirakan pembayaran tersebut ditanggung berdasarkan aturan pengalihan pertanggungjawaban. Hal ini mungkin tidak selalu sama dengan 3DS, misalnya Apple Pay di wilayah tertentu.
Untuk aturan custom, kami merekomendasikan untuk tetap menyelaraskan aturan Minta 3DS dan Blokir bergantung pada toleransi risiko Anda. Namun, jangan blokir transaksi di mana 3DS 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 3DS 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 3DS 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 3DS tidak akan diblokir. Upaya 3DS dengan autentikasi yang gagal tidak akan terus men-charge otorisasi.
Selalu wajibkan 3D Secure berdasarkan tingkat risiko Radar
Anda ingin menggunakan Radar untuk meminta 3DS atas semua charge berdasarkan tingkat risiko Radar meningkat atau tinggi, dan di atas jumlah tertentu. Jika kartu tidak mendukung 3DS, Anda jangan mau menerimanya.
| Aturan radar | Deskripsi |
|---|---|
Request 3D Secure if :risk_level: != | Aturan ini memeriksa tingkat risiko Radar, kemudian meminta 3DS 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 3DS 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_. 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 3DS 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 3DS dan 3DS telah dicoba tetapi pengguna berhasil mengautentikasi. Kartu yang tidak mendukung 3DS, pengecualian 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 3DS atas semua charge dengan atribut metadata custom.
| Aturan radar | Deskripsi |
|---|---|
Request 3D Secure if ::foo:: = | Aturan ini memeriksa syarat metadata, kemudian meminta 3DS. 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 3DS tidak akan diblokir. Upaya 3DS dengan autentikasi yang gagal tidak akan terus men-charge otorisasi.
Selalu wajibkan 3D Secure berdasarkan Metadata
Anda ingin menggunakan Radar untuk meminta 3DS 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 3DS. Untuk memeriksa metadata Pelanggan, ganti ::foo:: = 'bar' dengan nilai seperti ::customer:trusted:: = 'false'. |
Block if ::foo:: = | Aturan ini memblokir pembayaran tanpa alur 3DS 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_. 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 3DS atas semua kartu baru dan secara manual meninjau charge dari kartu yang tidak mendukung 3DS.
| Aturan radar | Deskripsi |
|---|---|
Minta 3D Secure jika is_missing(:seconds_since_card_first_seen:) | Aturan ini meminta 3DS atas semua kartu yang belum pernah digunakan pada akun Anda. Guna mengurangi friksi terhadap pengguna, Anda dapat menambahkan syarat tambahan untuk hanya meminta 3DS jika :risk_level: != . |
Minta 3D Secure jika :is_new_card_on_customer: | Sebagai alternatif dari aturan di atas, aturan ini meminta 3DS atas semua kartu baru digunakan pada Pelanggan. Guna mengurangi friksi terhadap pengguna, Anda dapat menambahkan syarat tambahan untuk hanya meminta 3DS jika :risk_level: != . |
Review if not :is_3d_secure and not:is_off_session: and :digital_wallet: != | Aturan ini menandai pembayaran di mana 3DS diperkirakan ada tetapi 3DS 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 3DS tidak akan diblokir. Upaya 3DS 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 3DS 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 ini akan meminta 3DS. |
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 3DS 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_. 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 3DS atas semua charge berdasarkan tingkat risiko Radar dan memblokir kartu yang tidak mendukung 3DS, tetapi secara manual meninjau kasus unik.
| Aturan radar | Deskripsi |
|---|---|
Request 3D Secure if :risk_level: != | Aturan ini memeriksa tingkat risiko Radar, kemudian meminta 3DS 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 3DS 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 3DS, tetapi tidak menghasilkan alur yang diautentikasi sepenuhnya. Ini akan meninjau kasus unik seperti attempt_dan juga menandai pembayaran yang sah meski ada pembebasan SCA. Karena aturan tinjau dievaluasi setelah aturan blokir, kartu yang tidak mendukung 3DS 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 hal berikut saat mengambil keputusan apakah akan mengaktifkan aturan custom:
- Jika Anda menganggap fitur atau perilaku pengguna tertentu lebih berisiko (misalnya penggunaan email sekali pakai).
- Jika 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).
- Jika pembayaran Anda yang saat ini dipersengketakan dan dikembalikan dananya memiliki kesamaan pola (misalnya, kesamaan jumlah, tipe kartu, atau negara).
- Jika saat ini Anda memiliki aturan yang ingin Anda migrasikan ke Stripe—Banyak aturan ini mungkin telah dicakup oleh model pembelajaran mesin Stripe, dan Anda dapat memeriksa 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.
Ingatlah hal-hal berikut ini saat membuat aturan:
- Aturan hanya berlaku untuk pembayaran mendatang dan tidak berlaku bagi pembayaran yang sudah Anda proses.
- Aturan Minta 3DS 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 tipe aturan 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 6 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 6 bulan terakhir, pastikan 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.
- Peraturan tersebut menghasilkan gabungan antara pembayaran yang sukses dan dikembalikan atau yang disengketakan" Ini berarti bahwa pemeriksaan tambahan pada jenis pembayaran tersebut dapat membantu memisahkan pembayaran yang sah dari yang curang.
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 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, karena pembayaran yang terblokir tidak 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 izinkan mengesampingkan semua aturan Anda lainnya, jadi gunakanlah secara hati-hati. Banyak bisnis mungkin tidak perlu mengimplementasikan aturan izinkan. Jika Anda memiliki persoalan, yaitu aturan izinkan tidak sedikit pun menjaring pembayaran penipuan, pertimbangkanlah untuk melakukan penyesuaian guna membatasi aturan ini lebih lanjut sebelum mengimplementasikannya.
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 menganalisis 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 3DS, 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 menu perluasan (). Perintah tambahan meliputi: Nonaktifkan, Aktifkan, Edit atau Hapus untuk setiap aturan.
Anda juga 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 | Jika aturan ini tidak lagi cocok sama sekali dengan pembayaran | Hapus aturan. |
| Jika 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 | Jika rasio penyelesaian 3DS tinggi, tetapi jumlah sengketa atau EFW rendah. | Hapus aturan karena Anda mungkin memberikan hambatan kepada pengguna yang baik. |
| Jika 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. | |
| Jika 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 | Jika jumlah sengketa, EFW, Pengembalian Dana, atau Pembayaran 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 sudah tidak efektif lagi. |
| Jika jumlah blokiran naik, tetapi penipuan Anda masih stabil atau meningkat. | Ubah aturan Anda karena mungkin memblokir pengguna yang baik. | |
| Jika 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 | Jika persentase pembayaran yang ditinjau rendah. | Buat aturan lebih restriktif karena mungkin terlalu luas. |
| Jika jumlah pembayaran yang berhasil atau disetujui tinggi. | Hapus seluruh aturan tinjau manual atau tulis aturan izinkan untuk menargetkan pembayaran tersebut. | |
| Jika jumlah pengembalian dana atau sengketa dan Peringatan Penipuan Dini tinggi. | Konversikan ke aturan blokir. |
Aturan minta 3DS
Untuk aturan minta 3DS, kami menampilkan:
- 3DS Diminta—berapa kali aturan terpicu 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.)
- Perkiraan pembayaran palsu dicegah—Perkiraan jumlah pembayaran palsu yang berhasil dicegah oleh aturan blokir Anda. Stripe menggunakan skor risiko pembelajaran mesin, yang dihitung dengan menganalisis jutaan transaksi di seluruh jaringan Stripe, untuk memprediksi pembayaran yang kemungkinan besar akan dipersengketakan atau ditolak karena penipuan, dan memperkirakan pembayaran yang berhasil diblokir oleh aturan Anda.
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, tetapi 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. Periksa 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.
Anda juga 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.