Referensi aturan

Sebelum membuat aturan, Anda perlu memahami cara pemrosesannya dan atribut pembayaran yang dapat Anda gunakan untuk mengatur kriteria evaluasi. Sistem penipuan pembelejaran mesin Stripe dapat memblokir banyak pembayaran penipuan bagi Anda, tetapi Anda dapat juga mengatur aturan yang unik bagi bisnis Anda memakai atribut yang didukung.

Pemrosesan dan urutan aturan

Radar mengevaluasi setiap pembayaran terhadap aturan yang Anda buat sesuai dengan jenis tindakannya, dengan menggunakan prioritas berikut:

1. Minta 3DS: Aturan yang bila digunakan dengan Payment Intents API atau Checkout, meminta penerbit melakukan autentikasi 3D Secure jika didukung. Radar akan mengevaluasi ini sebelum aturan blokir, tinjau, atau izinkan.
2. Izinkan: Aturan yang mengizinkan pembayaran agar diproses. Pembayaran yang masuk dalam aturan izinkan tidak dievaluasi terhadap aturan blokir atau tinjauan mana pun.
3. Blokir: Aturan yang memblokir pembayaran dan penolakannya. Pembayaran yang diblokir tidak dievaluasi terhadap aturan tinjauan mana pun.
4. Tinjau: Aturan yang mengizinkan pemrosesan pembayaran tetapi selanjutnya menempatkannya dalam tinjauan.

Aturan dengan jenis tindakan yang sama tidak diurutkan.

Jika pembayaran sesuai dengan kriteria suatu aturan, Radar akan mengambil tindakan yang sesuai dan menghentikan evaluasi. Sebagai contoh, jika pembayaran sesuai dengan aturan izinkan, pembayaran akan diproses secara normal, tanpa mengevaluasi aturan blokir atau tinjau berikutnya, meskipun pembayaran tersebut juga memenuhi kriteria aturan tersebut. Contoh kumpulan aturan adalah sebagai berikut:

• Izinkan pembayaran yang kurang dari $10
• Izinkan pembayaran yang dilakukan di dalam AS dan dengan tingkat risiko normal
• Blokir pembayaran yang tingkat risikonya high
• Blokir pembayaran yang greater than $1,000
• Tinjau pembayaran yang dilakukan dengan kartu yang dikeluarkan outside the US

Menggunakan aturan di atas:

• Semua pembayaran yang kurang dari 10 USD akan diproses, terlepas dari tingkat risiko atau lokasi penerbitnya. Karena aturan pertama mengizinkan pembayaran, tidak ada aturan lebih lanjut yang dievaluasi.
• Pembayaran 1.500 USD yang dilakukan di AS dengan tingkat risiko normal diproses secara normal karena memenuhi kriteria aturan kedua, sehingga tidak dievaluasi berdasarkan aturan untuk memblokir pembayaran di atas 1.000 USD.
• Pembayaran berisiko tinggi di atas 1.000 USD diblokir karena tidak memenuhi kriteria dari salah satu aturan yang mengizinkan, kemudian memicu kedua aturan blokir, terlepas dari urutan evaluasinya.

Struktur aturan

Struktur aturan memiliki dua komponen—tindakan yang harus diambilnya dan kondisi untuk mengevaluasi:

{action} if {condition}

Semua itu mewakili predikat. Pada praktiknya, aturan untuk memblokir semua pembayaran di atas USD1.000 akan tampak sebagai:

Block if :amount_in_usd: > 1000.00

• Tindakannya adalah Block
• Kondisinya adalah :amount_in_usd: > 1.000,00

Tindakan

Aturan melakukan salah satu dari empat tindakan yang dijelaskan di bagian ini ketika pembayaran memenuhi kriterianya. Urutan jenis tindakan berikut ini menunjukkan prioritas yang diikuti Radar ketika mengevaluasi setiap aturan.

Minta 3D Secure

Bila digunakan dengan Payment Intents API, aturan ini menentukan apakah Stripe meminta penerbit mencoba autentikasi 3D Secure. Meminta 3DS saja tidak memblokir semua kemungkinan hasil 3D Secure. Apakah ada kecocokan atau tidak pada aturan ini, kami mengevaluasi aturan izinkan, blokir, dan tinjau sesudahnya.

Izinkan

