Integrasi verifikasi SMS yang andal memisahkan pencarian katalog, penawaran terkait pengguna, pembuatan pesanan idempoten, pengambilan status, dan pembatalan terkonfirmasi. Simpan kunci penyedia di server dan terapkan pemeriksaan kepemilikan pada setiap permintaan. Anggap respons penyedia yang tidak pasti memerlukan rekonsiliasi, bukan otomatis membeli lagi atau mengembalikan dana tanpa konfirmasi.
Pisahkan antarmuka klien dari akses penyedia
Browser seharusnya meminta API aplikasi Anda; server Anda yang memanggil penyedia SMS. Simpan kredensial penyedia dalam rahasia runtime dan kembalikan hanya kolom pesanan yang diperlukan pengguna terautentikasi. Katalog publik berbeda dari akun atau kotak masuk privat. Periksa kepemilikan pada setiap operasi pesanan, termasuk polling status, pembatalan, dan penyelesaian. Autentikasi pada rute pembelian saja tidak cukup.
Jadikan penawaran berwenang dan berumur singkat
POST /api/v1/quotes yang diterapkan ReceiveSMSGo membuat penawaran terkait pengguna yang berlaku 60 detik. Server menghitung harga USD sebagai max($0.39, biaya penyedia terkonversi × 2). Klien mengirim pengenal penawaran, bukan harga yang dipercaya, ketika membuat pesanan. Jika penawaran berakhir, minta yang baru. Penawaran dapat hilang antara pencarian dan pembelian, sehingga kesalahan ketersediaan harus dinyatakan secara eksplisit.
Reservasi sekali dan tangani pembelian yang tidak pasti
POST /api/v1/orders membutuhkan Idempotency-Key dan quoteId. Menggunakan kembali kunci yang sama untuk operasi yang sama mengembalikan pesanan yang sudah ada. Reservasi dompet dan pembaruan ledger yang diterapkan bersifat atomik. Jika respons pembelian penyedia ambigu, pesanan masuk peninjauan daripada otomatis membeli lagi. Idempotensi melindungi batas aplikasi Anda; idempotensi tidak secara ajaib merekonsiliasi waktu habis penyedia.
- Buat satu kunci untuk satu pembelian yang dimaksud dan pertahankan saat percobaan ulang.
- Kirim pengenal penawaran terkini dengan konteks pengguna terautentikasi.
- Rekonsiliasi hasil ambigu sebelum memulai pembelian lain.
Polling pesanan milik pengguna tanpa membanjiri penyedia
GET /api/v1/orders/{id} mengembalikan pesanan pengguna dan dapat memperbarui status penyedia yang aktif. Implementasi membatasi pemeriksaan penyedia paling sering satu kali setiap lima detik per pesanan. Modelkan status menunggu, diterima, selesai, dibatalkan, kedaluwarsa, dan peninjauan secara terpisah. Jangan membuat waktu kedaluwarsa sendiri ketika dokumentasi penyedia tidak jelas tentang satuannya. Browser yang ditutup bukan bukti bahwa pesanan jarak jauh berakhir.
Konfirmasikan pembatalan sebelum mengubah saldo
POST /api/v1/orders/{id} menerima tindakan cancel atau finish. Pembatalan diblokir selama 120 detik setelah pembuatan; setelah itu server meminta pembatalan penyedia sebelum menerapkan satu pengembalian dana. Penyelesaian membutuhkan kode SMS yang telah diterima. Tindakan bersamaan menggunakan transisi status untuk mencegah pekerjaan tumpang tindih. Permintaan jaringan gagal tidak boleh dianggap sebagai pembatalan berhasil atau izin untuk memberikan kredit ganda.
Verifikasi callback dan bedakan kode dari kesiapan operasional
Callback yang masuk tidak otomatis menjadi sumber tepercaya. Verifikasi tanda tangan Stripe diikuti pencarian catatan pembayaran resmi sebelum saldo dikreditkan. Notifikasi status SMS tanpa tanda tangan hanya menjadi petunjuk untuk mengambil status pesanan dengan autentikasi. Peristiwa uji dan langsung Stripe harus cocok dengan rahasia endpoint, akun, dan lingkungan setorannya. Callback eksternal harus dapat dijangkau; pengalihan bukan bukti pembayaran. API ruang kerja memerlukan sesi situs yang terautentikasi, bukan kunci API pengembang publik. Tinjau operasi yang diaktifkan dan OpenAPI sebelum integrasi.
Pertanyaan berguna, jawaban jelas
Bisakah saya memasukkan kunci API penyedia dalam kode frontend?
Tidak. Simpan dalam rahasia runtime server. Frontend seharusnya memanggil API Anda sendiri dengan konteks pengguna terautentikasi.
Haruskah saya mencoba ulang pembelian yang waktunya habis dengan kunci baru?
Ambil dan rekonsiliasi pesanan awal terlebih dahulu. Kunci baru mewakili pembelian lain dan dapat membuat biaya lain.
Apakah API ReceiveSMSGo layanan publik dengan kunci pengembang?
Tidak. Operasi menggunakan sesi terautentikasi situs. Produk kunci API publik terpisah dan operasi produksi yang sepenuhnya terverifikasi belum tersedia.
Sumber dan bacaan lanjutan
Sumber menjelaskan layanan masing-masing dan dapat berubah. Periksa persyaratan terkini platform tujuan sebelum memilih nomor.
Pahami alur kerja sebelum memulai.
Jelajahi pemilihan layanan, pilihan negara, dan status SMS di ruang kerja. Penawaran serta ketersediaan bergantung pada penyedia; penerimaan nomor dan pengiriman tidak dijamin. Dompet dan pesanan Anda membutuhkan login.
Buka ruang kerja
