# Aturan pencegahan penipuan Gunakan aturan pencegahan penipuan untuk membantu melindungi bisnis Anda. Stripe Radar menyediakan aturan bawaan untuk membantu mendeteksi dan melindungi dari risiko penipuan di semua [metode pembayaran yang didukung](https://docs.stripe.com/radar/supported-payment-methods.md). Semua transaksi disaring menggunakan aturan default Radar. Radar for Fraud Teams dan [Radar for Platforms](https://docs.stripe.com/radar/radar-for-platforms.md) memungkinkan Anda menggunakan [Dashboard](https://dashboard.stripe.com/test/radar/rules) untuk membuat [aturan kustom](https://docs.stripe.com/radar/supported-payment-methods.md#custom-risk-settings) berdasarkan logika bisnis Anda. Misalnya, 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 - **Review** semua pembayaran lebih besar dari 1.000 USD yang dilakukan dengan kartu prabayar - **Tinjau dan jeda pembayaran secara otomatis** pada akun yang memiliki tingkat sengketa tinggi (dengan Radar untuk Platform) > Bisnis di Uni Eropa mungkin akan terdampak oleh [Regulasi Geo-blocking](https://support.stripe.com/questions/eu-geo-blocking-regulation-changes) beserta larangannya terhadap pemblokiran pembayaran dari pelanggan yang berbasis di negara-negara anggota Uni Eropa. ## Aturan bawaan Aturan berikut tersedia secara default, kecuali ditandai sebagai aturan khusus, yang hanya tersedia jika Anda menggunakan Radar untuk Tim Penipuan atau Radar untuk Platform. > #### Blokir penipuan secara otomatis > > Sebagai alternatif, Anda dapat menggunakan [kontrol risiko](https://docs.stripe.com/radar/risk-settings.md) Radar untuk memblokir penipuan secara otomatis. Kontrol risiko menggunakan [peringatan dini penipuan](https://docs.stripe.com/radar/risk-settings.md#early-fraud-warning) untuk mengevaluasi dan memblokir pembayaran dengan risiko tertinggi. ### Pemeriksaan risiko AI Semua penawaran Radar menyediakan seperangkat aturan default berdasarkan penilaian model kecerdasan buatan kami. | Aturan Radar | Deskripsi | | ---------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Block** if :risk_level: = `'tertinggi'` (Tidak digunakan lagi) | Aturan ini akan memblokir dan tidak akan memroses pembayaran dengan risiko penipuan tinggi. Aturan ini diaktifkan secara default untuk semua pengguna Radar. | | `if :risk_level: = 'elevated'` | Perilaku default untuk Radar for Fraud Teams dan Radar for Platforms adalah menempatkan pembayaran ke dalam peninjauan jika kami menduga pembayaran tersebut memiliki risiko penipuan yang lebih tinggi. | Radar for Platforms memiliki model kecerdasan buatan tambahan pada tingkat akun yang diterapkan melalui dua aturan default: `if :account_risk_level: = 'highest'` `if :account_risk_level: = 'elevated'` Kami menghitung risiko pada tingkat akun menggunakan informasi KYC, transaksi, faktor risiko geografis, dan pola perilaku. ### Pemeriksaan kartu tradisional Suatu pembayaran tetap dapat berhasil meskipun pemeriksaan *CVC* (The card verification code (CVC) or card verification value (CVV) is a three- or four-digit number printed directly on a card used to verify the entered card number) atau alamat (*AVS* (The address verification system (AVS) is used to pass billing address information to issuers to verify the data if available)) gagal, karena penerbit kartu mengevaluasi berbagai faktor risiko saat memutuskan apakah akan mengotorisasi pembayaran. Penerbit kartu mungkin tetap menganggap pembayaran yang gagal dalam verifikasi CVC atau kode pos sebagai sah, sehingga tetap 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 CVC dan AVS Berlaku mulai 17 Desember 2024, Dashboard menampilkan aturan ini kepada pelanggan baru dan pelanggan lama yang belum menggunakan aturan CVC atau AVS terdahulu. | Aturan Radar | Deskripsi | | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `jika Verifikasi CVC gagal berdasarkan skor risiko` | Aktifkan aturan ini untuk memblokir pembayaran yang gagal dalam pemeriksaan verifikasi CVC oleh penerbit kartu, kecuali jika Stripe menilai pembayaran tersebut berisiko rendah. Aturan ini tidak memblokir pembayaran ketika pelanggan tidak memberikan nomor CVC karena, misalnya, mereka menggunakan *dompet digital* (A digital wallet is a contactless payment method that stores payment options, such as credit and debit cards, allowing customers to use a smart device to make a purchase), atau penerbit kartu mereka tidak mendukung verifikasi tersebut. | | `jika Verifikasi kode pos gagal berdasarkan skor risiko` | Aktifkan aturan ini untuk memblokir pembayaran yang gagal dalam pemeriksaan verifikasi kode pos oleh penerbit kartu, kecuali jika Stripe menilai pembayaran tersebut berisiko rendah. Aturan ini tidak memblokir pembayaran ketika pelanggan tidak memberikan kode pos, atau penerbit kartu mereka tidak mendukung verifikasi tersebut. | #### Aturan CVC dan AVS terdahulu Efektif 17 Desember 2024, Dashboard menampilkan aturan ini kepada pelanggan yang sudah ada yang mengaktifkan setidaknya satu aturan. | Aturan Radar | Deskripsi | | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `jika verifikasi CVC gagal` | Aktifkan aturan ini untuk memblokir pembayaran yang gagal dalam pemeriksaan verifikasi CVC oleh penerbit kartu. Aturan ini tidak memblokir pembayaran ketika pelanggan tidak memberikan nomor CVC karena, misalnya, mereka menggunakan *dompet digital* (A digital wallet is a contactless payment method that stores payment options, such as credit and debit cards, allowing customers to use a smart device to make a purchase), atau penerbit kartu mereka tidak mendukung verifikasi tersebut. | | `jika verifikasi kode pos gagal` | Aktifkan aturan ini untuk memblokir pembayaran ketika pembayaran tersebut gagal dalam pemeriksaan verifikasi kode pos oleh penerbit kartu. Aturan ini tidak memblokir pembayaran ketika pelanggan tidak memberikan kode pos, atau penerbit kartu mereka tidak mendukung verifikasi tersebut. | ### Aturan bawaan untuk meminta 3D Secure *3D Secure (3DS)* (3D Secure (3DS) provides an additional layer of authentication for credit card transactions that protects businesses from liability for fraudulent card payments) meminta pelanggan untuk menyelesaikan langkah autentikasi tambahan sebelum mereka dapat menyelesaikan proses pembelian. Jika 3DS mengautentikasi suatu pembayaran, [tanggung jawab](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#disputed-payments) atas setiap sengketa terkait penipuan untuk pembayaran tersebut biasanya beralih dari penjual ke penerbit. Ini berarti bahwa dalam kebanyakan kasus, penjual tidak bertanggung jawab atas biaya penipuan pada pembayaran yang diautentikasi dengan 3DS. Stripe secara otomatis menangani kode penolakan lunak yang menunjukkan bahwa 3DS diwajibkan oleh penerbit. Kami juga memicu 3DS bila diperlukan, sesuai dengan regulasi, seperti [Autentikasi Pelanggan yang Kuat](https://stripe.com/guides/strong-customer-authentication) (SCA) yang diwajibkan oleh PSD2. Menonaktifkan Radar tidak mencegah 3DS dipicu dalam kasus-kasus yang memang memerlukannya. Stripe mendukung tiga aturan bawaan lama untuk meminta 3DS saat menggunakan Radar dengan [Payment Intents](https://docs.stripe.com/payments/accept-a-payment.md) atau [SetupIntents](https://docs.stripe.com/payments/save-and-reuse.md): | Aturan Radar | Deskripsi | | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `jika 3D Secure direkomendasikan untuk kartu` (Tidak lagi digunakan) | Aktifkan aturan ini untuk meminta pelanggan melakukan autentikasi 3DS berdasarkan risiko. | | `jika 3D Secure didukung untuk kartu` (Tidak lagi digunakan) | Aktifkan aturan ini untuk meminta pelanggan melakukan autentikasi 3DS, selama kartu mereka mendukungnya. | | `jika 3D Secure diperlukan untuk kartu` (Deprecated) | Aktifkan aturan ini untuk meminta pelanggan melakukan autentikasi 3DS, jika kartu tersebut secara historis [memerlukan 3DS](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#three-ds-cards). Terlepas dari aturan ini, Stripe secara otomatis memicu 3DS: - Jika kode penolakan lunak mengindikasikan bahwa penerbit mengharuskan 3DS. - Sesuai dengan regulasi, seperti mandat [Autentikasi Pelanggan yang Kuat](https://stripe.com/guides/strong-customer-authentication) dalam PSD2. | Karena 3DS mengharuskan pelanggan Anda untuk melewati lapisan autentikasi tambahan, penggunaan 3DS secara sembarangan dapat menurunkan rasio konversi. Meminta 3DS tidak selalu berarti bahwa penerbit benar-benar menjalankan 3DS. Pelajari lebih lanjut tentang [kemungkinan hasil](https://docs.stripe.com/payments/3d-secure.md). ### Aturan khusus untuk meminta 3D Secure dan bertindak berdasarkan hasil tertentu Setelah mencoba autentikasi 3DS, jika Anda memiliki [Radar for Fraud Teams](https://stripe.com/radar/fraud-teams) atau [Radar for Platforms](https://docs.stripe.com/radar/radar-for-platforms.md), Anda dapat mengevaluasi hasilnya dalam aturan izinkan, blokir, atau tinjau. Lihat di bawah untuk atribut paling penting bagi aturan Radar khusus. | Atribut | Deskripsi | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `is_3d_secure` | Nilai ini benar jika kartu didukung, 3DS dicoba oleh penerbit, dan pelanggan tidak gagal dalam autentikasi. Kami umumnya merekomendasikan penggunaan atribut ini dalam aturan blokir. | | `is_3d_secure_authenticated` | Nilai ini benar jika 3DS dicoba oleh penerbit dan pelanggan berhasil menyelesaikan autentikasi penuh. Menggunakan atribut ini dalam aturan blokir dapat mengecualikan transaksi sah yang mungkin memiliki pengecualian SCA atau tidak termasuk dalam kegagalan yang jelas maupun autentikasi yang berhasil, seperti kesalahan pemrosesan. | | `has_liability_shift` | Nilai ini benar jika Stripe memperkirakan *pengalihan tanggung jawab* (With some 3D Secure transactions, the liability for fraudulent chargebacks (stolen or counterfeit cards) shifts from you to the card issuer) akan mencakup pembayaran tersebut. Hal ini mungkin tidak selalu sama dengan [3DS](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#disputed-payments), misalnya Apple Pay di wilayah tertentu. | Untuk aturan khusus, kami menyarankan agar aturan `Minta 3DS` dan `Blokir` tetap selaras sesuai dengan [selera risiko](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data) Anda. Namun, jangan blokir pembayaran ketika 3DS tidak didukung, seperti pada beberapa dompet digital. Lihat di bawah untuk beberapa contoh yang menunjukkan cara mencapai hal ini untuk berbagai contoh penggunaan. #### Minta 3D Secure berdasarkan tingkat risiko Radar Anda ingin menggunakan Radar untuk meminta 3DS pada semua pembayaran, berdasarkan tingkat risiko dan yang berada di atas jumlah tertentu. | Aturan Radar | Deskripsi | | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if :risk_level: != 'normal' and :amount_in_usd: > 25` | Aturan ini memeriksa tingkat risiko Radar sebelum meminta 3DS pada semua pembayaran dengan tingkat risiko meningkat atau tinggi di atas jumlah tertentu. | Dalam kasus ini, tanpa aturan blokir, kartu atau dompet digital yang tidak mendukung 3DS tidak diblokir. Upaya 3DS yang gagal diautentikasi tidak melanjutkan ke otorisasi penagihan. #### Selalu wajibkan 3D Secure berdasarkan tingkat risiko Radar Anda ingin menggunakan Radar untuk meminta 3DS pada semua pembayaran, berdasarkan tingkat risiko meningkat atau tinggi dan yang berada di atas jumlah tertentu. Anda tidak ingin mendukung kartu yang tidak mendukung 3DS. | Aturan Radar | Deskripsi | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if :risk_level: != 'normal' and :amount_in_usd: > 25` | Aturan ini memeriksa tingkat risiko Radar sebelum meminta 3DS pada semua penagihan dengan tingkat risiko meningkat atau tinggi di atas jumlah tertentu. | | `Block if not :is_3d_secure: and :risk_level: != 'normal' and :amount_in_usd: > 25 and not :is_off_session: and :digital_wallet: != 'apple_pay' and not (:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Aturan ini memblokir pembayaran berisiko meningkat atau tinggi di atas jumlah tertentu yang tidak memiliki alur 3DS. Aturan ini menerima pembayaran sah yang mungkin memiliki pengecualian SCA atau tidak memiliki kegagalan yang jelas maupun autentikasi yang berhasil, seperti `attempt_acknowledged`. Aturan ini memungkinkan pembayaran di luar sesi, seperti tagihan langganan berulang, dan dompet digital seperti Apple Pay atau Google Pay untuk berhasil diproses. | #### Hanya terima pembayaran yang sepenuhnya diautentikasi dengan 3D Secure jika 3D Secure didukung Anda mengandalkan Stripe untuk mengaktifkan 3DS bila diperlukan dalam kasus seperti [Autentikasi Pelanggan yang Kuat](https://stripe.com/guides/strong-customer-authentication) (SCA), tetapi tidak ingin menerima [kasus tepi](https://docs.stripe.com/api/charges/object.md#charge_object-payment_method_details-card-three_d_secure-result), seperti kesalahan pemrosesan. | Aturan Radar | Deskripsi | | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Blokir if :is_3d_secure: dan bukan :is_3d_secure_authenticated:` | Aturan ini memblokir pembayaran ketika kartu terdaftar dalam 3DS, dan 3DS telah dicoba tetapi pengguna tidak berhasil diautentikasi. Kartu yang tidak mendukung 3DS, pengecualian SCA, pembayaran di luar sesi (seperti tagihan langganan berulang), dan dompet digital (seperti Apple Pay atau Google Pay) tetap diterima. | #### Permintaan 3D Secure berdasarkan metadata Anda ingin menggunakan Radar untuk meminta 3DS pada semua pembayaran dengan atribut metadata khusus. | Aturan Radar | Deskripsi | | -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if ::foo:: = 'bar'` | Aturan ini memeriksa kondisi metadata lalu meminta 3DS. Untuk memeriksa metadata pelanggan, ganti `::foo:: = 'bar'` dengan nilai seperti `::customer:trusted:: = 'false'`. | Dalam kasus ini, tanpa aturan blokir, kami tidak memblokir kartu atau dompet digital yang tidak mendukung 3DS. Upaya 3DS yang gagal diautentikasi tidak melanjutkan ke otorisasi penagihan. #### Selalu wajibkan 3D Secure berdasarkan metadata Anda ingin menggunakan Radar untuk meminta 3DS pada semua pembayaran dengan atribut metadata khusus dan memblokir kartu yang tidak mendukungnya. | Aturan Radar | Deskripsi | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if ::foo:: = 'bar'` | Aturan ini memeriksa kondisi metadata lalu meminta 3DS. Untuk memeriksa metadata pelanggan, ganti `::foo:: = 'bar'` dengan nilai seperti `::customer:trusted:: = 'false'`. | | `Block if ::foo:: = 'bar' and not :is_3d_secure and not :is_off_session: and :digital_wallet: != 'apple_pay' and not(:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Aturan ini memblokir pembayaran yang tidak memiliki alur 3DS untuk penagihan dengan atribut metadata khusus. Aturan ini menerima pembayaran sah yang mungkin memiliki pengecualian SCA atau tidak memiliki kegagalan yang jelas maupun autentikasi yang berhasil, seperti `attempt_acknowledged`. Aturan ini memungkinkan pembayaran di luar sesi, seperti tagihan langganan berulang, dan dompet digital seperti Apple Pay atau Google Pay untuk berhasil diproses. | #### Minta 3D Secure untuk semua kartu baru dan tinjau apakah 3D Secure tidak didukung Anda ingin menggunakan Radar untuk meminta 3DS pada semua kartu baru dan meninjau secara manual pembayaran dari kartu yang tidak mendukung 3DS. | Aturan Radar | Deskripsi | | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Minta 3D Secure jika is_missing(:seconds_since_card_first_seen:)` | Aturan ini meminta 3DS pada semua kartu yang belum pernah digunakan di akun Anda. Untuk mengurangi hambatan bagi pengguna, Anda dapat menambahkan kondisi untuk hanya meminta 3DS jika `:risk_level: != 'normal'`. | | `Minta 3D Secure jika :is_new_card_on_customer:` | Sebagai alternatif dari aturan di atas, aturan ini meminta 3DS pada semua kartu yang baru digunakan pada [Account](https://docs.stripe.com/api/v2/core/accounts/object.md#v2_account_object-configuration-customer) atau [Customer](https://docs.stripe.com/api/customers.md) yang dikonfigurasi pelanggan. Untuk mengurangi hambatan bagi pengguna, Anda dapat menambahkan syarat untuk hanya meminta 3DS jika `:risk_level: != 'normal'`. | | `Review if not :is_3d_secure and not:is_off_session: and :digital_wallet: != 'apple_pay' and not(:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Aturan ini menandai pembayaran untuk ditinjau secara manual ketika 3DS diharapkan tetapi tidak didukung. Aturan ini mengabaikan pembayaran off-session, seperti tagihan langganan berulang, serta dompet digital seperti Apple Pay atau Google Pay. Pembayaran yang ditandai untuk ditinjau tetap melanjutkan proses otorisasi dan dapat memberikan faktor risiko tambahan, seperti hasil pemeriksaan CVC oleh penerbit. | Dalam kasus ini, tanpa aturan blokir, kami tidak memblokir kartu atau dompet digital yang tidak mendukung 3DS. Upaya 3DS yang gagal diautentikasi tidak melanjutkan ke otorisasi penagihan. #### Selalu wajibkan 3D Secure untuk sejumlah negara penerbit tertentu Anda ingin menggunakan Radar untuk meminta 3DS pada semua pembayaran dari penerbit kartu yang berasal dari negara-negara dalam [daftar khusus](https://docs.stripe.com/radar/lists.md) dan memblokir kartu yang tidak mendukungnya. | Aturan Radar | Deskripsi | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Minta 3D Secure jika :card_country: di @enforce_3ds_list` | Aturan ini memeriksa kondisi berdasarkan negara asal penerbit kartu dan membandingkannya dengan [daftar khusus](https://docs.stripe.com/radar/lists.md). Jika cocok, kami meminta 3DS. | | `Block if :card_country: in @enforce_3ds_list and not :is_3d_secure and not :is_off_session: and :digital_wallet: != 'apple_pay' and not(:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Aturan ini memblokir pembayaran yang tidak memiliki alur 3DS dan yang berasal dari negara-negara dalam daftar khusus. Aturan ini menerima pembayaran sah yang mungkin memiliki pengecualian SCA atau tidak memiliki kegagalan yang jelas maupun autentikasi yang berhasil, seperti `attempt_acknowledged`. Aturan ini memungkinkan pembayaran di luar sesi, seperti tagihan langganan berulang, dan dompet digital seperti Apple Pay atau Google Pay untuk berhasil diproses. | #### Selalu wajibkan 3D Secure berdasarkan tingkat risiko Radar dan tinjau kasus unik Anda ingin menggunakan Radar untuk meminta 3DS pada semua pembayaran berdasarkan tingkat risiko, dan memblokir kartu yang tidak mendukung 3DS, tetapi meninjau kasus tepi secara manual. | Aturan Radar | Deskripsi | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if :risk_level: != 'normal'` | Aturan ini memeriksa tingkat risiko Radar sebelum meminta 3DS pada semua pembayaran berisiko meningkat atau tinggi di atas jumlah tertentu. | | `Block if not :is_3d_secure: and :risk_level: != 'normal' and not :is_off_session: and :digital_wallet: != 'apple_pay' and not (:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Aturan ini memblokir pembayaran berisiko meningkat atau tinggi di atas jumlah tertentu dan yang tidak memiliki alur 3DS. Aturan ini menerima pembayaran sah yang mungkin memiliki pengecualian SCA. Aturan ini memungkinkan pembayaran di luar sesi, seperti tagihan langganan berulang, dan dompet digital seperti Apple Pay atau Google Pay untuk berhasil diproses. | | `Review if not :is_3d_secure_authenticated: and :risk_level: != 'normal' and not :is_off_session: and :digital_wallet: != 'apple_pay' and not (:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Aturan ini menandai pembayaran yang menggunakan 3DS, tetapi tidak menghasilkan alur autentikasi penuh, untuk ditinjau secara manual. Aturan ini meninjau [kasus tepi](https://docs.stripe.com/api/charges/object.md#charge_object-payment_method_details-card-three_d_secure-result), seperti `attempt_acknowledged`, dan juga menandai pembayaran sah meskipun ada pengecualian SCA. Karena aturan peninjauan dievaluasi setelah aturan blokir, kami memblokir kartu yang tidak mendukung 3DS. | ## Buat aturan Hanya pemilik akun, administrator, dan pengembang yang dapat membuat aturan. Jika Anda membutuhkan [anggota tim](https://support.stripe.com/questions/can-i-invite-other-team-members-or-my-developer-to-use-my-stripe-account) untuk membuat aturan, periksa [pengaturan tim](https://dashboard.stripe.com/settings/team) untuk memastikan mereka memiliki akses administratif. Aturan default Stripe dapat memblokir sejumlah besar pembayaran penipuan. Bisnis yang memerlukan kendali lebih besar atas pembayaran mana yang ingin mereka tinjau, izinkan, atau blokir dapat menulis aturan khusus melalui Radar for Fraud Teams. Platform dapat menulis aturan khusus melalui Radar for Platforms untuk mengkalibrasi risiko pembayaran bagi platform dan akun terhubung mereka serta menerapkan aturan khusus akun. Pertimbangkanlah hal berikut saat mengambil keputusan apakah akan mengaktifkan aturan custom: - Jika Anda melihat fitur tertentu atau perilaku pengguna tertentu sebagai lebih berisiko (misalnya, menggunakan email sekali pakai). - Jika Anda ingin menerapkan aturan berdasarkan metode pembayaran (misalnya, secara otomatis memblokir pembayaran Debit Langsung SEPA yang melebihi skor risiko tertentu). - Jika Anda ingin menerapkan aturan berdasarkan jumlah pembayaran atau tingkat risiko yang dipersepsikan (misalnya, otomatis tinjau jika pembayaran di atas 500 USD, otomatis izinkan jika pembayaran di bawah 5 USD). - Jika pembayaran Anda yang sudah disengketakan dan dikembalikan dananya memiliki pola umum tertentu (misalnya, jumlah yang serupa, jenis kartu, atau negara yang sama). - Jika Anda memiliki aturan yang sudah ada dan ingin memindahkannya ke Stripe. Model kecerdasan buatan Stripe mungkin sudah mencakup banyak aturan ini, dan Anda dapat memeriksa bagaimana sistem kami bekerja untuk bisnis Anda sebelum menyesuaikannya. - Jika Anda ingin secara otomatis menaikkan peninjauan dan secara opsional menjeda pencairan dana pada akun. Ini hanya berlaku untuk platform. ### Buat aturan yang efektif Walaupun aturan dapat membantu Anda mengotomatiskan alur kerja yang sudah ada, aturan juga dapat berdampak negatif pada bisnis Anda jika digunakan secara keliru. Sebagai contoh, sebuah aturan dapat secara otomatis mengizinkan sejumlah besar pembayaran berisiko meningkat atau tinggi, atau memblokir sejumlah besar pembayaran sah, jika tidak disiapkan dengan benar. Ingat hal-hal berikut saat menyiapkan aturan: - Secara default, aturan berlaku untuk semua [metode pembayaran yang didukung](https://docs.stripe.com/radar/supported-payment-methods.md) kecuali Anda mendefinisikan metode pembayaran tertentu dalam predikat aturan menggunakan atribut `payment_method_type`. - Aturan hanya berlaku untuk pembayaran di masa mendatang dan tidak berlaku untuk pembayaran yang sudah Anda proses. - Aturan Minta 3DS hanya berlaku ketika menggunakan [Stripe Checkout](https://docs.stripe.com/payments/checkout.md), [Payment Intents](https://docs.stripe.com/payments/accept-a-payment.md), atau [Setup Intents](https://docs.stripe.com/payments/save-and-reuse.md), dan dievaluasi sebelum aturan tinjauan, blokir, atau izinkan. - Sebelum menerapkan aturan blokir untuk memblokir semua pembayaran atau menjeda pencairan dana untuk akun yang memenuhi kriterianya, pertimbangkan apakah Anda lebih baik meninjau pembayaran atau akun tersebut terlebih dahulu. - Terapkan aturan izinkan seminimal mungkin, karena aturan tersebut mengesampingkan aturan default Stripe, bersama dengan aturan custom or Aturan custom lain yang memenuhi kriteria yang sama. - Anda dapat membuat maksimal 200 aturan transaksi dan 100 aturan akun. ## Bangun aturan transaksi Anda dapat menambahkan dan mengelola aturan dari halaman [Aturan Radar](https://dashboard.stripe.com/test/radar/rules) di Dashboard. #### Untuk menambahkan aturan transaksi 1. Klik **+ Tambahkan aturan**. 1. Pilih jenis aturan. 1. Di editor aturan, buat aturan menggunakan sintaks `{action} if {attribute} {operator} {value}` dengan: - `{action}`: adalah cara Radar merespons ketika kriteria aturan terpenuhi. Nilai ini diisi otomatis berdasarkan jenis aturan yang Anda pilih. - `{attribute}`: adalah elemen pembayaran yang dievaluasi, seperti jumlah atau jenis kartu. Mulailah mengetik dengan `:` untuk membuka daftar atribut yang valid. Anda juga dapat mengevaluasi metadata khusus Anda dengan menempatkannya di dalam titik dua ganda, misalnya, `::product_sku::`. - `{operator}`: adalah cara membandingkan atribut dengan nilai, seperti `=`, `>`, `!=`, dan seterusnya. - `{value}`: adalah nilai atribut yang akan dievaluasi. 1. Klik **Coba aturan**. 1. Perbaiki kesalahan validasi yang terdeteksi, jika perlu. 1. Di halaman **Tinjau aturan baru**, tinjau performa aturan ini terhadap pembayaran terbaru Anda untuk mengonfirmasi apakah Anda ingin mengaktifkannya. Jika aturan tersebut mungkin memengaruhi pembayaran dari lebih dari satu metode pembayaran, gunakan filter untuk melihat performa aturan berdasarkan metode pembayaran (misalnya, ACH atau Kartu). 1. Klik **Tambahkan aturan** untuk menerapkan aturan ini ke semua transaksi mendatang. ### Gunakan Radar Assistant Penyunting aturan Stripe memiliki asisten LLM bawaan yang menyusun aturan transaksi Radar dari perintah dalam bahasa alami. Pelajari lebih lanjut tentang [layanan AI Stripe](https://support.stripe.com/questions/use-of-artificial-intelligence-(ai)-pada layanan Stripe). > #### Persetujuan data pelatihan > > Dengan menggunakan Radar Assistant, Anda setuju bahwa Stripe dapat mencatat dan menggunakan entri percakapan Anda untuk melatih dan meningkatkan kemampuan Radar Assistant. Jika Anda tidak ingin entri percakapan Anda digunakan untuk tujuan ini, tulis aturan secara manual. #### Untuk menggunakan Radar Assistant 1. Pada [Halaman Aturan Radar](https://dashboard.stripe.com/test/radar/rules), klik **+ Tambahkan aturan**. 1. Pilih jenis aturan. 1. Di editor aturan, klik **Radar Assistant**. 1. Pada kolom pesan, masukkan permintaan aturan Anda. Anda mungkin ingin meminta untuk: - *Tinjau pembayaran dengan negara kartu dan IP yang berbeda.* - *Blokir pembayaran kartu Discover yang lebih dari $1000.* - *Izinkan pembayaran dari alamat email stripe.com.* 1. 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. 1. Setelah Anda puas dengan aturan tersebut, klik **Tambahkan aturan** untuk mengaktifkannya untuk semua transaksi di masa mendatang. > #### Bagikan masukan Anda > > Bantu kami untuk terus meningkatkan Radar Assistant. Klik **Bagikan masukan** dan beri tahu kami kinerja Assistant untuk Anda dan hal yang dapat kami lakukan untuk meningkatkannya. Kami menerima semua pendapat, baik tentang keakuratan saran, UI, atau aspek lain dari interaksi Anda. ### Aturan tinjauan Stripe tetap memproses pembayaran secara normal ketika pembayaran tersebut memenuhi kriteria aturan peninjauan. Kami menambahkan pembayaran-pembayaran ini ke [antrean peninjauan](https://dashboard.stripe.com/test/radar) Anda agar tim Anda dapat meninjaunya dengan lebih saksama. Menyiapkan aturan yang terlalu luas dapat menyebabkan terlalu banyak pembayaran masuk ke antrean peninjauan Anda, memperlambat pelanggan Anda dan membebani tim peninjauan Anda. Antarmuka pengujian aturan Stripe menjalankan simulasi pada tagihan selama 6 bulan terakhir untuk menentukan berapa banyak pembayaran sah, pembayaran penipuan, dan pembayaran yang diblokir yang akan terdampak oleh aturan tersebut, seandainya aturan itu telah diterapkan. Saat menguji aturan dan memeriksa 6 bulan terakhir, pastikan bahwa: - **Volume pembayaran secara keseluruhan rendah**. Meninjau pembayaran ini seharusnya tidak membebani tim Anda. - **Peninjau manusia menambah nilai**. Peninjau manusia umumnya dapat mengidentifikasi pembayaran yang tinggi atau berisiko tinggi dengan keyakinan yang lebih besar daripada sistem otomatis. - **Aturan ini menghasilkan campuran pembayaran yang berhasil dan dikembalikan atau disengketakan**. Artinya, pemeriksaan tambahan pada jenis pembayaran 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 | | ------------------------------------------------------------------- | ------------------------------------------------------------------------------ | | `if :card_funding: = 'prabayar'` | `if :is_disposable_email: and :card_funding: = 'prabayar'` | | Aturan ini terlalu luas dan menghasilkan terlalu banyak peninjauan. | Aturan ini lebih terfokus dan menghasilkan jumlah peninjauan yang lebih kecil. | ### Aturan blokir Anda dapat menggunakan aturan blokir untuk memblokir pembayaran yang Anda yakini sebagai penipuan, atau berdasarkan pembatasan apa pun yang diterapkan bisnis Anda (seperti memblokir pembayaran dari kartu prabayar). Jika Anda tidak yakin bagaimana menerapkan aturan blokir, kami menyarankan menggunakan aturan peninjauan untuk menempatkan pembayaran ke peninjauan. Setelah meninjau pembayaran-pembayaran ini untuk kemungkinan positif palsu, Anda dapat memastikan apakah Anda 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 memperbaiki aturan blokir yang dibuat oleh bisnis yang memiliki tingkat penipuan tinggi dari pembayaran di luar AS. | Aturan awal | Aturan disempurnakan | | ------------------------------------------------------------ | ------------------------------------------------------------------------------ | | `if :card_country: != 'US'` | `if :card_country: != 'US' and :risk_level: = 'meningkat'` | | Aturan ini terlalu luas dan memblokir banyak pembayaran sah. | Aturan ini lebih terfokus dan menghasilkan jumlah peninjauan yang lebih kecil. | ### Aturan izinkan Jika Anda ingin memiliki kemampuan membuat aturan izinkan, [hubungi kami](https://support.stripe.com/contact). 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. - **Terus memblokir pembayaran berisiko tinggi**. Blokir pembayaran berisiko tinggi dengan menambahkan yang berikut ini ke aturan izinkan apa pun: dan :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](https://docs.stripe.com/radar/rules/reference.md#supported-attributes) dan cari atribut yang berisi kata “customer”. Berikut adalah contoh cara memperbaiki aturan izinkan untuk bisnis yang umumnya (tetapi tidak selalu) menerima pembayaran sah dari pelanggan di Inggris: | Aturan awal | Aturan disempurnakan | | --------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | `if :ip_country: = 'GB'` | `if :ip_country: = 'GB' dan :risk_level: != 'tertinggi'` | | Aturan ini terlalu luas dan mengizinkan beberapa pembayaran penipuan. | Aturan ini lebih terfokus dan menghasilkan jumlah pembayaran penipuan yang diizinkan lebih sedikit. | ## Pelihara aturan Anda Seiring bisnis Anda terus berkembang, pastikan aturan Anda tetap mencerminkan jenis pelanggan yang ingin Anda layani. Berikut adalah beberapa praktik terbaik untuk menjaga agar aturan tetap sesuai dengan kondisi bisnis Anda. ### Pantau aturan secara berkala untuk memastikan aturan tersebut masih efektif #### Metrik aturan Pola penipuan terus berubah, jadi kami menyediakan [metrik](https://dashboard.stripe.com/settings/radar/rules) untuk menunjukkan cara kerja aturan ini. Metrik ini bervariasi menurut tipe aturan, karena tipe aturan melakukan tindakan yang berbeda. ![](https://b.stripecdn.com/docs-statics-srv/assets/rule-performance.8d495f28c352641ff7b710df3c3df2ed.png) Anda mungkin melihat perbedaan antara jumlah pembayaran yang cocok dengan aturan peninjauan dan jumlah pembayaran yang dikirim ke antrean peninjauan Anda dalam periode waktu yang sama. Karena hanya pembayaran yang *berhasil* yang ditempatkan ke peninjauan, pembayaran yang memenuhi kriteria aturan peninjauan tetapi ditolak oleh penerbit, misalnya, tidak dikirim ke antrean peninjauan Anda. Gunakan **bagan performa aturan** untuk memahami perilaku aturan Radar Anda. Cari lonjakan atau penurunan tak terduga dalam jumlah pembayaran yang sesuai dengan aturan Anda, seperti mengizinkan aturan yang mengizinkan terlalu banyak pembayaran atau aturan pemblokiran yang memblokir terlalu banyak. Lonjakan ini mungkin mengindikasikan perubahan dalam jenis pembayaran yang diterima bisnis Anda atau yang mungkin memerlukan pembaruan aturan. **Baris berkode warna** melacak jumlah pembayaran yang cocok [3DS](https://docs.stripe.com/issuing/3d-secure.md) aturan, mengizinkan aturan, memblokir aturan, dan meninjau aturan. Aturan yang diperbarui ditampilkan sebagai **simbol segitiga** pada garis grafik, dan dapat membantu Anda membandingkan dampak perubahan sebelum dan sesudah Anda membuatnya. Klik menu overflow (⋯) untuk melihat perintah tambahan untuk aturan apa pun, termasuk **Nonaktifkan**, **Aktifkan**, **Edit** atau **Hapus**. Anda juga dapat menggunakan produk pelaporan kami, Sigma dan Data Pipelines, untuk [query data sengketa dan penipuan](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md), termasuk keputusan aturan dan atribut untuk setiap pembayaran individual. #### Lakukan evaluasi keefektifan aturan Anda dapat menemukan informasi tentang efektivitas aturan Anda dan melihat berapa banyak pembayaran yang telah dipengaruhi oleh setiap aturan. Anda juga dapat melihat dan mengunduh daftar tersaring dari setiap pembayaran yang telah dikenai suatu aturan. Tinjau contoh pertanyaan dalam tabel berikut untuk membantu Anda memutuskan apakah Anda perlu membuat perubahan pada aturan tertentu atau menghapusnya sepenuhnya. | Jenis aturan | Evaluasi | Tindakan untuk dipertimbangkan | | --------------- | ---------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Umum | Jika aturan ini tidak lagi cocok dengan pembayaran apa pun. | Hapus aturan. | | | Jika aturan ini memiliki perilaku tak normal, seperti mengizinkan lebih banyak pembayaran daripada periode waktu sebelumnya. | Tinjau secara manual pembayaran yang cocok dengan aturan ini untuk menentukan apakah ini perilaku yang Anda inginkan. | | 3DS | Jika tingkat penyelesaian 3DS tinggi, tetapi jumlah sengketa atau peringatan dini penipuan rendah. | Hapus aturan tersebut karena Anda mungkin menimbulkan hambatan bagi pengguna Anda. | | | Jika penipuan tinggi untuk transaksi yang melewati 3DS | Pertimbangkan untuk mengubah aturan 3DS Anda menjadi aturan blokir untuk mencegah pengguna ini lolos melalui alur tanpa hambatan (yang dikendalikan oleh penerbit) atau melakukan penipuan pihak pertama. | | | Jika rasio konversi untuk 3DS rendah. | Ini mungkin merupakan aturan yang efektif karena kemungkinan besar aturan ini memblokir penipu. Pertimbangkan untuk menyelidiki secara manual pembayaran yang cocok untuk memastikan pengguna baik Anda tidak meninggalkan transaksi karena adanya hambatan tambahan. | | Izinkan | Jika jumlah sengketa, peringatan dini penipuan, pengembalian dana, atau pembayaran gagal tinggi. | Hapus aturan yang mengizinkan pemrosesan pembayaran buruk. | | Blokir | Jika jumlah pemblokiran menurun, tetapi penipuan Anda tetap 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 aturan tersebut mungkin memblokir pengguna baik. | | | Jika jumlah pemblokiran meningkat, dan penipuan Anda menurun. | Ini mungkin merupakan aturan yang efektif. Pertimbangkan untuk meninjau secara manual beberapa transaksi untuk memastikan Anda tidak memblokir terlalu banyak pengguna baik. | | Tinjauan Manual | Jika persentase pembayaran yang ditinjau rendah. | Buat aturan lebih ketat karena aturan tersebut mungkin terlalu luas. | | | Jika jumlah pembayaran yang berhasil atau disetujui tinggi. | Hapus seluruh aturan peninjauan manual, atau tulis aturan izinkan untuk menargetkan pembayaran tersebut. | | | Jika jumlah pengembalian dana atau sengketa dan peringatan dini penipuan tinggi. | Konversikan ke aturan blokir. | #### Minta aturan 3DS Untuk aturan permintaan 3DS, kami menampilkan **3DS Requested**, yang merupakan berapa kali aturan memicu permintaan 3DS. Anda dapat mengklik aturan 3DS untuk melihat metrik berikut. ![](https://b.stripecdn.com/docs-statics-srv/assets/request-credentials-rule-details.c22b65bc432aafec9e5bcb6079c53528.png) **Aturan izinkan** Jika Anda menggunakan Radar for Fraud Teams, Anda dapat melihat aturan izinkan berikut: - **Pembayaran yang diizinkan**. jumlah 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**: Yang sesuai [hasil risiko](https://docs.stripe.com/radar/risk-evaluation.md#risk-outcomes) ditetapkan oleh model AI kami ke kumpulan pembayaran yang diizinkan oleh aturan Anda. - **Sengketa dari pengesampingan**. Jumlah total pembayaran diizinkan yang dipersengketakan. - **Volume, sengketa dari pengesampingan**. jumlah total uang setempat, dikaitkan dengan sengketa dari pembayaran yang diizinkan. > Jika metrik sengketa tinggi, Anda mungkin perlu menulis aturan izinkan yang lebih sempit sasarannya, untuk mencegah pembayaran yang pada akhirnya disengketakan agar tidak lolos. Pilih aturan izinkan untuk melihat metrik berikut: ![](https://b.stripecdn.com/docs-statics-srv/assets/allow-rule-details.e8da078613fdbca5592d2f9330c0f6d4.png) **Aturan blokir** Anda dapat melihat aturan blokir berikut: - **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. Jika Anda menggunakan Radar for Fraud Teams, Anda juga dapat melihat hal berikut: - **Skor risiko**: Yang sesuai [hasil risiko](https://docs.stripe.com/radar/risk-evaluation.md#risk-outcomes) ditetapkan oleh model AI kami ke kumpulan pembayaran yang diizinkan oleh aturan Anda. - **Perkiraan tingkat positif palsu**: Perkiraan persentase pembayaran non-penipuan yang diblokir untuk aturan pemblokiran Anda sebagai satu set dan aturan perorangan. Perkiraan ini dibuat menggunakan perkiraan tingkat positif palsu dari skor risiko AI yang sesuai, yang kami hitung dengan eksperimen di seluruh jaringan Stripe. - **Estimasi pembayaran penipuan dicegah**: Perkiraan jumlah pembayaran penipuan yang dicegah oleh aturan pemblokiran Anda. Stripe menggunakan skor risiko AI, yang dihitung dengan menganalisis jutaan transaksi di seluruh jaringan Stripe, untuk memprediksi pembayaran dengan kemungkinan besar dibantah atau ditolak karena penipuan, dan memperkirakan pembayaran mana yang berhasil diblokir oleh aturan Anda. > Jika metrik perkiraan tingkat positif palsu tinggi, Anda mungkin perlu menulis aturan blokir yang lebih sempit sasarannya atau meninjau pembayaran mana yang dicakup oleh aturan tersebut, untuk menghindari memblokir terlalu banyak pembayaran nonpenipuan. Pilih aturan blokir untuk melihat metrik berikut: ![](https://b.stripecdn.com/docs-statics-srv/assets/block-rule-details.5df9a2e8652f228cf61b525a32ef56da.png) **Aturan tinjau** Jika Anda menggunakan Radar for Fraud Teams, Anda dapat melihat aturan peninjauan berikut: - **Pembayaran yang dikirim untuk ditinjau**: Jumlah total pembayaran yang dikirim ke peninjauan manual menurut 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 ulasan yang disetujui**: Jumlah total pembayaran yang disetujui dalam ulasan Anda, tetapi akhirnya disengketakan. - **Volume, sengketa dari tinjauan yang disetujui**. Jumlah total, dalam mata uang setempat, yang dikaitkan dengan sengketa dari tinjauan pembayaran yang disetujui. Pilih aturan peninjauan untuk melihat metrik berikut: ![](https://b.stripecdn.com/docs-statics-srv/assets/review-rule-details.10851302ef65dee05ffce64f7989528f.png) #### Lihat Riwayat Aturan Anda dapat meninjau riwayat perubahan yang dilakukan terhadap aturan Radar. Jejak audit ini membantu memahami kapan suatu aturan dibuat, disunting, diaktifkan, dinonaktifkan, serta oleh pengguna mana dalam tim. Untuk melihat aktivitas aturan tertentu, buka tab [Aturan](https://dashboard.stripe.com/radar/rules) pada halaman Radar dan klik nama aturan tersebut. Log **Aktivitas Aturan** menampilkan ringkasan semua modifikasi. Klik kejadian tertentu untuk melihat detail selengkapnya, seperti predikat aturan lengkap sebelum dan sesudah pembaruan. Anda hanya dapat melihat perubahan aturan selama 180 hari terakhir. Meninjau aktivitas ini secara rutin dapat membantu Anda mengaitkan perubahan aturan dengan dampaknya terhadap bisnis. ### Pantau antrean peninjauan manual Anda secara berkala Jika antrean peninjauan Anda terlalu besar untuk dikelola, pastikan Anda memiliki aturan yang tepat. Jika sebagian besar peninjauan berakhir dengan pengembalian dana karena penipuan, pertimbangkan aturan tambahan untuk memblokir pembayaran. Jika sebagian besar pembayaran disetujui, pertimbangkan untuk membuat aturan peninjauan Anda lebih terfokus. ### Menganalisis pembayaran yang disengketakan dan dikembalikan dananya [Sengketa](https://docs.stripe.com/disputes.md) secara inheren berkaitan dengan penipuan, sehingga semakin banyak yang Anda lakukan untuk mengurangi penipuan, semakin rendah tingkat sengketa Anda. Periksa apakah pembayaran yang disengketakan memiliki karakteristik serupa (misalnya, dari lokasi yang sama atau dengan jumlah yang serupa). Anda juga dapat melakukan jenis investigasi ini dengan melihat pembayaran yang dikembalikan dananya selama peninjauan. Jika Anda melihat tren, Anda dapat menguji dan membuat aturan yang sesuai. Jika ada pembayaran yang tampak sebagai penipuan, kembalikan dana 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](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md). Anda dapat merespons setiap sengketa yang masuk menggunakan Dashboard atau melalui API, dan [dokumentasi sengketa](https://docs.stripe.com/disputes.md) kami akan menyertakan beberapa saran tentang cara menyajikan kasus yang terdokumentasikan dengan baik. ### Antisipasi perubahan besar pada bisnis Anda yang mungkin memengaruhi tingkat penipuan Anda Jika Anda merencanakan peluncuran produk besar atau perubahan besar pada layanan Anda (misalnya, produk baru dengan nilai tinggi atau memperluas layanan Anda ke negara baru), Anda mungkin ingin memantau pembayaran-pembayaran ini pada awalnya. Untuk perubahan semacam ini, praktik yang baik adalah menyiapkan beberapa aturan peninjauan agar Anda dapat memeriksa pembayaran baru. Meninjau pembayaran-pembayaran ini dan mengidentifikasi polanya dapat membantu Anda menyiapkan aturan baru untuk membantu melindungi bisnis Anda dari penipuan. ## Aturan mendukung beberapa metode pembayaran Secara default, aturan Radar menyaring pembayaran untuk kartu, ACH, dan Debit Langsung SEPA untuk sebagian besar pengguna. Kami mendukung aturan pemblokiran berisiko tinggi untuk semua metode pembayaran ini. Jika Anda menggunakan atribut Radar for Fraud Teams atau Radar for Platforms, kami juga mendukung aturan kustom menggunakan atribut `:p ayment_method_type:` untuk menulis aturan yang hanya berlaku untuk metode pembayaran tertentu, misalnya: `if :p ayment_method_type: = 'us_bank_account'. Pelajari lebih lanjut tentang .` ## Bangun aturan akun Dengan Radar for Platforms, Anda juga dapat menambahkan dan mengelola aturan akun dari tab **Aturan** di halaman Radar di Dasbor. #### Untuk menambahkan aturan akun 1. Klik **+ Tambahkan aturan**. 1. Pilih jenis aturan: **Tinjauan** atau **Jeda pembayaran** (yang memunculkan peninjauan DAN jeda pembayaran). 1. Di editor aturan, buat aturan menggunakan sintaks `{action} if {attribute} {operator} {value}` dengan: - `{action}`: adalah cara Radar merespons ketika kriteria aturan terpenuhi. Nilai ini diisi otomatis berdasarkan jenis aturan yang Anda pilih. - `{attribute}`: adalah elemen pembayaran yang dievaluasi, seperti jumlah atau jenis kartu. Mulailah mengetik dengan `:` untuk membuka daftar atribut yang valid. - `{operator}`: adalah cara membandingkan atribut dengan nilai, seperti `=`, `>`, `!=`, dan seterusnya. - `{value}`: adalah nilai atribut yang akan dievaluasi. 1. Klik **Coba aturan**. 1. Perbaiki kesalahan validasi yang terdeteksi, jika perlu. 1. Di halaman **Tinjau aturan baru**, lihat akun yang cocok dengan aturan ini hari ini untuk mengonfirmasi apakah Anda ingin mengaktifkannya. 1. Klik **Aktifkan aturan** untuk menerapkan aturan ini ke semua akun yang ada dan yang akan datang. Pengujian aturan tingkat akun membutuhkan waktu lebih lama dibandingkan pengujian transaksi, namun kami merekomendasikan pengujian untuk menghindari secara tidak sengaja menaikkan akun ke peninjauan atau menjeda pencairan dana otomatis. Pertama, uji perilaku menaikkan akun ke peninjauan. Lalu, uji jeda pencairan dana otomatis setelah Anda yakin aturan tersebut memengaruhi akun seperti yang diharapkan. ## See also - [Contoh aturan 3DS](https://docs.stripe.com/radar/rules.md#request-3d-secure) - [Panduan pengelolaan penipuan berkelanjutan](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data) - [Data penipuan dan sengketa query](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md) - [Referensi aturan](https://docs.stripe.com/radar/rules/reference.md) - [Atribut yang didukung](https://docs.stripe.com/radar/rules/supported-attributes.md)