Bank Host to Host vs Payment Gateway Integration

Payment gateway integration and bank host-to-host integration get sold as the same decision at different price points. They are not. On 4 September 2026 we read the published SNAP documentation of five Indonesian publishers and compared how each specifies one mandatory header, X-EXTERNAL-ID. The declared field lengths were 36, 32 and 9 characters, and one publisher recommends a UUID. That header decides whether your ERP connector can talk to three counterparties or one, and nobody puts it in a proposal.

Start further back, though, because the term itself is unstable. At BCA, Host to Host ERP Integration (HEI) is a file channel: BCA supplies the "Aplikasi BCA Client" with a "Security Key Pretty Good Privacy (PGP)" or the "Aplikasi SSH File Transfer Protocol (SFTP) BCA", and the customer builds the HEI system "berdasarkan Dokumen Spesifikasi Teknis dari BCA". At Bank Mandiri, Kopra Host to Host is "a payment solution that utilizes direct debiting based on API integration between the Bank's system and your Enterprise Resources Planning (ERP) system". Maybank Indonesia uses the identical phrase for plain SFTP. Three banks, three technologies, one product name.

One mandatory header, five specifications that disagree

Here is the comparison, each row read from that publisher's own live documentation on 4 September 2026.

Publisher	Documented type and length	Documented description
ASPI — SNAP Keamanan reference	Mandatory, String (36)	"Numeric String. Reference number that should be unique in the same day" — identical wording in the Transaction Request (B2B) and (B2B2C) header tables
DOKU — SNAP QRIS	Required, no length stated	"Numeric String. Reference number that should be unique in the same day (Request Id)"
Espay — Direct API SNAP QRIS	String (32), mandatory	"String Numerik. Kode referensi yang bersifat unik pada hari yang sama."
BRI — SNAP BI Bank Statement	Numeric, mandatory, length 9	—
Midtrans — Core API SNAP	UUID recommended, TTL 24 hours	"we highly recommend merchant to use UUID format to avoid duplication"

A UUID is 36 characters, so it fits ASPI's declared length while contradicting ASPI's own description of the field as numeric. It fits neither Espay's 32 nor BRI's 9. And the standard-setter's own worked example runs to 32 digits — 41807553358950093184162180797837 — printed underneath a type that says String (36).

Our view, and it is the most expensive line in the whole standard: generate one identifier scheme in your ERP connector, fan it out to three counterparties, and at least one rejects it — as 409 "Cannot use same X-EXTERNAL-ID in same day", which says nothing about format. Agree the scheme in writing per counterparty, not once for the programme. Time is contested too: Midtrans documents a rolling 24-hour TTL, ASPI a calendar day, so a retry crossing midnight is a new transaction under one reading and a duplicate under the other.

Why the file-versus-API split is not an architectural preference

SNAP's scope sits in Pasal 3 ayat (4) of PADG No. 23/15/PADG/2021 (issued 16 August 2021), and the verb matters: the technical, security and data standards are applied "dalam API dengan kategori" — registration, balance information, transaction history, credit transfer, debit transfer, plus any further category Bank Indonesia designates. A payroll file pushed over SFTP is not an API and is not in those categories. Take a file channel and you get a bank-proprietary interface with no national standard behind it, which is entirely lawful and entirely on you.

Bank Mandiri prints the division on its own product page. Kopra Host to Host requires adherence to "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". Two specification regimes in one product, and what decides which applies is the service, not the channel.

The common mistake is assuming the obligation stops at the bank. Pasal 127 ayat (3) of PBI No. 10 Tahun 2025, in force 31 March 2026, applies the national-standards obligation "mutatis mutandis" to "Penyelenggara Penunjang dan pihak lain yang melakukan kerja sama dengan PJP, PIP, dan/atau Peserta". Build the integration and you are that other party. Pasal 184 huruf c keeps PBI 23/11/PBI/2021 alive "termasuk peraturan pelaksanaannya", so the SNAP PADG did not go with the old regime. The examiner's file we covered separately in SNAP BI Open API Compliance: The Examiner's Nine Files.

What the SNAP directory shows once you separate the two columns

Our Tuesday piece counted 15 entities in the Direktori Publikasi on ASPI's SNAP Developer Site on 2 September 2026, and said plainly that listing is voluntary, so the number is a floor rather than a census. We re-opened all 15 detail pages on 4 September; the population was unchanged. What nobody has counted is inside those pages. Each separates List of Services Provided from List of Services Consumed, and the answer changes sharply depending on which column you read.

SNAP sub-API	Provided by	Listed in either column
API Balance Inquiry	9 of 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, PT Bank Permata, Tbk	4