Aturan ini menentukan kapan untuk mengizinkan pembayaran yang memenuhi kriteria tertentu, tanpa memandang aturan Anda lainya yang sesuai. Bila pembayaran sesuai dengan kriteria dalam aturan izinkan, hal itu tidak tunduk pada evaluasi aturan Radar lebih lanjut. Stripe memproses pembayaran secara normal, tetapi penerbit kartu mungkin masih menolaknya.

Blokir

Aturan blokir menyarankan Stripe untuk selalu memblokir pembayaran. Jika pembayaran cocok dengan kriteria dalam aturan blokir, maka Stripe akan menolaknya, dan pembayaran tidak akan tunduk pada evaluasi aturan lebih lanjut.

Tinjau

Anda mungkin ingin mengizinkan tipe pembayaran tertentu tetapi juga memiliki opsi untuk mempelajarinya lebih dekat. Dengan aturan tinjauan. Dengan aturan tinjauan, Anda dapat menempatkan pembayaran dalam tinjauan. Ini terutama bermanfaat untuk pembayaran yang tidak masuk dalam pola bersama, seperti pembayaran yang lebih besar atau pembayaran yang berasal dari negara yang jarang Anda layani pengirimannya. Stripe masih memroses pembayaran dan charge ini kepada pelanggan, tetapi Anda memiliki kesempatan ekstra untuk meninjau pesanan dan memeriksa tanda-tanda penipuan.

Ketika aturan tertentu dipicu, Radar mengambil tindakan yang ditentukan dan menghentikan evaluasi aturan lebih lanjut.

Kondisi

Jika pembayaran cocok dengan kondisi aturan, maka tindakan terkait akan diambil. Kondisi dasarnya itu sendiri terdiri dari tiga bagian:

[attribute] [operator] [value]

• Atribut: Atribut pembayaran (misalnya _jumlah _ atau tipe kartu)
• Operator: Aritmatika yang membandingkan atribut dengan nilai (misalnya lebih besar dari atau tidak sama dengan)
• Nilai: Kriteria yang ingin Anda gunakan (misalnya, 100.00 atau debit)

Memadukan kedua tindakan dan kondisi ini maka struktur aturannya adalah:

{action} if {[attribute] [operator] [value]}

Ada empat tipe kondisi, bergantung tipe atribut:

• [string_attribute] [operator] [string_value]
• [country_attribute] [operator] [country_value]
• [numeric_attribute] [operator] [numeric_value]
• [boolean_attribute]

Anda juga dapat menggunakan atribut sebagai nilai yang terkait di dalam suatu kondisi. Misalnya, Anda dapat membuat aturan untuk memblokir pembayaran yang negara penerbit kartunya tidak cocok dengan negara tempat pembayaran dilakukan:

Block if :card_country: != :ip_country:

Untuk daftar semua syarat yang memungkinkan, lihat atribut yang didukung.

Atribut string

Ini berisi segala kombinasi karakter. Atribut dan nilai string yang paling umum mewakili bagian teks, seperti brand kartu (misalnya, visa, amex) atau tingkat risiko (misalnya, elevated). Anda dapat menggunakannya dalam aturan untuk mengizinkan pembayaran dari negara tertentu saja, atau memblokir pembayaran yang dibuat dengan kartu prabayar.

Atribut metadata

Atribut ini diturunkan dari metadata yang telah Anda kaitkan pada pembayaran Anda. Atribut metadata dapat beroperasi baik sebagai string atau angka. Ketika dipakai sebagai string, atribut metadata adalah case-sensitive.

Anda dapat menggunakan atribut ini saat membuat aturan Stripe Radar, sehingga Anda dapat membuat aturan pada atribut bisnis khusus apa saja yang Anda teruskan ke Stripe dalam bidang metadata yang melekat pada pembayaran Anda.

Atribut metadata tertulis dalam struktur berikut:

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

Misalnya, katakan kita memiliki pembayaran dengan data nilai kunci tersimpan dalam bidang metadata berikut:

Anda dapat menulis aturan untuk menempatkan pembayaran yang cocok dengan kriteria berikut ke dalam tinjauan.

Review if ::Customer Age:: < 30

Anda juga dapat menulis aturan menggunakan atribut metadata maupun atribut yang didukung lainnya disebut dalam dokumen ini. Misalnya, Anda dapat menulis aturan yang hanya menempatkan pembayaran dalam tinjauan jika Item ID cocok dengan 5A381D dan jumlah pembayaran melebihi USD1.000.

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

