Host to Host Bank: Berkas, API Bank, atau Open API SNAP

Kalau sebuah bank menawarkan host to host, jawab satu pertanyaan sebelum menyusun estimasi: berkas atau API. Ketiga halaman produknya kami baca pada 4 September 2026. Di BCA, Host to Host ERP Integration (HEI) adalah kanal berkas — BCA menyediakan "Aplikasi BCA Client ... dan Security Key Pretty Good Privacy (PGP), dan/atau Aplikasi SSH File Transfer Protocol (SFTP) BCA", dan nasabah "wajib membangun sistem HEI berdasarkan Dokumen Spesifikasi Teknis dari BCA". Di Bank Mandiri, Kopra Host to Host adalah "a payment solution that utilizes direct debiting based on API integration between the Bank's system and your Enterprise Resources Planning (ERP) system". Nama produknya sama. Arsitekturnya tidak saling menggantikan.

Maybank Indonesia memakai frasa yang persis sama untuk SFTP murni: instruksi dikirim "langsung (Host to Host) dari sistem ERP ... ke sistem Maybank Indonesia melalui metode Secure File Transfer Protocol (SFTP)", mencakup Within Maybank, SKN dan RTGS. Tiga bank, tiga teknologi, satu nama produk. Jadi scoping dimulai dari dokumen spesifikasi teknis yang bank serahkan, bukan dari frasa di brosurnya.

Bedanya bukan soal selera arsitektur

Ruang lingkup SNAP dikunci di Pasal 3 ayat (4) PADG No. 23/15/PADG/2021 (ditetapkan 16 Agustus 2021), dan kata kerjanya yang menentukan: standar teknis dan keamanan, standar data, serta spesifikasi teknis SNAP "diterapkan dalam API dengan kategori" registrasi, informasi saldo, informasi riwayat transaksi, transfer kredit, transfer debit, ditambah kategori lain yang ditetapkan Bank Indonesia. Kiriman berkas payroll lewat SFTP bukan API dan tidak masuk lima kategori itu. Ambil kanal berkas, Anda dapat antarmuka milik bank tanpa standar nasional di belakangnya — sah, dan sepenuhnya jadi tanggungan Anda.

Bank Mandiri menuliskan pembagian ini sendiri di halaman produknya. Syarat Kopra Host to Host mencakup kepatuhan pada "the technical specification and governance standards set by Bank Mandiri, and the National Open API Payment Standard (SNAP) adopted by Bank Indonesia for SNAP specification services". Dua rezim spesifikasi di satu produk, dan yang menentukan mana yang berlaku adalah layanannya, bukan kanalnya.

Yang keliru adalah menganggap kewajiban standar berhenti di bank. Pasal 127 ayat (3) PBI No. 10 Tahun 2025 — berlaku 31 Maret 2026 — memberlakukan kewajiban pemenuhan standar nasional itu "mutatis mutandis terhadap kewajiban ... bagi Penyelenggara Penunjang dan pihak lain yang melakukan kerja sama dengan PJP, PIP, dan/atau Peserta". Kalau Anda yang membangun integrasinya, Anda pihak lain itu. Pasal 184 huruf c menjaga PBI 23/11/PBI/2021 "termasuk peraturan pelaksanaannya" tetap berlaku, jadi PADG SNAP tidak ikut tercabut.

Jenis koneksi	Siapa yang menerbitkan spesifikasinya	Konformansi yang wajib	Yang patah lebih dulu
H2H berkas (SFTP/PGP) — BCA HEI, Maybank Bulk Payment	Bank, lewat Dokumen Spesifikasi Teknis internalnya; BCA juga mewajibkan nasabah "membangun infrastuktur jaringan" sendiri	Tidak ada standar nasional — batch berkas bukan API	Rekonsiliasi. Tanpa callback; status datang lewat laporan, di BCA termasuk MT940
H2H API milik bank — Kopra Host to Host	Bank, plus SNAP untuk layanan yang masuk kategori Pasal 3 ayat (4)	SNAP untuk layanan yang tercakup; kewajibannya mengalir ke Anda lewat Pasal 127 ayat (3) PBI 10/2025	Header dan tanda tangan. Gagalnya muncul sebagai 401 atau 409 yang tidak menjelaskan apa pun
Open API SNAP penuh	Standar disusun dan dikelola SRO atas penugasan Bank Indonesia (Pasal 129 PBI 10/2025); dokumennya terbit di Developer Site ASPI	Standar Teknis dan Keamanan serta Standar Data dan Spesifikasi Teknis, v1.0.2, September 2024	Format identitas transaksi dan notifikasi. Lihat dua pengukuran di bawah

