Uji integrasi di sandbox
Sandbox adalah lingkungan TEST untuk membuktikan bahwa aplikasi Anda menangani pembayaran dan kegagalan dengan benar. Jangan berhenti setelah satu simulasi paid berhasil: integrasi juga harus aman saat respons hilang atau event datang berulang.
Siapkan pengujian yang terisolasi
- Gunakan project dan API key TEST.
- Gunakan pesanan serta data pelanggan sintetis.
- Pisahkan penyimpanan pesanan uji dari sistem pemenuhan pesanan nyata.
- Daftarkan webhook TEST sebelum membuat payment agar event baru punya tujuan pengiriman.
- Pastikan worker delivery dan receiver yang digunakan pada lingkungan uji berjalan.
Pembayaran produksi dinonaktifkan. Pengujian ini tidak membuktikan provider live, settlement uang nyata, atau kesiapan produksi.
Menjalankan simulator API
Buat payment baru seperti pada Quickstart, lalu pilih skenario:
curl --include --request POST \
"$VALCENTRA_API_URL/v1/test/payments/$PAYMENT_ID/simulate" \
--header "Authorization: Bearer $TEST_API_KEY" \
--header "Idempotency-Key: order-book-1002-simulate-failed" \
--header "Content-Type: application/json" \
--data '{"scenario":"failed"}'Gunakan payment baru yang belum memiliki attempt checkout untuk setiap skenario. Misalnya, gunakan order-book-1002 serta key create baru untuk kasus failed. Jangan mencoba memindahkan payment paid kembali ke pending.
Header wajib bukan jaminan deduplikasi
Simulator membutuhkan Idempotency-Key, tetapi tidak mendeduplikasi percobaan. Jangan otomatis mengulang request simulasi setelah
timeout. Periksa payment terlebih dahulu.
Skenario yang diterima
scenario | Tujuan pengujian |
|---|---|
paid | Hasil berhasil dan pemrosesan pesanan uji sekali. |
pending | Aplikasi tetap menunggu, tidak memenuhi pesanan. |
failed | Hasil gagal tidak dianggap lunas. |
expired | Payment kedaluwarsa tidak diteruskan sebagai pembayaran aktif. |
cancelled | Pembatalan tidak memicu pemenuhan. |
delayed_webhook | Notifikasi hasil dari simulator tertunda; aplikasi tidak menganggap pending sebagai gagal atau paid. |
repeated_webhook | Notifikasi simulator berulang tidak menyebabkan efek bisnis ganda. |
Untuk skenario tertunda, respons simulasi dapat masih menunjukkan pending. Ambil status setelah notifikasi diproses; jangan menganggap satu respons awal sebagai hasil akhir.
Skenario repeated_webhook menguji notifikasi simulator yang berulang. Sistem dapat mendeduplikasi sebelum membuat delivery merchant; skenario ini tidak menjamin receiver menerima POST yang sama dua kali. Uji deduplikasi receiver Anda juga secara terpisah.
Checklist sebelum integrasi dianggap siap di TEST
| Pengujian | Bukti yang perlu Anda lihat |
|---|---|
| Create berhasil | HTTP 201, ID tersimpan, checkout URL tersedia, livemode: false. |
| Retry create yang sama | Payment ID tetap sama ketika API key, body, dan idempotency key sama. |
| Key sama, body berbeda | HTTP 409 idempotency_conflict, tidak membuat payment baru. |
| Checkout | Jumlah benar, key tidak muncul di browser, return tidak otomatis melunasi pesanan. |
| Paid | Status API paid dan pesanan uji diperbarui tepat sekali. |
| Pending / failed / expired / cancelled | Tidak ada pemenuhan pesanan. |
| Signature salah | Receiver menolak tanpa mengubah pesanan. |
| Timestamp di luar 5 menit | Receiver menolak request replay. |
| Event diterima dua kali | Inbox tidak memiliki duplikasi dan efek bisnis hanya terjadi sekali. |
| Dua event bersamaan | Constraint unik/transaksi mencegah pemrosesan ganda. |
| Event lama datang belakangan | Status akhir tidak diturunkan menjadi pending. |
| Penyimpanan receiver gagal | Receiver tidak membalas 2xx sebelum event tersimpan aman. |
| Worker merchant gagal setelah penerimaan | Event persisten dapat diproses ulang tanpa pemenuhan ganda. |
| Receiver timeout / non-2xx | Delivery gagal dapat diperiksa dan dipulihkan setelah receiver diperbaiki. |
Untuk menguji POST berulang dan event tidak berurutan, buat fixture event sintetis di pengujian receiver Anda. Tandatangani raw bytes dengan secret uji khusus, timestamp saat ini, dan algoritma pada panduan HMAC. Jangan menyimpan request webhook nyata atau credential layanan untuk fixture.
Periksa dari dua sisi
Di Valcentra: lihat status payment, event/delivery yang tersedia, jumlah percobaan, dan hasil pengiriman.
Di aplikasi Anda: lihat inbox event, hasil worker, status pesanan, dan pengenal job pemenuhan. Delivery sukses tidak cukup jika aplikasi Anda kehilangan event setelah membalas 2xx.
Catat ID fixture, status yang diharapkan, dan hasil yang Anda lihat. Jangan memasukkan key, signature lengkap, atau payload provider ke laporan pengujian.
Lanjutkan ke: retry webhook untuk pemulihan, atau error API untuk masalah request.