Atribut metadata juga mendukung operator IN agar cocok dengan beberapa nilai. Misalnya, Anda dapat menulis aturan yang menempatkan poembayaran dalam tinjauan jika Category ID adalah salah satu toko kelontong, elektronik, atau pakaian.

Review if ::Category ID:: IN ('sembako', 'elektronik', 'pakaian')

Anda dapat menggunakan operator INCLUDES dengan aturan untuk atribut metadata dan atribut string lainnya agar cocok dengan substring. Misalnya, Anda dapat menulis aturan yang menempatkan pembayaran dalam tinjauan jika Item ID mencakup string A381. Ini cocok dengan A381, 5A381D, A381D, 5A381, dan lain-lain.

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

Metadata pada Objek Pelanggan dan Tujuan

Anda juga dapat mengakses metadata pada objek pelanggan dan tujuan (jika objek digunakan untuk suatu pembayaran). Atribut ini menggunakan struktur berikut:

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

Misalnya, katakan Anda memiliki pelanggan dengan metadata berikut:

Anda dapat menulis aturan yang selalu mengizinkan pembayaran jika bidang metadata Tepercaya adalah true.

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

Atau jika Anda memiliki tujuan dengan metadata berikut:

Anda dapat menulis aturan yang menempatkan pembayaran dalam tinjauan jika bidang metadata Category dari tujuan adalah new.

Review if ::destination:Category:: = 'baru'

Atribut negara

Ini menggunakan kode negara dua huruf untuk mewakili sebuah negara, seperti US untuk Amerika Serikat, GB untuk Britania Raya, atau AR untuk Argentina. Atribut negara beroperasi dengan cara yang sama dengan atribut string, satu-satunya perbedaannya adalah nilainya harus berupa kode negara.

Atribut negara bagian

Ini menggunakan kode ISO untuk mewakili negara bagian atau subdivisi utama sebuah negara, seperti CA untuk mewakili California dari Amerika Serikat, ENG untuk mewakili Inggris yang merupakan bagian dari Britania Raya, atau L untuk mewakili La Pampa yang merupakan bagian dari Argentina. Kami menghilangkan kode negara dua huruf dari kode ISO negara bagian, jadi jika ingin memblokir transaksi dari California, bandingkan atribut negara bagian dengan CA.

Blokir jika :ip_state: = 'CA'

Atribut negara bagian beroperasi dengan cara yang sama dengan atribut string, satu-satunya perbedaannya adalah nilainya harus berupa kode ISO.

Atribut numerik

Karena ini hanya mengandung angka saja, maka lebih banyak operator yang didukung daripada atribut dan nilai string. Jumlah pembayaran adalah salah satu contoh atribut numerik. Anda dapat membuat aturan untuk melaksanakan tindakan jika jumlahnya lebih tinggi, lebih rendah, sama dengan, atau tidak sama dengan jumlah yang Anda tetapkan.

Untuk atribut numerik yang merupakan hitungan dalam suatu rentang waktu, hitungan ini tidak termasuk pembayaran yang saat ini sedang Anda proses. Misalnya total_charges_per_customer_hourly mewakili jumlah upaya charge sebelumnya dari suatu pelanggan pada jam sebelumnya. Karena itu, untuk upaya charge pertama dalam suatu jam bagi suatu pelanggan, total_charges_per_customer_hourly bernilai 0. Untuk upaya charge kedua dalam jam yang sama, maka nilainya 1, dan seterusnya.

Atribut waktu sejak pertama kali dilihat juga tidak memperhitungkan pembayaran yang sedang Anda proses. Misalnya, pembayaran tanpa email memiliki nilai yang hilang untuk seconds_since_email_first_seen. Begitu juga pembayaran dengan email yang belum pernah terlihat sebelumnya di akun Anda (karena kami tidak menyertakan pembayaran yang saat ini sedang diproses, ini secara efektif merupakan perilaku yang sama seperti contoh pertama). Lihat di bawah untuk detail selengkapnya tentang nilai yang hilang. Bidang seconds_since_email_first_seen hanya non-null setelah pembayaran baru dengan email yang diberikan diproses.

Atribut numerik terbatas

Atribut numerik terbatas mirip dengan atribut numerik yang dijelaskan di atas. Misalnya, mereka mengecualikan pembayaran yang sedang Anda proses. Perbedaannya adalah bahwa nilai yang tersedia untuk atribut numerik terbatas dibatasi (atau bounded) pada nilai tertentu.