Soal berkas pemeriksaan — berita acara pengujian, surat rekomendasi SRO, rencana tindak — sudah kami uraikan terpisah di SNAP BI dan PADG 23/15/2021: sembilan berkas pemeriksa. Tulisan ini soal apa yang terjadi saat sistemnya sudah jalan.

Satu header wajib, lima spesifikasi yang tidak sama

Pada 4 September 2026 kami membaca dokumentasi SNAP milik pengelola standar dan empat penyelenggara Indonesia, lalu membandingkan bagaimana masing-masing mendefinisikan satu header wajib: X-EXTERNAL-ID. Tidak ada dua yang sama, dan bedanya ada di panjang field.

Penerbit dokumentasi	Tipe dan panjang	Deskripsi
ASPI — referensi Keamanan SNAP	Mandatory, String (36)	"Numeric String. Reference number that should be unique in the same day" — kalimat yang sama di tabel Transaction Request (B2B) maupun (B2B2C)
DOKU — SNAP QRIS	Required, panjang tidak dinyatakan	"Numeric String. Reference number that should be unique in the same day (Request Id)"
Espay — Direct API SNAP QRIS	String (32), wajib	"String Numerik. Kode referensi yang bersifat unik pada hari yang sama."
BRI — SNAP BI Bank Statement	Numeric, mandatory, panjang 9	—
Midtrans — Core API SNAP	UUID dianjurkan, TTL 24 jam	"we highly recommend merchant to use UUID format to avoid duplication"

Baca kolom panjangnya saja: 36, 32, dan 9. UUID panjangnya 36 karakter, jadi ia muat di deklarasi ASPI sekaligus melanggar deskripsi ASPI sendiri yang menyebut field itu numerik; ia tidak muat di 32 milik Espay maupun 9 milik BRI. Contoh yang dicetak ASPI di halamannya sendiri malah 32 digit — 41807553358950093184162180797837 — di bawah tipe yang tertulis String (36).

Pendapat kami, dan ini yang paling mahal dari seluruh isi standar: satu skema identitas yang dibuat sekali di konektor ERP lalu dikirim ke tiga lawan transaksi akan ditolak setidaknya satu di antaranya — sebagai 409 "Cannot use same X-EXTERNAL-ID in same day", yang tidak menyinggung soal format sama sekali. Sepakati skemanya tertulis per lawan transaksi, bukan sekali untuk seluruh program. Soal waktunya pun berbeda: Midtrans memakai TTL 24 jam yang bergulir, ASPI memakai hari kalender, jadi retry yang melewati tengah malam adalah transaksi baru menurut satu pembacaan dan duplikat menurut yang lain.

Apa yang benar-benar disediakan, dan apa yang cuma dikonsumsi

Artikel Selasa kami menghitung 15 entitas di Direktori Publikasi Developer Site SNAP pada 2 September 2026, dan mencatat bahwa pencantumannya sukarela sehingga angkanya lantai, bukan sensus. Kami membuka lagi seluruh 15 halaman detailnya pada 4 September; entitasnya sama persis. Yang belum pernah dihitung siapa pun ada di dalam halaman-halaman itu. Masing-masing memisahkan List of Services Provided dari List of Services Consumed, dan angkanya jauh berbeda tergantung kolom mana yang Anda baca.

Sub-API SNAP	Disediakan	Muncul di salah satu kolom
API Balance Inquiry	9 dari 15	11
API Trigger Interbank Transfer	7	9
API Transaction Status Inquiry	5	9
API Transfer RTGS	5	8
API Transfer SKNBI	5	7
API Bank Statement	5	7
API Virtual Account – Notification for Payment to VA from Intra Bank	2 — PT Bank Central Asia Tbk dan PT Bank Permata, Tbk	4

Dua. Notifikasi push yang biasanya jadi tulang punggung desain rekonsiliasi disediakan oleh dua entitas; dua lainnya mencantumkannya sebagai layanan yang mereka konsumsi — PT Bank Rakyat Indonesia Tbk dan PT Harsya Remitindo. Sebuah bank yang muncul sebagai konsumen memberi tahu Anda di mana ia duduk dalam alur milik pihak lain, dan itu informasi arsitektur, bukan trivia.