Two. The push notification most reconciliation designs are built around is offered by two of the fifteen. Two others list it as something they consume — PT Bank Rakyat Indonesia Tbk and PT Harsya Remitindo — which is useful in itself, because a bank appearing as a consumer tells you where it sits in somebody else's flow.

Look at the shape, not any single row. The most widely provided service is a balance read; the least provided is the only one that pushes data at you unasked. Read that way the directory is not a compliance register at all. It is a supplier capability list, and the suppliers sell reads.

The method matters, because the pages are untidy. We counted per entity, not per row: several list the same service in both columns, and some rows are literal duplicates — PT GDC Multi Sarana prints "API Transaction Status Inquiry" twice, PT Harsya Remitindo's 60 consumed rows hold 58 distinct names, and PT Bank Mandiri Persero Tbk's page prints 22 rows for 21 services. Two entities provide nothing at all.

Three places SNAP implementations break at runtime

1. The idempotency key is not an idempotency key

ASPI's response-code table carries two 409s that have to be read as a pair: 409-any-00 Conflict, "Cannot use same X-EXTERNAL-ID in same day", and 409-any-01 Duplicate partnerReferenceNo, "Transaction has previously been processed". Replaying a request with the same key returns a rejection, not the same answer — the opposite of what an idempotency key does everywhere else.

What turns that from an oddity into a trap is Midtrans's own mapping. It documents a real Idempotency-Key with correct semantics — "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" — then, on the next line, equates X-EXTERNAL-ID with it: "Has the same usage as idempotency-key in legacy API." Two headers, two behaviours, one description. And since responseCode is composed as "HTTP status code + service code + case code", a handler matching on a leading "409" collapses a key collision and a genuine duplicate into one branch.

2. One 404 that means success and failure at once

404-any-18 "Inconsistent Request" reads: "It can be considered as failed in transfer debit, but it should be considered as success in transfer credit." ASPI then enumerates it. Success: intrabank, interbank, RTGS and SKNBI transfers, VA payment and payment to VA, refund payment, void. Failed: transfer to OTC, direct debit payment, QR CPM payment, auth payment, capture. One HTTP status whose meaning inverts depending on which sub-API produced it — and a generic handler reads it wrong in the direction of either paying twice or reversing a transaction that succeeded.

3. The signature formula names the wrong key

The asymmetric transaction signature is published as "SHA256withRSA (clientSecret, stringToSign)". SHA256withRSA signs with a private key, not a client secret, and the access-token formula on the same page gets it right: "SHA256withRSA (Private_Key, stringToSign)". Which construction applies is picked by a header value — "1 - Symmetric Signature with Get Token; 2 - Asymmetric Signature without Get Token", Default Value: 1. Two entirely different stringToSign constructions behind one header, and the default is rarely a deliberate choice.

One transport note whose date has passed. The same standard sets TLS 1.3, allows negotiating down to TLS 1.2 with four named cipher suites, then closes that door: the fallback "hanya dapat diterapkan oleh Penyedia Layanan dan Pengguna Layanan sampai dengan tanggal 30 Juni 2026". Since 1 July 2026 there is no compliant TLS 1.2 path on either side. We measured 15 Indonesian payment API hosts against that on 2 September 2026 and published the results with the compliance piece.

Reconciliation is architecture work, not operations work

Pasal 2 of PADG No. 17 Tahun 2023 on BI-FAST (issued 28 November 2023, amended three times, most recently by PADG 3/2026 in force 31 March 2026) sets two principles: settlement happens "secara seketika per transaksi", and it is "final dan tidak dapat dibatalkan". Pasal 34 ayat (2) and (3) add that BI-FAST runs Monday to Sunday, 24 hours. No batch window, no cut-off to hide behind.

Put that next to the previous section. On the rail: settlement that is final and irreversible. On the API: 202-any-00 "Request In Progress", 504-any-00 "Timeout — timeout from the issuer", a one-day key that rejects on replay, a 404 whose meaning flips per product, and for most counterparties in the directory no push notification at all. There is no compensating transaction on that rail. The only control left is reconciliation, and because the rail never closes it runs continuously rather than once overnight.

What moves the schedule further than the code does

For a commercial bank, Pasal 58 ayat (1) of POJK No. 11/POJK.03/2022 requires next year's IT development plan to be reported "paling lambat pada akhir bulan November". Ayat (2) allows one change, "paling lambat pada akhir bulan Juni tahun berjalan". Ayat (3) leaves a door open outside that window, but only with particular justification and OJK approval — which turns an integration that missed November's plan from engineering work into an application.