Sebagai contoh, ambil authorized_charges_per_email_hourly yang menunjukkan jumlah charge sebelumnya yang diotorisasi untuk email dalam satu jam terakhir di akun Anda. Demi contoh, katakanlah ini memiliki batas 5. Untuk upaya charge pertama dalam satu jam terakhir dengan email jenny.rosen@example.com penghitung memiliki nilai 0. Upaya charge berikutnya dalam jam yang sama mendapat nilai penghitung yang lebih tinggi. Setelah mengesahkan charge ke-6 dalam waktu satu jam dari jenny.rosen@example.com, penghitung berhenti bertambah dan tetap di 5 meskipun sebenarnya mendapatkan upaya charge 6 dalam satu jam terakhir.

Jika upaya untuk menaikkan penghitung di atas batas terjadi, kami mengecualikan nilai yang lebih lama dari pertimbangan dan menggantinya dengan nilai yang lebih baru. Misalnya, pertimbangkan penghitung dengan batas 3 yang telah diisi dengan 3 charge. Salah satu cara untuk memvisualisasikan penghitung adalah dengan menyimpan daftar stempel waktu yang mewakili waktu kedatangan charge: [10, 20, 30] misalnya. Ketika charge tiba pada waktu 50, penghitung sekarang terlihat seperti [20, 30, 50].

Atribut boolean

Atribut boolean mewakili apakah suatu atribut tertentu itu benar. Tidak seperti atribut string dan numerik, atribut boolean tidak memiliki operator atau nilai. Anda dapat menggunakan atribut Boolean untuk memblokir pembayaran yang telah dibuat dengan alamat email sekali pakai, atau menempatkan pembayaran dalam tinjauan yang dibuat dengan alamat IP anonim.

Atribut pasca otorisasi

Atribut pascaotorisasi (misalnya :cvc_check:, :address_zip_check:, or :address_line1_check:) mengharuskan Stripe bertukar data dengan penerbit kartu sebagai bagian dari proses otorisasi. Penerbit kartu memverifikasi data ini dengan informasi yang ada dalam catatan mereka untuk pemegang kartu dan memeriksa kesamaannya. Aturan yang menggunakan pascaotorisasi dieksekusi setelah aturan yang tidak menggunakan atribut pascaotorisasi. (Hal ini tidak akan memengaruhi apakah suatu charge diblokir atau tidak, melainkan berdampak pada aturan yang memblokir charge.)

Jika Anda menggunakan atribut pasca otorisasi dalam suatu aturan, maka rekening koran pelanggan Anda sementara dapat menampilkan otorisasi meski jika charge itu pada akhirnya diblokir—otorisasi umumnya hilang setelah beberapa hari.

Atribut (AVS) alamat dan CVC memiliki lima kemungkinan nilai:

Beberapa contoh aturan:

• Block if :address_line1_check: = 'gagal'
• Blokir jika :cvc_check: = 'fail'
• Block if :address_zip_check: di ('gagal', 'not_provided')

Pengharusan pass yang ketat pada aturan dapat terlalu membatasi. Sebagai contoh, dompet digital biasanya tidak menyediakan CVC karena menyimpan informasi kartu yang diubah menjadi token. Oleh karena itu, pemeriksaan CVC, seperti pemeriksaan 3D-Secure, tidak tersedia untuk metode pembayaran seperti Apple Pay. Stripe merekomendasikan penggunaan Aturan bawaan Radar, yang mempertimbangkan kasus unik ini.

Atribut yang didukung

Lihat daftar semua atribut yang didukung untuk daftar lengkap atribut yang dapat Anda terapkan pada definisi aturan.

Jumlah yang dikonversi

Saat menggunakan amount_in_xyz, Stripe secara otomatis menentukan jumlah yang dikonversi dari pembayaran saat memeriksa apakah jumlah tersebut sesuai dengan kriteria yang dipilih. Misalnya, jika Anda membuat aturan menggunakan amount_in_usd untuk memblokir semua pembayaran yang lebih besar dari 1.000 USD, Stripe memblokir pembayaran dengan jumlah nominal lebih rendah dalam mata uang berbeda (misalnya 900 GBP) jika nilai konversi yang setara melebihi 1.000 USD.

“Mempertimbangkan pembayaran mulai tahun 2020 dan seterusnya” dalam praktik

