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

The rule structure has two components—the action to take and the condition to evaluate:

{action} if {condition}

Together they represent the predicate. In practice, a rule to block all payments over 1,000 USD appears as:

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 kemungkinan hasil 3D Secure. Apakah ada kecocokan atau tidak pada aturan ini, kami mengevaluasi aturan untuk mengizinkan, memblokir, dan meninjau 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

Block rules advise Stripe to always block a payment. If a payment matches the criteria in a block rule, Stripe rejects it and it’s not subject to further rules evaluation.

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]

You can also use attributes as a corresponding value within a condition. For example, you can create a rule to block payments where the issuing country of the card doesn’t match the country where the payment took place:

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

These use ISO codes to represent the state or principal subdivision of a country, such as CA to represent California of the United States, ENG to represent England which is part of Great Britain, or L to represent La Pampa which is part of Argentina. We omit the two-letter country code from the state ISO code, so if you want to block transactions from California, compare the state attribute to 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

A post-authorization attribute (for example, :cvc_check:, :address_zip_check:, or :address_line1_check:) requires Stripe to exchange data with card issuers as part of the authorization process. The card issuer verifies this data against the information they have on file for the cardholder and checks for a match. Rules that use post-authorization attributes execute after rules that don’t use post-authorization attributes. (This won’t affect whether a charge is blocked or not, but might impact which rule blocks the charge.)

If you use a post-authorization attribute in a rule, your customer’s statement might temporarily show an authorization even if the charge is ultimately blocked—the authorization generally disappears after a few days.

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')

Mengharuskan pass yang ketat pada aturan dapat bersifat sangat 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

When using amount_in_xyz, Stripe automatically determines the converted amount of any payment when checking if the amount matches your chosen criteria. For example, if you create a rule using amount_in_usd to block all payments greater than 1,000 USD, Stripe blocks a payment of a lower nominal amount in a different currency (for example, 900 GBP) if its equivalent converted value exceeds 1,000 USD.

“Mempertimbangkan pembayaran mulai tahun 2020 dan seterusnya” dalam praktik

The descriptions of some rule attributes include the phrase “takes into account payments from 2020 onwards”. This means that the rule treats a card that last transacted with your business in 2019 the same as a card that’s new to your business. Consider what this means in the context of your business and rules as it could result in counterintuitive behavior. For example, if you create a rule to block high-value payments from new cards, you might end up blocking a good customer who hasn’t made a purchase since 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

Consider the rule Block if :email_domain: = 'definitelyfraud.com'. If you didn’t collect the customer’s email address, the :email_domain: attribute doesn’t exist, so the rule condition doesn’t match the payment.

Now consider the rule Review if :email_domain: != 'definitelysafe.com'. If the :email_domain: attribute is missing, this rule also doesn’t match the payment. It might seem like a match because no value isn’t 'definitelysafe.com'. However, we interpret != 'definitelysafe.com' to mean “the attribute has some value other than 'definitelysafe.com',” which a missing attribute doesn’t satisfy. Missing attribute information is also carried forward when using the NOT operator, so the rule Review if NOT (:email_domain: = 'definitelysafe.com') similarly doesn’t match the payment if the :email_domain: attribute is missing.

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

If you want to explicitly check for the existence of an attribute or metadata attribute, use the is_missing function. Provide this function with the attribute or metadata key that might be missing.

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 calculates attributes using bucket increments. The increment length varies based on the attribute interval. This means the velocity for any attribute might include data that occurred within the interval plus one bucket. For example, an hourly attribute interval might be 3900 seconds (one hour and five minutes) of the current transaction because the interval uses five minute buckets.

Atribut didefinisikan sebagai:

• hourly is up to 3900 seconds (5 minute buckets)
• daily is up to 90000 seconds (1 hour buckets)
• weekly is up to 608400 seconds (1 hour buckets)
• yearly is up to 31622400 seconds (1 day buckets)
• all_time includes 5 years of data with velocity up to 31622400 seconds (1 day buckets)

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