Perhatikan bentuk sebarannya, bukan satu barisnya. Yang paling banyak disediakan adalah inquiry saldo; yang paling jarang adalah satu-satunya layanan yang mendorong data ke arah Anda tanpa diminta. Dibaca begini, direktori itu bukan daftar kepatuhan — ia daftar kapabilitas pemasok, dan pemasoknya hampir semua menjual bacaan.

Cara menghitungnya perlu dinyatakan, karena halamannya tidak rapi. Kami menghitung per entitas, bukan per baris: beberapa entitas mencantumkan layanan yang sama di kedua kolom, dan ada baris yang benar-benar kembar — PT GDC Multi Sarana mencetak "API Transaction Status Inquiry" dua kali, 60 baris konsumsi milik PT Harsya Remitindo hanya berisi 58 nama berbeda, dan halaman PT Bank Mandiri Persero Tbk mencetak 22 baris untuk 21 layanan. Dua entitas tidak menyediakan apa pun.

Tiga tempat implementasi SNAP patah saat berjalan

1. Kunci idempotensi yang bukan kunci idempotensi

Tabel response code ASPI memuat dua kode 409 yang harus dibaca berpasangan: 409-any-00 Conflict, "Cannot use same X-EXTERNAL-ID in same day", dan 409-any-01 Duplicate partnerReferenceNo, "Transaction has previously been processed". Memutar ulang request dengan kunci yang sama menghasilkan penolakan, bukan jawaban yang sama — kebalikan dari perilaku kunci idempotensi di mana pun.

Yang membuatnya jebakan, bukan sekadar kejanggalan: Midtrans mendokumentasikan Idempotency-Key sendiri dengan semantik yang benar — "If transaction already succeed and merchant re-send the same idempotency-key on request, Midtrans will response the same successful response as the first request" — lalu di baris berikutnya menyamakan X-EXTERNAL-ID dengannya: "Has the same usage as idempotency-key in legacy API." Dua header, dua perilaku, satu deskripsi. Dan karena responseCode disusun sebagai "HTTP status code + service code + case code", error handler yang mencocokkan awalan "409" saja menyamakan tabrakan kunci dengan duplikasi transaksi.

2. Satu 404 yang artinya sukses dan gagal sekaligus

Kode 404-any-18 "Inconsistent Request" berbunyi: "It can be considered as failed in transfer debit, but it should be considered as success in transfer credit." ASPI lalu merincinya. Dianggap sukses: transfer intrabank, interbank, RTGS, SKNBI, pembayaran VA dan pembayaran ke VA, refund payment, void. Dianggap gagal: transfer ke OTC, direct debit payment, QR CPM payment, auth payment, capture. Satu status HTTP yang maknanya berbalik tergantung sub-API mana yang memunculkannya, dan error handler generik akan salah membacanya ke arah membayar dua kali atau membalikkan transaksi yang berhasil.

3. Rumus tanda tangan menyebut kunci yang keliru

Varian asimetris tanda tangan transaksi diterbitkan sebagai "SHA256withRSA (clientSecret, stringToSign)". SHA256withRSA menandatangani dengan private key, bukan client secret — dan rumus token akses di halaman yang sama menuliskannya benar: "SHA256withRSA (Private_Key, stringToSign)". Mana yang berlaku dipilih lewat nilai header, "1 - Symmetric Signature with Get Token; 2 - Asymmetric Signature without Get Token", Default Value: 1. Dua konstruksi stringToSign yang berbeda total di balik satu header, dan defaultnya jarang disetel sadar.

Satu catatan transport yang sudah lewat tanggalnya. Standar yang sama menetapkan TLS 1.3, memberi jalan mundur ke TLS 1.2 dengan empat cipher suite tertentu, lalu menutupnya: kemunduran itu "hanya dapat diterapkan oleh Penyedia Layanan dan Pengguna Layanan sampai dengan tanggal 30 Juni 2026". Sejak 1 Juli 2026 tidak ada jalur TLS 1.2 yang sesuai standar di sisi mana pun. Kami mengukur posisi TLS 15 host API pembayaran Indonesia pada 2 September 2026 dan menerbitkan hasilnya di artikel kepatuhan SNAP.

Rekonsiliasi adalah pekerjaan arsitektur, bukan pekerjaan operasional