Deskripsi beberapa atribut aturan termasuk frasa “memperhitungkan pembayaran mulai tahun 2020 dan seterusnya”. Artinya, aturan tersebut memperlakukan kartu yang terakhir kali ditransaksikan dengan bisnis Anda di tahun 2019 sama dengan kartu baru di bisnis Anda. Pertimbangkan dengan cermat apa artinya ini dalam konteks bisnis dan aturan Anda karena dapat mengakibatkan perilaku yang berlawanan dengan intuisi. Misalnya, jika Anda membuat aturan untuk memblokir pembayaran bernilai tinggi dari kartu baru, Anda mungkin akan memblokir pelanggan baik yang belum melakukan pembelian sejak 2019.

“Atribut ini hanya mencakup objek Pelanggan mode live yang berinteraksi dengan akun Anda dalam satu <week, year> terakhir. Data ini diperbarui paling banyak setiap 72 jam.” sedang diterapkan

Keterangan beberapa atribut aturan termasuk kalimat “Atribut ini hanya mencakup objek Pelanggan mode live yang berinteraksi dengan akun Anda dalam <week, year> terakhir. Data ini diperbarui paling banyak setiap 72 jam.” Ini berarti bahwa objek Pelanggan mode live yang dibuat, di-charge, atau diperbarui di akun Anda dalam satu minggu, atau tahun terakhir termasuk dalam penghitungan ini. Namun, penghitungan tidak segera diperbarui dan mungkin memerlukan waktu hingga 72 jam untuk menyebar melalui sistem, meskipun sering kali penghitung ini diperbarui lebih cepat dari 72 jam.

Operator

Operator suatu kondisi menunjukan perbandingan antara atribut pembayaran dan nilai yang Anda berikan. Operator berbeda tersedia, bergantung pada tipe atribut yang sedang digunakan.

Daftar

Anda dapat mereferensikan sekelompok nilai dalam aturan Anda melalui daftar. Semua alias daftar yang direferensikan dalam aturan harus dimulai dengan @. Untuk mengonstruksikan suatu aturan yang mereferensikan suatu daftar, ikuti struktur ini:

{action} [attribute] dalam [list]

Misalnya, katakan Anda memiliki daftar negara kartu yang ingin Anda blokir. Anda dapat menulis aturan menggunakan beberapa klausul OR:

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

Anda juga dapat menulis aturan menggunakan daftar sisip:

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

Anda juga dapat membuat daftar negara penerbit kartu yang ingin Anda blokir, bernama card_countries_to_block. Selanjutnya Anda menambahkan negara-negara pilihan ke daftar dan mereferensikan daftar itu dalam aturan:

Block if :card_country: in @card_countries_to_block

Mereferensikan daftar dalam aturan memungkinkan Anda untuk mengedit item dalam jumlah besar di satu tempat daripada memelihara banyak aturan satu per satu.

Tidak ada atribut

Kondisi aturan khusus merujuk pada atribut yang diatur pada setiap pembayaran, seperti :card_country: (yang diatur pada setiap charge berbasis kartu) atau suatu atribut metadata yang selalu Anda kirim bersama permintaan pembayaran. Dalam beberapa skenario, suatu atribut mungkin tidak ada, misalnya:

• Anda memiliki alur checkout berbeda dalam situs, dan sebagian darinya tidak mengumpulkan alamat email pelanggan.

• Anda baru saja mulai menggunakan Stripe.js, sehingga :ip_country: tersedia pada pembayaran baru, tetapi tidak tersedia pada pembayaran sebelumnya (yang kita cari saat mempratinjau aturan)

• Bagi sebagian pembayaran Anda, suatu bug dalam integrasi Anda gagal mengatur kunci metadata yang diharapkan

Bagaimana kondisi aturan mengevaluasi ketiadaan atribut

Perhatikan aturan Block if :email_domain: = 'definitelyfraud.com'. Jika Anda tidak mengumpulkan alamat email pelanggan, atribut :email_domain: tidak ada, sehingga syarat aturan tidak akan cocok dengan pembayaran.

Sekarang, pertimbangkan aturan Tinjau jika :email_domain: != 'definitelysafe.com'. Jika atribut :email_domain: tidak ada, aturan ini juga tidak sesuai dengan pembayaran. Ini mungkin tampak sesuai, karena ketiadaan nilai tidak sama dengan 'definitelysafe.com'. Namun, kami menafsirkan != 'definitelysafe.com' sebagai “atribut yang memiliki sejumlah nilai selain 'definitelysafe.com'"," yang tidak dipenuhi oleh atribut yang tidak ada. Informasi atribut yang tidak ada juga dibawa maju ketika menggunakan operator NOT, jadi demikian pula aturan Tinjau jika NOT (:email_domain: = 'definitelysafe.com') tidak sesuai dengan pembayaran jika atribut :email_domain: tidak ada.

