Integrasi Aplikasi Kasir Online dengan Layanan Perbankan

Hubungan aplikasi kasir online dengan layanan perbankan terutama terjadi pada penerimaan pembayaran, settlement, transfer, virtual account, rekonsiliasi, serta data yang dipertukarkan melalui penyedia resmi. Sistem Kasir tidak berubah menjadi sistem inti bank dan tidak boleh menyimpan atau memproses informasi melebihi ruang lingkup yang diperlukan. Desain yang baik memisahkan order, payment, settlement, dan ledger sehingga kegagalan salah satu komponen tidak merusak catatan lainnya.

Artikel ini ditujukan bagi merchant yang menilai integrasi kasir dengan bank atau penyedia pembayaran, bukan panduan untuk menyelenggarakan jasa sistem pembayaran. Fitur, kewajiban, dan pihak yang boleh menyediakan layanan harus diverifikasi melalui bank, penyedia berizin, serta ketentuan yang berlaku.

Jawaban singkat

Gunakan transaction ID internal dan provider reference yang unik. Catat metode, nominal, waktu, status, fee, refund, settlement batch, serta rekening tujuan tanpa menyimpan credential atau data sensitif yang tidak diperlukan.

Rekonsiliasi dilakukan berlapis: order ke payment, payment ke laporan provider, settlement ke rekening bank, dan hasilnya ke pembukuan. Setiap selisih masuk exception queue dengan owner serta tenggat.

Pahami pembagian peran

Merchant menjual barang atau jasa, kasir mencatat order, penyedia pembayaran memproses instruksi, bank mengelola rekening dan layanan sesuai perannya, sedangkan sistem akuntansi mencatat dampak keuangan. Kontrak perlu menjelaskan pihak, layanan, data, SLA, dispute, dan tanggung jawab.

Jangan menggunakan nomor rekening atau nama pelanggan sebagai identitas transaksi. Gunakan reference yang dirancang untuk uniqueness dan traceability.

Ikuti kerangka resmi

Blueprint Sistem Pembayaran Indonesia 2030 dari Bank Indonesia memuat arah penguatan infrastruktur, industri, inovasi, internasional, dan Rupiah Digital. Implementasi merchant perlu memakai layanan resmi serta mengikuti aturan teknis dan kontraktual dari pihak terkait.

Untuk integrasi API pembayaran, periksa ketentuan serta standar yang berlaku, ruang lingkup izin penyedia, dan perubahan versi. Jangan menganggap akses teknis sebagai kewenangan melakukan seluruh aktivitas pembayaran.

Pisahkan order dan pembayaran

Order menjelaskan apa yang dibeli, sedangkan payment attempt menjelaskan usaha membayar. Satu order dapat memiliki payment gagal, pending, berhasil, atau diganti metode.

Status order tidak boleh otomatis paid hanya karena request dikirim. Perubahan memerlukan response atau notification yang diverifikasi sesuai desain penyedia.

Gunakan idempotency

Retry karena timeout harus mengembalikan hasil transaksi yang sama, bukan membuat debit baru. Gunakan idempotency key, unique constraint, dan state machine.

Jika hasil belum diketahui, tandai unknown atau pending dan lakukan inquiry. Jangan mengubahnya menjadi gagal hanya agar pelanggan dapat mengulang.

Verifikasi notifikasi

Webhook atau callback perlu diautentikasi, divalidasi, dicatat, dan diproses idempotent. Periksa signature, timestamp, source, payload schema, reference, currency, serta nominal sesuai dokumentasi penyedia.

Balasan HTTP bukan akhir kontrol. Simpan event mentah secara aman, hasil proses, retry, dan dead-letter queue untuk investigasi.

Kelola virtual account

Jika digunakan, simpan virtual account ID, customer atau invoice mapping, nominal, expiry, status, dan provider reference. Static serta dynamic virtual account memiliki risiko rekonsiliasi berbeda.

Pembayaran setelah expiry, nominal berbeda, atau reference tidak dikenal masuk pengecualian. Jangan menebak invoice tujuan hanya dari nama pengirim.

Rekonsiliasi settlement

Payment berhasil belum sama dengan dana tersedia. Settlement dapat menggabungkan transaksi, mengurangi fee, memasukkan refund, atau diproses pada jadwal tertentu.

Langkah rekonsiliasi harian adalah:

1. Ambil order yang seharusnya dibayar pada periode.

2. Cocokkan payment reference serta status provider.

3. Kelompokkan transaksi menurut settlement batch.

4. Rekonsiliasi nilai bruto, fee, refund, dan neto.

5. Cocokkan batch dengan mutasi rekening bank.

6. Masukkan perbedaan ke exception queue.

7. Tutup hanya setelah penyebab serta bukti tersedia.

8. Posting hasil ke accounting tanpa menggandakan jurnal.

Terapkan cut-off serta timezone yang konsisten. Selisih satu hari dapat berasal dari jadwal, bukan kehilangan dana.

Kelola multi-rekening

Bisnis dapat memakai rekening collection, operasional, pajak, atau cabang sesuai kebijakan. Mapping rekening harus disetujui dan perubahan memerlukan kontrol kuat.

Perubahan beneficiary termasuk tindakan berisiko tinggi: gunakan maker-checker, MFA, cooling period bila tersedia, notifikasi, dan audit log. Jangan memproses instruksi perubahan hanya dari email tanpa verifikasi.

Tangani refund

