Mulai

Mode tes

Bangun dan uji integrasi Anda tanpa memindahkan uang sungguhan.

API key tes membuat permintaan pembayaran yang tampak dan berperilaku seperti yang sungguhan — field sama, biaya sama, webhook sama — tetapi tidak ada uang sungguhan yang pernah berpindah.

Key tes

Di samping key live, Anda bisa memegang satu key tes, berawalan kp_test_. Rotasi dan cabut di Pengaturan → Developer, persis seperti key live — satu key aktif per mode. Dashboard menampilkan satu environment saja: pindahkan ke Sandbox untuk melihat key tes, Live untuk yang live. Dipakai di header yang sama:

Authorization: Bearer kp_test_...

Mode key menentukan mode segala yang dibuatnya. Tidak ada field yang perlu diisi dan tidak ada yang perlu dikonfigurasi — create dengan kp_test_ menghasilkan objek tes; create dengan kp_live_ menghasilkan objek live. Setiap key hanya melihat modenya sendiri: key tes tidak akan pernah bisa mengambil atau mendaftar permintaan pembayaran live, dan sebaliknya.

Objek tes

Setiap respons /v1 dan setiap webhook membawa livemode — false untuk objek tes, true untuk yang live. Halaman checkout pembayaran tes menampilkan badge tes yang jelas, dan yang diberikannya ke pembeli sengaja dibuat stub yang tidak bisa dipakai: QR yang ditolak semua e-wallet, dan nomor Virtual Account yang tidak bisa dituju transfer. Dan memang begitu seharusnya — tidak ada bagian dari pembayaran tes yang boleh bisa dibayar.

curl https://pay.kasera.id/v1/transactions \
  -H "Authorization: Bearer kp_test_..." \
  -H "Idempotency-Key: test-order-1234" \
  -H "Content-Type: application/json" \
  -d '{ "amount": 150000, "description": "Kaos komunitas" }'

Mengarahkan hasil

Pembayaran tes tidak pernah terkonfirmasi sendiri — Anda yang mengarahkannya. Ambil token dari checkout_url di respons create (bagian setelah /p/) lalu kirim hasil yang Anda mau:

curl -X POST https://pay.kasera.id/api/v1/checkout/{token}/simulate-payment \
  -H "Content-Type: application/json" \
  -d '{ "outcome": "succeeded" }'

curl -X POST https://pay.kasera.id/api/v1/checkout/{token}/simulate-payment \
  -H "Content-Type: application/json" \
  -d '{ "outcome": "expired" }'

Body kosong berarti succeeded. Nilai lain ditolak 422 invalid_outcome. Endpoint ini diotorisasi oleh token checkout itu sendiri — tanpa API key. Memanggilnya pada pembayaran live dijawab 404, sama seperti token yang tidak ada.

Kartu di mode tes

Pembayaran kartu live mengarahkan pembeli ke halaman kartu (payment.redirect_url), tempat mereka mengisi kartu dan melewati 3-D Secure, lalu membawanya kembali. Di mode tes tidak ada yang sampai ke pemroses kartu, jadi redirect_url adalah halaman Kasera Pay Checkout untuk pembayaran itu, dan langkah kartunya berupa formulir kartu simulasi: nomor, masa berlaku, CVV, nama — divalidasi di browser dan tidak pernah dikirim ke mana pun. Hanya kartu uji di bawah yang diterima; tiap nomor memainkan satu hasil, jadi semua skenario bisa dilatih.

Hasil	Mastercard	VISA
Lunas (3DS)	`5573 3810 1111 1101`	`4617 0069 1111 1106`
Lunas (tanpa 3DS)	`5573 3810 1111 1135`	`4617 0069 1111 1130`
Ditolak pemroses (3DS)	`5573 3810 1111 1119`	`4617 0069 1111 1114`
Ditolak pemroses (tanpa 3DS)	`5573 3810 1111 1200`	`4617 0069 1111 1213`
Ditolak bank (3DS)	`5573 3810 1111 1127`	`4617 0069 1111 1122`
Ditolak bank (tanpa 3DS)	`5573 3810 1111 1226`	`4617 0069 1111 1221`

Masa berlaku 01/31 (bulan mana pun di masa depan bisa), CVV 123 (tiga digit apa pun), nama bebas. Kartu bertanda 3DS menampilkan langkah kode sekali pakai dulu; langkahnya mencetak kodenya (123456) dan hanya kode itu yang lolos. Kartu yang ditolak membiarkan pembayaran tetap pending dan pembeli boleh mencoba kartu lain — percobaan yang ditolak bukan pembayaran yang gagal, di mode tes maupun live.

Kartu uji yang lunas memicu webhook payment.paid yang sama seperti kartu sungguhan, pembeli diteruskan ke return_url Anda, dan refund tes lewat POST /v1/refunds berhasil tanpa menyentuh pemroses.

Webhook

Menyimulasikan succeeded memicu pengiriman payment.paid yang nyata dan bertanda tangan — ke endpoint tes, dengan signing secret tes. Endpoint live dan tes terpisah dan diatur di mode dashboard masing-masing, jadi siapkan dulu endpoint tes di mode Sandbox sebelum menunggu kiriman. Verifikasi signature-nya persis seperti event live.

Periksa livemode sebelum memproses pesanan. Event tes tidak bisa dibedakan dari yang live dengan cara lain — dan memang itu tujuannya.

Yang tidak pernah disentuh mode tes

Pembayaran tes dikecualikan dari semua jalur uang: payout, saldo Anda, laporan pendapatan, rekonsiliasi, dan batas harian Anda — create tes tidak memakai jatah harian dan tidak pula ditolak olehnya. Pembayaran tes juga tidak pernah mengirim email atau push ke pembeli maupun merchant; hanya webhook developer yang terkirim.

Naik ke live

Ganti kp_test_ dengan kp_live_. Tidak ada yang lain yang berubah. Kedua mode tidak berbagi ruang pembayaran — termasuk idempotency key — jadi key yang dipakai integrasi Anda di mode tes terhitung baru di mode live: permintaan live pertama Anda membuat pembayaran live, bukan replay dari yang tes.