Terima pembayaran

Direct API

Ambil payload pembayaran mentah dan tampilkan di antarmuka Anda sendiri.

Endpoint yang sama dengan Checkout, POST /v1/transactions. Bedanya field mana yang Anda pakai: alih-alih mengarahkan pembeli ke checkout_url, Anda membaca payload pembayarannya dan menggambar layarnya sendiri. Desain, teks, dan penanganan error jadi milik Anda.

Satu endpoint, bukan satu per metode

Kalau Anda pernah mengintegrasikan payment gateway lain, Anda mungkin mengharapkan endpoint terpisah per metode — satu path untuk membuat virtual account, satu untuk membuat QR, satu lagi untuk menagih kartu. Begitulah rel bank di bawahnya distandarkan, dan itu sebabnya menambah metode pada integrasi semacam itu selalu berarti menulis kode baru.

Di sini semua metode memakai POST /v1/transactions. Metodenya adalah nilai yang Anda kirim, bukan path yang Anda panggil, dan perbedaannya datang lewat objek payment pada respons. Kami yang mengerjakan urusan per-rel di balik satu endpoint itu, supaya menambah metode ke integrasi Anda paling banyak hanya satu cabang.

Pengecualiannya adalah operasi yang berbeda, bukan metode yang berbeda: GET /v1/payment_methods untuk apa yang bisa diterima akun Anda, dan POST /v1/refunds — yang hanya didukung sebagian metode, dan menjawab 422 dengan kode yang jelas pada sisanya.

Minta satu metode

Kirim payment_methods berisi satu kode — ["va_bca"] — dan responsnya langsung membawa objek payment metode itu, tanpa ada yang perlu dipilih pembeli. Kirim beberapa kode dan berarti Anda sendiri yang membangun pemilihnya, dari GET /v1/payment_methods.

Tiga bentuk, berapa pun metodenya

Berapa pun metode yang kami dukung, sebuah pembayaran hanya pernah tampil dalam tiga bentuk. Tangani tiga bentuk itu dan daftar metodenya bisa bertambah tanpa menyentuh kode Anda.

payment.typeAnda dapatAnda tampilkanMetode
qrqr_stringGambar QRQRIS
payment_codepayment_code, bankNomornya + cara membayarVirtual Account, minimarket
redirectredirect_urlArahkan pembeli ke sanaKartu, e-wallet, paylater
// A Direct API integration is one switch, and it stays one
// switch as methods are added.
switch (trx.payment.type) {
  case "qr":           return <Qr value={trx.payment.qr_string} />;
  case "payment_code": return <Code value={trx.payment.payment_code} />;
  case "redirect":     return redirect(trx.payment.redirect_url);
}

Data pembeli Anda yang kumpulkan

Tidak ada halaman kami yang bisa menanyakan apa pun ke pembeli, jadi apa pun yang dibutuhkan sebuah metode tentang mereka harus ikut di customer saat create. Create yang menyebut metode dengan field wajib yang kosong ditolak 422beserta nama fieldnya — lihat metode pembayaran untuk metode mana butuh apa. Kalau Anda lebih suka tidak membangun formulir itu, Checkout yang mengumpulkannya untuk Anda.

Yang menjadi tanggung jawab Anda

  • Kedaluwarsa. Sembunyikan pembayarannya pada expires_at dan buat permintaan baru kalau pembeli masih mau membayar. Kode atau QR yang dipakai setelah itu gagal di bank, bukan di kami.
  • Instruksi. Setiap respons membawa blok instructions yang ditulis untuk pembeli dalam bahasa Indonesia. Tampilkan apa adanya daripada menulis sendiri — itu bedanya pembeli yang membayar dan pembeli yang menelepon Anda.
  • Metode baru. Metode yang bentuknya belum Anda implementasikan tidak akan tampil. Setiap bentuk baru itu satu cabang; metode baru dalam bentuk yang sudah ada tidak menambah apa pun.

Data kartu tidak pernah sampai ke server Anda, di integrasi mana pun. Kartu berbentuk redirect: Anda mengarahkan pembeli ke payment.redirect_url, halaman pemroses yang menerima kartu dan 3-D Secure, lalu pembeli kembali ke return_url Anda — sehingga Anda tetap di luar cakupan PCI DSS. Lihat kartu.

Mengonfirmasi pembayaran

Sama persis dengan Checkout: dengarkan webhook payment.paid, atau poll GET /v1/transactions/:id. Tidak ada yang di layar pembeli menjadi bukti pembayaran — hanya catatan kami.