Payment Gateway

Secara sederhana, Payment Gateway (PG) adalah penerjemah universal dan perantara keamanan di dunia pembayaran.

Masalah: Merchant (contoh: Tokopedia) ingin menerima pembayaran dari semua bank dan e-wallet (BCA, Mandiri, GoPay, OVO, Visa, dll). Bank dan e-wallet ini punya sistem, API, dan bahasa teknis yang berbeda-beda.
Solusi (PG): Merchant cukup melakukan satu kali integrasi API ke Payment Gateway. Selanjutnya, Payment Gateway-lah yang pusing mengurus puluhan integrasi API ke semua bank dan e-wallet tersebut.

1. Kerja Sama dengan Bank (Sisi Teknis & Bisnis)

Kerja sama antara PG dan Bank adalah hubungan B2B (Business-to-Business) yang sangat teknis. PG pada dasarnya adalah nasabah korporat super bagi bank.

Sisi Bisnis (Legal):
- PG mendaftar ke bank sebagai Merchant Aggregator.
- PG akan mendapatkan satu Merchant ID (MID) master dari bank. Semua ribuan merchant di bawah PG (misal: warung kopi A, toko online B) akan "numpang" di bawah MID master ini.
- PG menegosiasikan biaya transaksi (MDR - Merchant Discount Rate) secara "grosir" dengan bank. Karena volume transaksinya miliaran per hari, PG dapat harga sangat murah dari bank. PG kemudian menjual layanan ini "eceran" ke merchant-merchant kecil dengan harga yang sedikit lebih tinggi (itulah model bisnisnya).
Sisi Teknis (API):
- Kerja sama ini berjalan di atas API (Application Programming Interface).
- Bank menyediakan serangkaian private API (sering disebut Host-to-Host atau H2H) yang hanya bisa diakses oleh PG.
- API ini berfungsi untuk:
  1. Membuat Tagihan: Misal, request "Tolong buatkan Virtual Account (VA) BCA untuk order 123 senilai Rp 100.000".
  2. Menerima Notifikasi: Bank akan mengirim webhook (HTTP callback) ke endpoint API milik PG saat ada pembayaran masuk. "VA 123 tadi sudah dibayar lunas."
  3. Melakukan Pencairan (Disbursement): PG memanggil API bank untuk memerintahkan transfer uang dari rekening master PG ke rekening merchant (ini disebut settlement).
  4. Mengecek Mutasi (Reconciliation): API untuk menarik laporan rekening koran (e-statement) secara otomatis untuk proses rekonsiliasi.

2. ⚙Alur Kerja Payment Gateway

Ada dua alur utama yang harus Anda pahami sebagai engineer: Authorization (Transaksi) dan Settlement (Pencairan Dana).

Alur 1: Authorization (Proses Pembayaran, < 5 Detik)

Ini adalah proses saat pelanggan mengklik "Bayar" sampai muncul notifikasi "Berhasil". Mari kita ambil contoh pembayaran Virtual Account (VA), yang paling umum di Indonesia.

Pelanggan (User): Klik "Bayar" di website/aplikasi Merchant (misal: Tokopedia) dan memilih metode bayar "BCA Virtual Account".
Merchant: Backend server Merchant mengirim API request ke Payment Gateway (PG). Isinya: (order_id: 'XYZ', amount: 50000, payment_method: 'BCA_VA').
Payment Gateway (PG):
- Sistem PG menerima request ini.
- PG kemudian memanggil API internal Bank (misal: BCA) untuk membuat VA. Isinya: (customer_name: 'Budi', amount: 50000, unique_id: 'PG-XYZ').
- Bank BCA memvalidasi request dari PG, lalu membuatkan nomor VA unik (misal: 88088-12345678) di sistemnya.
- Bank BCA membalas ke PG: "Sukses, nomor VA adalah 88088-12345678".
Merchant:
- PG meneruskan nomor VA tadi ke server Merchant.
- Merchant menampilkan nomor VA 88088-12345678 dan jumlah Rp 50.000 ke layar pelanggan.
- (--- Pelanggan pergi ke m-banking/ATM untuk bayar ---)
Bank:
- Pelanggan berhasil bayar. Sistem core banking BCA mencatat "VA 88088-12345678 lunas".
- Sistem Bank seketika mengirim Webhook (notifikasi HTTP POST) ke sistem Payment Gateway. Isinya: (va_number: '88088-12345678', amount_paid: 50000, status: 'PAID').
Payment Gateway (PG):
- Sistem PG menerima webhook dari Bank.
- PG memvalidasi notifikasi ini, lalu mengubah status database untuk order_id: 'XYZ' menjadi 'PAID'.
- Sistem PG seketika mengirim Webhook ke sistem Merchant. Isinya: (order_id: 'XYZ', status: 'PAID', amount: 50000).
Merchant:
- Backend Merchant menerima webhook dari PG.
- Merchant memvalidasi notifikasi ini, mengubah status order_id: 'XYZ' di database-nya menjadi 'PAID'.
- Merchant mengirim email/notifikasi ke pelanggan ("Pesanan dibayar!") dan mulai memproses barang.