Pasal 2 PADG No. 17 Tahun 2023 tentang penyelenggaraan BI-FAST (ditetapkan 28 November 2023, telah diubah tiga kali, terakhir oleh PADG 3/2026 yang berlaku 31 Maret 2026) menetapkan dua prinsip: setelmen dana dilakukan "secara seketika per transaksi", dan setelmen dana "bersifat final dan tidak dapat dibatalkan". Pasal 34 ayat (2) dan (3) menambahkan bahwa BI-FAST beroperasi Senin sampai Minggu, 24 jam. Tidak ada jendela batch, tidak ada cut-off untuk berlindung.

Gabungkan itu dengan bagian sebelumnya. Di sisi rel: setelmen final dan tidak dapat dibalik. Di sisi API: 202-any-00 "Request In Progress — Transaction still on process", 504-any-00 "Timeout — timeout from the issuer", kunci berumur sehari yang menolak saat diputar ulang, satu 404 yang maknanya berbalik per produk, dan — untuk sebagian besar lawan transaksi di direktori — tidak ada notifikasi push. Tidak ada compensating transaction di rel itu. Kontrol yang tersisa hanya rekonsiliasi, dan karena relnya tidak pernah tutup, ia harus berjalan terus-menerus, bukan semalam sekali.

Yang menggeser jadwal proyek lebih jauh dari kodenya

Bagi bank umum, Pasal 58 ayat (1) POJK No. 11/POJK.03/2022 (ditetapkan 6 Juli 2022) mewajibkan pelaporan rencana pengembangan TI setahun ke depan "paling lambat pada akhir bulan November sebelum tahun rencana pengembangan TI". Ayat (2) memberi satu kali perubahan, "paling lambat pada akhir bulan Juni tahun berjalan". Ayat (3) masih membuka pintu di luar jendela itu, tapi hanya "sepanjang memenuhi pertimbangan tertentu dan mendapatkan persetujuan dari Otoritas Jasa Keuangan" — artinya integrasi yang tidak masuk rencana November berubah dari pekerjaan teknis menjadi permohonan.

Pasal 30 ayat (3) huruf i mewajibkan perjanjian dengan penyedia jasa TI memuat "kesediaan pihak penyedia jasa TI untuk memberikan akses kepada Otoritas Jasa Keuangan dan/atau pihak lain yang berwenang untuk melakukan pemeriksaan"; huruf c menambahkan komitmen menyerahkan hasil audit TI berkala oleh auditor independen. Integrator Anda ikut menandatangani kesediaan diperiksa. Dan kalau kegagalan verifikasi tanda tangan sampai membocorkan data transaksi, tiga jam berjalan bersamaan: notifikasi awal ke OJK paling lama 24 jam dan laporan insiden paling lama 5 hari kerja (Pasal 60 ayat (1)), serta pemberitahuan tertulis "paling lambat 3 x 24 ... jam" menurut Pasal 46 ayat (1) UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi. Selama jam-jam itu, transaksi yang terkena sudah selesai disetelmen secara final.

Kalau jawabannya payment gateway, yang berpindah adalah buktinya

Rute keempat adalah tidak menyambung ke bank sama sekali. iPaymu menjual justru ketiadaannya: di berandanya ada baris fitur "Tanpa Host-to-Host ke Bank", bersebelahan dengan "Realtime Settlement" dan "PCI Compliant (PCIDSS)". Perumusan yang jujur soal pertukarannya — API payment gateway memang menyerap beban host-to-host, dan harganya adalah setelmen, rekonsiliasi serta berkas kepatuhan berpindah ke pihak ketiga.

Untuk lembaga yang diawasi, perpindahan itu tidak sampai ke ujung. Penjelasan Pasal 29 ayat (1) POJK 11/2022 menyatakannya terang: "meskipun Bank menyerahkan penyelenggaraan TI kepada pihak penyedia jasa TI maka Bank tetap bertindak sebagai penyelenggara Sistem Elektronik untuk setiap Sistem Elektronik yang digunakan Bank". Pertanyaannya karena itu bukan "API atau host to host", melainkan siapa yang memegang buktinya saat pemeriksa bertanya.

Apa yang bisa dan tidak bisa kami klaim