Pasal 30 ayat (3) huruf i requires the agreement with an IT service provider to record its "kesediaan ... untuk memberikan akses kepada Otoritas Jasa Keuangan dan/atau pihak lain yang berwenang untuk melakukan pemeriksaan"; huruf c adds periodic independent IT audit results. Your integrator signs up to being examined alongside you. And if a signature-verification failure leaks transaction data, three clocks run at once: initial notification to OJK within 24 hours and an incident report within 5 working days (Pasal 60 ayat (1)), plus written notification "paling lambat 3 x 24 ... jam" under Pasal 46 ayat (1) of UU No. 27 Tahun 2022. Through every one of those hours the affected transactions have already settled with finality.

If the answer is a payment gateway, what moves is the evidence

The fourth route is not connecting to a bank at all. iPaymu sells precisely that absence: among the features on its home page is "Tanpa Host-to-Host ke Bank", next to "Realtime Settlement" and "PCI Compliant (PCIDSS)". An honest statement of the trade. A payment gateway API does absorb the host-to-host burden, and the price is that settlement, reconciliation and the compliance file move to a third party.

For a supervised institution that move does not go all the way. The Penjelasan to Pasal 29 ayat (1) of POJK 11/2022 says it outright: even where a bank hands IT operation to a service provider it "tetap bertindak sebagai penyelenggara Sistem Elektronik" for every electronic system it uses. So the question is not "API or host to host". It is who holds the evidence when the examiner asks.

What we can and cannot claim

The limit first, because you can check it. On 4 September 2026 we scanned every payload of WEBARQ's public portfolio API: 214 active clients, 42 of them in Banking & Financial, 13 carrying a full case-study narrative. Across all 26 detail payloads — 13 clients in two languages — occurrences of "host to host", "payment gateway", "BI-FAST", "QRIS", "virtual account", "SNAP", "RTGS", "SKNBI" and "core banking" came back at zero each. We have never connected a payment rail and we are not going to imply otherwise. When an agency claims host-to-host experience, ask for the sub-API names and the verification date.

What we can evidence is the adjacent work. On CGS International, the recorded challenge is "Efficiently linking databases from banks, CGS-CIMB, KSEI, and DUKCAPIL to streamline user operations and data accuracy", for online securities account opening with OCR on the web form, video call and self-verification — four counterparties, synchronous, under financial-sector rules. On MSIG, the site "Links directly with MSIG's core financial systems to streamline policy sales, premium collections, and customer financial interactions". One detail from the same scan we had missed: the MSIG challenge list runs to five items in Indonesian and four in English, and the extra one is integrating the core into the website system without disturbing services already running.

In this sector money almost never moves in the channel layer. It moves in the core, and the channel's job is to talk to that core correctly — which is why host-to-host exists at all.

What this means for you

• Solution architect. Before estimating, ask for three things: the bank's technical specification document, the list of sub-APIs it actually provides, and written confirmation of the X-EXTERNAL-ID format and length for that counterparty. If push notification is not on the list, make status polling the primary path from day one.
• CISO. The TLS 1.2 concession closed on 30 June 2026, so a counterparty still negotiating it is a finding today, not a migration item. The same standard requires "penerapan whitelisted IP pada perangkat/aset yang digunakan untuk Open API Pembayaran berbasis SNAP" — which decides where the ERP connector may run. That is a hosting decision, not a firewall ticket.
• Compliance. Pasal 30 ayat (3) huruf i belongs in the developer contract, drafted before kick-off rather than bolted on after UAT.
• The director signing the budget. The critical path is not the code. It is the IT plan amendment window that closes at the end of June under Pasal 58 ayat (2), and verification that has to precede integration.

For which rail should carry which payment, start with Indonesia Payment Gateway, BI-FAST and QRIS: Who Can Connect. The integration layer itself is cloud native application development and website development work, which is what we do.

Method. The BCA, Bank Mandiri, Maybank Indonesia and iPaymu product pages, the five X-EXTERNAL-ID specifications, the ASPI Direktori Publikasi index with all 15 detail pages, and WEBARQ's public case-study API were all fetched on 4 September 2026 from a Jakarta network. Sub-API counts are deduplicated per entity, because several pages repeat a service across the two lists and some print duplicate rows. Regulatory quotations come from the issuing body's own PDFs at bi.go.id, ojk.go.id and peraturan.bpk.go.id. The ASPI directory is a mutable list publishing no "as of" date, so re-run the measurement before it goes into a working paper. Written with AI assistance and checked against primary sources by the WEBARQ team.