Poin Penting (Kartu Kredit): Alur kartu kredit sedikit berbeda karena melibatkan Payment Network (Visa/Mastercard) dan Bank Issuer (Bank penerbit kartu pelanggan) untuk mengecek saldo/limit sebelum transaksi disetujui. Prosesnya disebut Authorization & Capture.

Alur 2: Settlement (Proses Pencairan Dana, H+1)

Ini adalah alur "di balik layar" tentang perputaran uang. Uang yang dibayar pelanggan tidak langsung masuk ke rekening merchant.

H+0 (Hari Transaksi):
- Semua uang dari pelanggan (pembayaran VA, kartu kredit, dll) masuk dan terkumpul di satu rekening penampungan (rekening escrow) milik si Payment Gateway di bank.
- Merchant A dapat 100 transaksi (total Rp 10 Juta).
- Merchant B dapat 50 transaksi (total Rp 5 Juta).
- Uang di rekening PG bertambah Rp 15 Juta. Tapi uang ini masih "tercampur".
H+0 (Tengah Malam - Batch Process):
- Sistem PG menjalankan job Rekonsiliasi (Reconciliation).
- Ini adalah proses data engineering yang krusial: Sistem PG mencocokkan data di database-nya (SELECT * FROM transactions WHERE status='PAID') dengan data dari laporan rekening koran (e-statement) yang diunduh via API dari bank.
- Tujuannya: Memastikan tidak ada data yang hilang dan jumlah uangnya cocok. (Contoh: "Database PG bilang ada 150 transaksi, rekening koran bank juga bilang ada 150 kredit masuk. Cocok!").
H+1 (Hari Berikutnya - Payout/Disbursement):
- Setelah rekonsiliasi sukses, sistem PG menghitung hak setiap merchant.
- Contoh: "Hak Merchant A adalah Rp 10.000.000 dikurangi biaya PG (misal 1%) = Rp 9.900.000".
- Sistem PG kemudian secara otomatis memanggil API Transfer/Disbursement milik bank.
- Perintahnya: "Tolong transfer Rp 9.900.000 dari rekening master PG ke rekening Bank Merchant A".
- Proses ini diulang untuk ribuan merchant lainnya.

3. Konsep Kunci untuk Engineer di Payment Gateway

Idempotency: Sangat krusial. Jika Merchant mengirim API request (misal: "buat VA") dua kali karena jaringan error, sistem PG harus cukup pintar untuk tahu bahwa ini request yang sama (biasanya via X-Request-ID atau order_id) dan hanya memprosesnya satu kali. Ini mencegah tagihan ganda.
Webhooks & Retries: Apa yang terjadi jika PG mengirim webhook "PAID" tapi server Merchant sedang down? Sistem PG yang baik harus punya mekanisme antrean (queue) dan retry (coba lagi) dengan exponential backoff (coba lagi 1 menit, lalu 5 menit, lalu 15 menit).
Security (Keamanan):
- PCI-DSS: Jika PG memproses kartu kredit, ini adalah standar keamanan yang wajib ditaati. Anda tidak boleh menyimpan nomor kartu kredit lengkap sebagai plain text. Semuanya harus di-tokenize.
- Signature Key: Setiap request API (dari Merchant ke PG) dan webhook (dari PG ke Merchant) harus memiliki digital signature (misal pakai HMAC-SHA256) untuk membuktikan keasliannya dan mencegah request palsu.
Rekonsiliasi (Reconciliation): Ini adalah tantangan backend terbesar. Memproses, membandingkan, dan mencocokkan jutaan baris data dari database internal dengan file CSV/laporan mutasi dari bank secara cepat dan akurat.
High Availability (HA): Payment Gateway tidak boleh mati. Downtime 1 menit saja berarti kerugian miliaran rupiah bagi seluruh merchant. Ini berarti arsitektur sistem harus multi-region, load balanced, dan punya database replication yang andal.

Semoga ini memberi gambaran teknis yang jelas. Fokuslah pada konsep-konsep di atas, terutama Idempotency, Webhooks, dan Rekonsiliasi.

PreviousPayment Switching NextOAuth Grant Types

Last updated 9 days ago