Batasnya kami sebut lebih dulu, dan bisa Anda periksa sendiri. Pada 4 September 2026 kami memindai seluruh muatan API portofolio publik WEBARQ: 214 klien aktif, 42 di antaranya Banking & Financial, 13 punya narasi studi kasus lengkap. Di seluruh 26 muatan detail itu — 13 klien dikali dua bahasa — kemunculan "host to host", "payment gateway", "BI-FAST", "QRIS", "virtual account", "SNAP", "RTGS", "SKNBI" dan "core banking" berjumlah nol masing-masing. WEBARQ belum pernah menyambungkan rel pembayaran, dan kami tidak akan menyiratkan sebaliknya. Kalau sebuah agensi mengklaim pengalaman host-to-host, minta nama Sub-API-nya dan tanggal verifikasinya.

Yang bisa kami buktikan adalah pekerjaan di sebelahnya. Pada CGS International, tantangan yang tercatat adalah "menghubungkan basis data dari bank, CGS-CIMB, KSEI, dan DUKCAPIL secara efisien untuk memperlancar operasi pengguna dan meningkatkan akurasi data" pada pembukaan rekening efek daring dengan OCR pada formulir web, panggilan video dan verifikasi mandiri — empat lawan transaksi, sinkron, di bawah aturan sektor keuangan. Pada MSIG, sistem situs "terhubung langsung dengan sistem finansial utama MSIG untuk memperlancar penjualan polis, pengumpulan premi, dan interaksi keuangan pelanggan".

Satu detail dari pemindaian yang sama, dan kami sendiri baru menyadarinya: daftar tantangan MSIG versi Indonesia memuat lima butir, versi Inggrisnya empat. Butir yang hanya ada di versi Indonesia berbunyi:

"Memastikan integrasi yang lancar dari sistem utama ke sistem situs tanpa mengganggu layanan yang ada."

Di sektor ini uang hampir tidak pernah bergerak di lapisan kanal. Ia bergerak di core, dan tugas kanal adalah berbicara dengan core itu secara benar — persis alasan host-to-host ada.

Apa artinya untuk Anda

• Solution architect. Sebelum estimasi, minta tiga hal: Dokumen Spesifikasi Teknis dari bank, daftar Sub-API yang benar-benar disediakan, dan konfirmasi tertulis format serta panjang X-EXTERNAL-ID untuk lawan transaksi itu. Kalau notifikasi push tidak ada di daftar, jadikan polling status jalur utama sejak hari pertama.
• CISO. Konsesi TLS 1.2 tutup 30 Juni 2026, jadi lawan transaksi yang masih menegosiasikannya adalah temuan hari ini, bukan rencana migrasi. Standar yang sama menuntut "penerapan whitelisted IP pada perangkat/aset yang digunakan untuk Open API Pembayaran berbasis SNAP" — itu keputusan penempatan konektor ERP, bukan tiket firewall.
• Compliance. Pasal 30 ayat (3) huruf i masuk ke kontrak pengembang, disusun sebelum kick-off, bukan ditempel setelah UAT.
• Direktur yang menandatangani anggaran. Jalur kritisnya bukan koding. Jalur kritisnya jendela perubahan rencana TI yang menutup akhir Juni menurut Pasal 58 ayat (2), dan verifikasi yang mendahului integrasi.

Untuk konteks rel mana yang membawa pembayaran mana, mulai dari Payment Gateway Indonesia vs BI-FAST, QRIS, dan Virtual Account. Lapisan integrasinya sendiri masuk ke pengembangan cloud native application dan pengembangan website yang kami kerjakan.

Metode. Halaman produk BCA, Bank Mandiri, Maybank Indonesia dan iPaymu, lima dokumentasi X-EXTERNAL-ID, indeks Direktori Publikasi ASPI beserta seluruh 15 halaman detailnya, serta API studi kasus publik WEBARQ — semuanya diambil pada 4 September 2026 dari jaringan Jakarta. Hitungan Sub-API dilakukan per entitas, bukan per baris, karena beberapa halaman mengulang layanan di kedua kolom dan mencetak baris kembar. Kutipan peraturan diambil dari PDF penerbitnya di bi.go.id, ojk.go.id dan peraturan.bpk.go.id. Direktori ASPI bisa berubah dan tidak mencantumkan tanggal pemutakhiran; ulangi pengukurannya sebelum memakainya di kertas kerja. Disusun dengan bantuan AI, diperiksa terhadap sumber primer oleh tim WEBARQ.