Lebih umum lagi: setiap perbandingan (misalnya, =, !=, >, <) dari ketiadaan fitur dengan nilai statis atau fitur lainnya (tidak ada atau ada) selalu mengembalikan false. Penggunaan operator NOT dengan perbandingan yang berisi ketiadaan fitur selalu menghasilkan false.

Penanganan eksplisit dengan fungsi is_missing

Jika Anda ingin secara tegas memeriksa keberadaan suatu atribut atau atribut metadata, gunakan fungsi is_missing. Berikan fungsi ini dengan atribut atau kunci metadata yang mungkin tidak ada.

Misalnya, Anda dapat menulis aturan agar cocok dengan semua pembayaran yang tidak Anda miliki aksesnya ke alamat email pelanggan:

• Review jika is_missing(:email_domain:)

Atau Anda mungkin menulis aturan untuk mencocokkan semua pembayaran yang memiliki atribut metadata tertentu sebagai telah diatur:

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

Anda juga dapat menggunakan fungsi is_missing dalam konjungsi OR atau AND:

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

Kondisi yang rumit

Anda dapat membangun kondisi yang rumit dengan menggabungkan kondisi dasar menggunakan operator AND, OR, dan NOT. Anda dapat juga menggunakan persamaan simbolis: masing-masing &&, ||, dan !.

Serupa dengan bahasa pemrograman seperti C, Python, dan SQL, Stripe mendukung preseden (urutan pengoperasian) operator standar. Misalnya, kondisi yang rumit:

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

ditafsirkan sebagai:

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

Pengelompokkan sub-bersyarat di dalam kondisi kompleks juga didukung menggunakan tanda kurung. Misalnya, Anda dapat mengubah contoh sebelumnya untuk mengubah secara eksplisit urutan evaluasi dari sub-predikat:

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

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

Menggunakan tanda kurung di berbagai lokasi, masing-masing kondisi kompleks ini mengakibatkan hasil berbeda.

Kondisi valid

Kondisi berikut adalah contoh penggunaan atribut yang benar dan operator yang didukung:

• :card_brand: = 'amex'
• :card_country: != 'US'
• :amount_in_usd: >= 1000.00
• :is_anonymous_ip:

Kondisi tidak valid

Saat membuat aturan, Radar memberikan masukan jika Anda berusaha menggunakan kondisi yang tidak valid. Sebagai referensi, berikut adalah contoh kondisi yang tidak valid, di mana nilai untuk suatu atribut atau operator yang digunakan tidak didukung:

• :risk_level: < 'tertinggi' (nilai string hanya dapat menggunakan operator = atau !=)
• :ip_country: = 'Kanada' (nilai negara harus dinyatakan dalam kode pendek dua huruf)
• :amount_in_usd: >= 'seribu dolar' (nilai numerik harus dinyatakan dalam angka)
• :is_anonymous_ip: = 'true' (atribut Boolean tidak digunakan bersama operator atau nilai)

Aturan kecepatan

Banyak atribut yang didukung yang menyertakan invarian untuk skala waktu yang berbeda (misalnya, daily dalam total_charges_per_email_daily). Ini disebut aturan kecepatan.

Stripe menghitung atribut menggunakan penambahan wadah. Panjang tambahan bervariasi berdasarkan interval atribut. Ini berarti kecepatan untuk setiap atribut mungkin mencakup data yang terjadi dalam interval ditambah satu wadah. Sebagai contoh, interval atribut per jam mungkin 3900 detik (satu jam dan lima menit) dari transaksi saat ini karena interval menggunakan wadah lima menit.

Atribut didefinisikan sebagai:

• setiap jam adalah hingga 3900 detik (wadah 5 menit)
• harian adalah hingga 90000 detik (wadah 1 jam)
• mingguan adalah hingga 608400 detik (wadah 1 jam)
• tahunan adalah hingga 31622400 detik (wadah 1 hari)
• all_time termasuk data 5 tahun dengan kecepatan hingga 31622400 detik (wadah 1 hari)

Kasus penggunaan yang umum untuk atribut-atribut ini adalah untuk mengurangi percobaan kartu atau skenario serangan enumerasi, seperti yang dijelaskan dalam panduan Radar 101.