Batas tingkat
Stripe API menggunakan sejumlah pengamanan terhadap semburan lalu lintas yang masuk guna membantu memaksimalkan stabilitasnya. Pengguna yang mengirim banyak permintaan secara berurutan dalam rentang waktu pendek mungkin melihat respons kesalahan yang ditampilkan sebagai kode status 429
. Kami memiliki beberapa pembatas di API, termasuk:
Pembatas tingkat yang membatasi jumlah permintaan yang diterima oleh API dalam setiap detik tertentu.
Untuk kebanyakan API, Stripe memungkinkan hingga 100 operasi baca per detik dan 100 operasi tulis per detik dalam mode live, serta 25 operasi per detik untuk masing-masing operasi dalam mode percobaan.
Untuk Files API, Stripe memungkinkan hingga 20 operasi baca per detik dan 20 operasi tulis per detik baik dalam mode live maupun mode percobaan. Batas mode live dan mode percobaan itu terpisah.
Untuk Search API, Stripe memungkinkan hingga 20 operasi baca per detik yang berlaku untuk semua endpoint pencarian baik dalam mode live maupun mode percobaan. Batas mode live dan mode percobaan itu terpisah.
Pembatas konkurensi yang membatasi jumlah permintaan yang aktif pada waktu tertentu. Masalah dengan pembatas ini kurang umum dibandingkan dengan pembatas tingkat permintaan, tetapi lebih mungkin menghasilkan permintaan berumur panjang yang intensif sumber daya.
Perlakukan batas ini sebagai maksimum dan jangan buat beban yang tidak perlu. Lihat Penanganan pembatasan dengan baik untuk mendapatkan saran tentang penanganan 429. Jika Anda tiba-tiba melihat lonjakan jumlah permintaan yang diberi tingkat terbatas, hubungilah dukungan.
Kami dapat mengurangi batas untuk mencegah penyalahgunaan, atau meningkatkan batas untuk memungkinkan aplikasi dengan lalu lintas tinggi. Untuk permintaan peningkatan batas kecepatan, silakan hubungi Tim CS. Jika Anda meminta kenaikan yang besar, hubungi kami 6 minggu sebelum advance ketika Anda membutuhkan kenaikan batas kecepatan.
Penyebab dan mitigasi umum
Pembatasan kecepatan dapat terjadi dalam berbagai kondisi, tetapi yang paling umum terjadi dalam skenario ini:
- Menjalankan permintaan berjarak dekat dalam volume besar dapat menyebabkan pembatasan tingkat. Hal ini sering kali merupakan bagian dari operasi analitis atau migrasi. Ketika terlibat dalam aktivitas ini, Anda harus mencoba mengontrol tingkat permintaan pada sisi client (lihat Penanganan pembatasan dengan baik).
- Penerbitan banyak permintaan berumur panjang dapat memicu pembatasan. Permintaan bervariasi dalam hal jumlah sumber daya server Stripe yang digunakan, dan permintaan yang lebih intensif sumber daya cenderung membutuhkan waktu lebih lama serta berisiko menyebabkan permintaan baru dibatasi oleh pembatas konkurensi. Persyaratan sumber daya sangat bervariasi, tetapi permintaan daftar dan permintaan yang menyertakan perluasan biasanya menggunakan lebih banyak sumber daya dan membutuhkan waktu lebih lama untuk dijalankan. Kami menyarankan pembuatan profil durasi permintaan Stripe API serta pemerhatian batas waktu untuk mencoba dan menemukan waktu yang lambat secara tak terduga.
- Peningkatan tiba-tiba dalam volume charge seperti penjualan kilat dapat mengakibatkan pembatasan tingkat. Kami mencoba mengatur tingkat kami cukup tinggi sehingga mayoritas pengguna tidak pernah diberi tingkat terbatas untuk lalu lintas pembayaran yang sah, tetapi jika Anda menduga kejadian yang akan datang dapat menyebabkan batas yang tercantum di atas terlampaui, hubungilah dukungan.
Penanganan pembatasan dengan baik
Teknik dasar integrasi agar dapat menangani pembatasan dengan baik adalah memperhatikan kode status 429
dan membuat mekanisme coba ulang. Mekanisme coba ulang harus mengikuti jadwal backoff eksponensial untuk mengurangi volume permintaan bila perlu. Kami juga merekomendasikan pembuatan beberapa hal acak ke jadwal backoff guna menghindari efek thundering herd.
Anda hanya dapat mengoptimalkan permintaan perorangan hingga tingkat tertentu, jadi pendekatan yang lebih canggih adalah mengontrol lalu lintas kunjungan ke Stripe di tingkat global, dan membatasinya kembali jika Anda mendeteksi pembatasan tingkat yang substansial. Teknik umum untuk mengontrol tingkat adalah mengimplementasikan sesuatu seperti algoritma pembatasan tingkat wadah token pada sisi client. Implementasi siap-pakai dan matang untuk wadah token tersedia di hampir semua bahasa pemrograman.
Batas waktu penguncian objek
Integrasi mungkin mengalami kesalahan dengan status HTTP 429
, kode lock_timeout
, dan pesan ini:
Objek ini sekarang tidak dapat diakses karena permintaan API yang lain atau proses Stripe tengah mengaksesnya. Jika Anda melihat kesalahan ini hanya sesekali, coba ulang permintaan. Jika Anda sering melihat kesalahan ini dan tengah membuat beberapa permintaan serentak ke satu objek, buat permintaan secara berseri atau dengan tingkat yang lebih rendah.
Stripe API mengunci objek pada beberapa operasi sehingga beban kerja serentak tidak mengganggu serta memberikan hasil yang tidak konsisten. Kesalahan di atas disebabkan oleh permintaan yang mencoba memperoleh penguncian yang sudah dilakukan di tempat lain, dan waktunya habis setelah tidak dapat diperoleh tepat pada waktunya.
Batas waktu penguncian memiliki penyebab yang berbeda dengan pembatasan tingkat, tetapi mitigasinya serupa. Seperti halnya kesalahan pembatasan tingkat, kami merekomendasikan coba ulang pada jadwal backoff eksponensial (lihat Penanganan pembatasan dengan baik). Namun, tak seperti kesalahan pembatasan tingkat, mekanisme coba ulang otomatis yang dibangun ke pustaka client Stripe mencoba ulang 429
yang disebabkan oleh batas waktu penguncian:
Ketidakcocokan penguncian disebabkan oleh akses serentak pada objek yang dikaitkan. Integrasi dapat sangat mengurangi hal ini dengan memastikan bahwa mutasi pada objek yang sama dimasukkan ke dalam antrean dan sebagai gantinya dijalankan secara berurutan. Operasi serentak terhadap API masih tidak masalah, tetapi coba pastikan operasi simultan hanya beroperasi pada objek yang unik. Juga memungkinkan untuk melihat ketidakcocokan penguncian yang disebabkan oleh pertentangan dengan proses latar belakang Stripe internal—hal ini seharusnya jarang terjadi, tetapi karena berada di luar kendali pengguna, kami merekomendasikan semua integrasi dapat mencoba ulang permintaan.
Percobaan beban
Adalah hal yang umum bagi pengguna untuk mempersiapkan acara penjualan besar dengan melakukan pengujian beban pada sistem mereka, dengan Stripe API yang berjalan dalam mode pengujian mode percobaan sebagai bagian darinya. Kami umumnya tidak menyarankan praktik ini karena batas API lebih rendah dalam mode percobaan, sehingga uji beban kemungkinan besar akan mencapai batas yang tidak akan dicapai dalam produksi. Mode percobaan juga bukan pengganti yang sempurna untuk live API, dan hal ini dapat menyesatkan. Sebagai contoh, membuat charge dalam mode live mengirimkan sebuah permintaan ke gateway pembayaran dan permintaan tersebut ditiru dalam mode percobaan, menghasilkan profil latensi yang berbeda secara signifikan.
Sebagai alternatif, kami merekomendasikan pembuatan integrasi agar memiliki sistem yang dapat dikonfigurasi untuk membuat rekaan permintaan ke Stripe API, yang dapat Anda aktifkan untuk percobaan beban. Untuk hasil yang realistis, integrasi harus menyimulasikan latensi dengan tidur selama waktu yang Anda tentukan dengan mengambil sampel durasi panggilan API Stripe mode live nyata, seperti yang terlihat dari perspektif integrasi.
Alokasi permintaan baca API
Stripe menyediakan akses ke permintaan API (GET) baca untuk memfasilitasi aktivitas pencarian sewajarnya yang terkait dengan integrasi pembayaran. Guna memaksimalkan kualitas layanan bagi semua pengguna, Stripe menyediakan alokasi berikut untuk permintaan baca berdasarkan jumlah transaksi:
- Permintaan API baca tidak boleh melebihi rasio rata-rata 500 permintaan per transaksi untuk sebuah akun. Misalnya, jika akun memproses 100 transaksi dalam periode 30 hari, maka tidak boleh melebihi 50.000 permintaan API baca selama periode yang sama.
- Saat menggunakan Connect, platform dan akun terhubungnya memiliki izin API baca yang berbeda:
- Setiap akun terhubung memiliki alokasi masing-masing untuk permintaan yang diprakarsai (500 permintaan per transaksi).
- Platform Connect menggunakan alokasi terpisah untuk membuat permintaan baca atas nama akun terhubung menggunakan kunci API rahasianya atau token akses OAuth. Alokasi ini juga berjumlah 500 permintaan per transaksi berdasarkan hitungan transaksi agregat di seluruh akun terhubung.
- Rasio diukur setiap 30 hari.
- Setiap akun, berapa pun hitungan transaksinya, memiliki alokasi minimum 10.000 permintaan baca per bulan.
- Permintaan API tulis tidak memiliki batas alokasi.
Panggilan ke endpoint API berikut ini tidak disertakan dalam batas alokasi di atas:
Untuk mengurangi volume permintaan API, pertimbangkan penggunaan Stripe Data Pipeline untuk mengekspor data API secara lengkap ke penyedia atau database lokal Anda.
Saring permintaan untuk membatasi panggilan yang di-paginasi
Beberapa endpoint daftar mengembalikan hasil beberapa halaman dan mungkin memerlukan beberapa permintaan untuk mengembalikan rangkaian lengkap objek API bagi operasi daftar. Terapkan filter bila memungkinkan guna mempersempit hasil daftar Anda.