Refund dihubungkan ke order dan payment asal. Simpan jumlah penuh atau parsial, item, alasan, approver, provider reference, status, fee, dan settlement.

Pisahkan request refund dari refund completed. Pelanggan menerima informasi waktu serta kanal sesuai kebijakan penyedia, tanpa janji yang tidak dapat dikendalikan merchant.

Kelola dispute dan chargeback

Simpan bukti transaksi, persetujuan, receipt, delivery, komunikasi, dan kebijakan. Batasi akses karena evidence dapat memuat data pribadi.

Catat deadline, owner, amount at risk, response, dan outcome. Analisis dispute menurut produk, channel, metode, dan akar penyebab.

Lindungi credential

API key, client secret, certificate, dan token tidak ditanam di aplikasi client atau dibagikan melalui chat. Simpan pada secret management yang sesuai, rotasi, dan batasi scope.

Pisahkan environment test serta production. Log tidak boleh memuat credential atau data sensitif penuh.

Terapkan kontrol akses

Gunakan akun individual, role minimum, MFA, approval, session timeout, dan audit log. Pisahkan petugas yang membuat refund, mengubah rekening, serta menyetujui bila risiko material.

Review akses berkala dan segera saat staf keluar. Akun service memiliki owner, tujuan, scope, dan masa berlaku.

Minimalkan data

Kumpulkan hanya data yang diperlukan untuk transaksi, rekonsiliasi, dukungan, atau kewajiban. Gunakan token dari penyedia alih-alih menyimpan data instrumen pembayaran jika arsitektur mendukung.

Tetapkan retensi, masking, encryption, serta proses akses dan penghapusan sesuai kewajiban. Backup juga termasuk dalam cakupan perlindungan.

Siapkan kontinuitas

Peta dependency mencakup kasir, internet, DNS, provider, bank, webhook, database, dan accounting. Tentukan dampak serta RTO/RPO untuk fungsi kritis.

Runbook mencakup provider timeout, notification delay, bank statement terlambat, credential compromised, dan settlement mismatch. Uji tanpa menyentuh transaksi pelanggan nyata bila memungkinkan.

Kelola risiko pihak ketiga

Sebelum integrasi, nilai legal entity, ruang lingkup layanan, izin atau kerja sama yang relevan, keamanan, subkontraktor, lokasi pemrosesan, SLA, status page, histori insiden, dukungan, serta rencana penghentian. Bukti perlu ditinjau ulang ketika layanan atau regulasi berubah.

Kontrak menjelaskan data ownership, notification insiden, kewajiban rekonsiliasi, batas tanggung jawab, perubahan API, dan bantuan migrasi. Jangan bergantung pada janji sales yang tidak masuk dokumen layanan.

Siapkan jalur eskalasi operasional dan keuangan yang berbeda. Insiden teknis dapat selesai lebih cepat daripada penelusuran dana, sehingga owner serta bukti yang diperlukan tidak selalu sama.

Uji perubahan sebelum produksi

Gunakan sandbox atau lingkungan uji untuk schema, signature, timeout, retry, expiry, dan error code. Simulasikan versi API baru serta rotasi certificate.

Rilis memakai change record, peer review, test evidence, rollback, dan monitoring ketat. Perubahan kecil pada mapping currency atau amount dapat menimbulkan selisih besar walaupun endpoint tetap merespons sukses.

Monitor secara end-to-end

Pantau payment success, pending age, duplicate attempt, webhook delay, reconciliation rate, settlement age, refund age, dispute, dan API error. Alert memiliki threshold serta owner.

Jangan menampilkan semua error sebagai “bank bermasalah”. Identifikasi komponen serta evidence sebelum berkomunikasi kepada pelanggan.

Audit integrasi

Dokumentasikan data flow, endpoint, schema, version, authentication, certificate, retry, idempotency, logging, owner, dan vendor contact. Tinjau perubahan serta dependency.

Gunakan Kasair untuk konteks transaksi dan artikel Kasair untuk panduan operasional lain. Verifikasi integrasi aktual dengan bank atau penyedia resmi sebelum implementasi.

Jalankan pilot

Uji sukses, gagal, timeout, pending, duplicate callback, amount mismatch, refund parsial, settlement berbeda hari, credential rotation, dan recovery. Gunakan nominal serta environment sesuai ketentuan penyedia.

Rekonsiliasi dari order hingga rekening serta jurnal. Go-live hanya setelah exception dapat diselesaikan dan rollback tersedia.

FAQ

Apakah aplikasi kasir menjadi sistem bank?

Tidak. Kasir mencatat transaksi merchant dan berintegrasi dengan layanan dari pihak yang memiliki peran serta kewenangan sesuai aturan.

Apa beda payment dan settlement?

Payment mencatat proses pembayaran pelanggan; settlement adalah penyelesaian dana kepada merchant setelah komponen terkait.

Bagaimana mencegah debit ganda?

Gunakan idempotency key, reference unik, state machine, inquiry, dan larangan retry buta saat status belum diketahui.

Mengapa webhook perlu diverifikasi?

Karena notification memengaruhi status transaksi dan harus dipastikan berasal dari sumber sah serta belum diproses.

Apa kontrol perubahan rekening?

Gunakan maker-checker, MFA, verifikasi independen, notifikasi, pembatasan akses, dan audit log.

Apa yang harus diuji saat pilot?

Uji sukses, gagal, timeout, pending, duplikasi, refund, settlement, rekonsiliasi, credential, dan recovery.