Dari Payment ke Open API

Tahap pertama digitalisasi pembayaran adalah membuat transaksi menjadi elektronik.

Tahap berikutnya jauh lebih sulit.

Membuat seluruh sistem di belakang transaksi saling memahami.

Sebuah restoran bisa menerima pembayaran digital dalam hitungan detik.

Namun finance masih perlu mencocokkan settlement dengan order.

Tim accounting memasukkan transaksi ke sistem lain.

Refund diproses di aplikasi berbeda.

Treasury melihat saldo di portal lain.

Customer service membuka sistem lain lagi untuk mencari riwayat pembelian.

Secara kasat mata bisnis sudah digital.

Di belakang layar, workflow-nya masih terfragmentasi.

Di titik inilah Open API menjadi penting.

Pembayaran yang cepat belum tentu menghasilkan operasi yang efisien

Bayangkan customer membayar Rp250.000.

Bagi customer, transaksinya selesai.

Bagi perusahaan, justru banyak proses baru dimulai.

Apakah order sudah berubah status menjadi paid?

Apakah stok otomatis berkurang?

Apakah invoice terbentuk?

Apakah transaksi tercatat dalam accounting?

Kapan settlement masuk?

Bagaimana fee dicatat?

Jika refund terjadi, apakah seluruh sistem menerima informasi yang sama?

Semakin banyak jawaban yang memerlukan pekerjaan manual, semakin kecil productivity gain dari digital payment.

Karena itu tahap berikutnya bukan sekadar membuat payment lebih cepat.

Tetapi membuat payment information mengalir ke seluruh business workflow.

Indonesia sudah memiliki bahasa standar

Bank Indonesia menetapkan Standar Nasional Open API Pembayaran atau SNAP melalui keputusan pada Agustus 2021.[1]

SNAP menstandarkan berbagai komponen teknis dan keamanan Open API pembayaran, termasuk:

protokol komunikasi;

arsitektur API;

format data;

metode autentikasi;

otorisasi;

enkripsi;

pengelolaan akses;

struktur request;

dan struktur response.[1]

Selain standar teknis, SNAP juga memiliki pedoman tata kelola yang mencakup pelindungan konsumen, perlindungan data, kehati-hatian, serta kontrak antara penyedia dan pengguna layanan.[1]

Tujuannya adalah menciptakan sistem yang lebih terintegrasi, interoperable, aman, kompetitif, dan efisien.

SNAP bukan produk baru 2026

Ini penting untuk diluruskan.

SNAP bukan inovasi yang baru muncul pada FEKDI 2026.

Standarnya sudah ditetapkan sejak 2021.

Pengelolaannya bahkan telah dialihkan dari Bank Indonesia kepada Asosiasi Sistem Pembayaran Indonesia atau ASPI sejak 1 September 2023.[1]

Yang berubah pada 2026 adalah konteks industrinya semakin matang.

Bank Indonesia kini menjalankan PBI Nomor 10 Tahun 2025 dan aturan pelaksanaannya, PADG Nomor 32 Tahun 2025, yang sama-sama efektif sejak 31 Maret 2026.[2][3]

Kerangka baru itu jauh lebih luas daripada API.

Ia mengatur struktur industri, aktivitas, produk, pricing, teknologi, governance, risk management, data, pengawasan, serta kerja sama.

Jadi Open API harus dilihat sebagai salah satu bagian dari arsitektur sistem pembayaran yang lebih besar.

Mengapa API penting bagi bisnis non-finansial?

API sering terdengar seperti topik engineer.

Padahal dampaknya sangat operasional.

Retailer ingin payment langsung masuk POS.

Hotel ingin settlement terhubung ke booking.

Marketplace ingin refund sinkron dengan order.

Distributor ingin payment status masuk ERP.

Corporate treasury ingin collection masuk cash-positioning.

SaaS business ingin billing memicu provisioning otomatis.

Tanpa integration layer, setiap proses membutuhkan rekonsiliasi manusia.

API memungkinkan sistem berbicara langsung.

Standardisasi mengurangi “bahasa” yang berbeda

Tanpa standar, satu perusahaan dapat menghadapi provider A dengan format API tertentu, provider B dengan format lain, dan provider C dengan autentikasi berbeda.

Setiap integration menjadi proyek khusus.

Biaya naik.

Maintenance naik.

Dependency pada developer tertentu naik.

Standardisasi mengurangi variasi yang tidak perlu.

Bukan berarti semua API menjadi identik.

Tetapi fondasi teknisnya menjadi lebih konsisten.

Itu menurunkan friction integrasi.

Tetapi standar tidak otomatis menciptakan integrasi yang baik

Ini distinction penting.

SNAP memberi standar.

Ia tidak menjamin implementation quality.

Dua perusahaan dapat sama-sama mengikuti standar tetapi memiliki:

uptime berbeda;

latency berbeda;

error handling berbeda;

documentation berbeda;

support berbeda;

dan incident response berbeda.

Bagi merchant atau enterprise customer, pengalaman integrasi masih dipengaruhi kualitas provider.

Karena itu compliance terhadap standard adalah baseline.

Bukan competitive advantage akhir.

Competitive advantage berpindah ke workflow

Saat acceptance payment semakin commoditised, diferensiasi dapat berpindah ke pertanyaan lain.

Seberapa mudah payment terhubung ke bisnis?

Seberapa cepat onboarding?

Apakah settlement mudah direkonsiliasi?

Apakah refund otomatis?

Apakah accounting integration tersedia?

Apakah webhook reliable?

Apakah API documentation jelas?

Apakah sandbox representatif terhadap production?

Inilah layer yang semakin menentukan developer dan merchant experience.

POS → payment → accounting seharusnya satu alur

Ambil contoh restoran.

Order dibuat di POS.

Customer membayar.

Payment provider mengirim status sukses.

POS mengubah order menjadi paid.

Accounting mencatat revenue.

Inventory mengurangi bahan.

Dashboard memperbarui sales.

Settlement kemudian direkonsiliasi terhadap transaksi.

Jika kelima langkah ini terjadi otomatis, payment menjadi infrastructure.

Jika empat langkah terakhir masih manual, payment hanya digital di permukaan.

ERP integration lebih penting untuk perusahaan besar

Untuk perusahaan dengan volume besar, payment integration bisa masuk lebih dalam.

Accounts receivable.

Invoice matching.

Virtual account.

Collections.

Treasury.

Cash forecasting.

Vendor payments.

Refund.

Enterprise resource planning.

Selisih satu persen dalam automation mungkin menghasilkan ribuan transaksi manual lebih sedikit.

Di skala enterprise, API adalah productivity infrastructure.

Authentication dan authorisation tidak boleh dianggap detail teknis

API menghubungkan sistem.

Artinya API juga membuka jalur akses.

Karena itu autentikasi dan otorisasi menjadi kritis.

Siapa yang dapat meminta data?

Data apa?

Untuk tindakan apa?

Berapa lama akses berlaku?

Bagaimana credential disimpan?

Bagaimana akses dicabut?

SNAP secara eksplisit memasukkan authentication, authorisation, encryption, dan API access management ke dalam standar.[1]

Itu bukan formalitas.

Salah konfigurasi dapat menjadi security exposure.

Integration memperluas attack surface

Sebelum API, sistem A dan sistem B mungkin relatif terpisah.

Setelah terintegrasi, kelemahan di satu titik dapat mempunyai konsekuensi lintas sistem.

API key bocor.

Credential digunakan berlebihan.

Webhook dipalsukan.

Partner system compromise.

Rate limit tidak tepat.

Third party menjadi entry point.

Semakin connected sistem, semakin penting zero-trust thinking dan least privilege.

Operational risk juga meningkat

Integrasi yang baik mengurangi pekerjaan.

Integrasi yang buruk dapat menciptakan dependency baru.

Misalnya:

payment sebenarnya sukses;

tetapi webhook gagal;

POS menganggap belum bayar;

customer dikenakan dua kali;

refund dibuat;

settlement kemudian tidak cocok.

Masalah kecil di integration layer bisa menghasilkan customer-service incident.

Karena itu integration reliability perlu dipantau seperti core business process.

API uptime bukan satu-satunya KPI

Sistem bisa technically “up” tetapi tetap buruk digunakan.

Enterprise sebaiknya melihat:

success rate;

latency;

timeout;

duplicate event;

reconciliation break;

failed callback;

retry behaviour;

incident recovery time.

Uptime 99,9% terdengar bagus.

Tetapi jika error terkonsentrasi pada jam peak, dampak ekonominya bisa besar.

Idempotency terdengar teknis, tetapi dampaknya bisnis

Dalam payment system, retry bisa terjadi.

Network terputus.

Response terlambat.

Application mencoba kembali.

Jika sistem tidak dirancang menangani request berulang secara aman, customer bisa melihat transaksi ganda.

Konsep seperti idempotency bukan jargon engineering semata.

Ia melindungi customer dan reconciliation.

Data minimisation tetap relevan

API membuat data lebih mudah bergerak.

Tetapi bukan berarti semua data harus bergerak.

Jika sistem hanya membutuhkan:

transaction ID;

amount;

status;

timestamp;

maka ia mungkin tidak perlu mendapat data customer yang lebih luas.

Semakin banyak integrasi, semakin penting membatasi data pada kebutuhan aktual.

SNAP memasukkan perlindungan data dalam governance framework.[1]

Consent dan purpose tidak hilang karena API

Customer memberikan izin kepada satu service bukan berarti seluruh ecosystem bebas menggunakan data untuk semua tujuan.

Technical connectivity tidak sama dengan legal permission.

Organisasi tetap perlu mengelola:

consent;

purpose;

retention;

sharing;

security.

API mempercepat data flow.

Governance harus ikut mempercepat kontrol.

Vendor lock-in tetap mungkin

Open API tidak otomatis menghapus vendor dependency.

Perusahaan bisa tetap terkunci karena:

proprietary business logic;

historical data;

workflow integration;

switching cost;

contract;

atau bespoke feature.

Karena itu procurement perlu membedakan:

technical interoperability;

dan practical portability.

Sistem bisa technically open tetapi economically sulit dipindahkan.

Design for exit

Saat memilih payment provider atau middleware, perusahaan jarang bertanya:

“Bagaimana kalau lima tahun lagi kita ingin pindah?”

Padahal exit architecture penting.

Apakah data mudah diekspor?

Apakah integration layer reusable?

Apakah API mapping terdokumentasi?

Apakah contract memungkinkan migration?

Apakah dual-running bisa dilakukan?

Architecture yang baik tidak hanya mempermudah masuk.

Ia juga mempermudah keluar.

Regulator juga melihat struktur industri, bukan sekadar inovasi

PBI 10/2025 memperkenalkan pendekatan yang lebih menyeluruh terhadap industri sistem pembayaran.[2]

Ruang lingkupnya mencakup:

aktivitas;

produk;

pricing;

innovation;

industrial structure;

payment and data infrastructure;

governance;

risk management;

market conduct;

consumer protection;

data;

dan supervision.[2]

PADG 32/2025 kemudian memperinci implementasinya.[3]

Pesannya jelas:

innovation harus berjalan bersama resilience.

“Same activity, same risk, same regulation”

PBI baru juga menggunakan pendekatan penilaian berbasis transaksi, interkoneksi, kompetensi, risk management, dan infrastructure technology—diringkas dalam konsep TIKMI.[2]

Ini relevan untuk API ecosystem.

Semakin sebuah pihak terhubung dan semakin kritikal perannya dalam payment chain, semakin besar konsekuensi operasional jika gagal.

Connectivity meningkatkan usefulness.

Ia juga meningkatkan systemic importance.

FEKDI hadir di momentum yang tepat

Bank Indonesia menjadwalkan Festival Ekonomi dan Keuangan Digital Indonesia pada 24–26 September 2026.[4]

Dalam Tinjauan Kebijakan Moneter Agustus, BI menyebut FEKDI 2026 berkolaborasi dengan Indonesia Fintech Summit & Expo serta OJK dan pemerintah.[5]

Momentum ini tepat karena pembicaraan ekosistem digital Indonesia mulai bergerak dari:

“berapa banyak user?”

ke:

“seberapa baik infrastructure bekerja?”

Itu evolusi yang sehat.

Open API bukan tujuan akhir

Ada risiko lain.

Perusahaan mengejar jumlah integration sebagai vanity metric.

“Sudah punya 150 API.”

Tetapi banyak yang tidak digunakan.

Atau digunakan tetapi tidak menghasilkan efficiency.

API seharusnya dinilai berdasarkan outcome.

Berapa jam rekonsiliasi berkurang?

Berapa settlement mismatch turun?

Berapa onboarding partner lebih cepat?

Berapa error manual hilang?

Berapa lead time integration turun?

API count tidak sama dengan value.

Integration debt bisa menjadi technical debt berikutnya

Semakin banyak point-to-point integration, semakin sulit architecture dipelihara.

Provider A terhubung langsung ke ERP.

Provider B langsung ke POS.

Provider C ke CRM.

Marketplace punya custom connector.

Setiap perubahan menciptakan efek berantai.

Pada akhirnya perusahaan memiliki integration spaghetti.

Karena itu bisnis membutuhkan architecture principle.

Canonical data.

API gateway.

Event standard.

Version control.

Monitoring.

Ownership.

Tidak perlu menjadi perusahaan teknologi untuk memerlukan discipline ini.

CFO harus ikut peduli

API bukan hanya urusan CIO.

Jika integration buruk, dampaknya masuk ke finance:

unreconciled cash;

delayed close;

manual headcount;

payment dispute;

duplicate refund;

working-capital uncertainty.

CFO seharusnya memahami apakah payment architecture mengurangi atau menambah operating complexity.

Product team juga harus peduli

Bagi product, integration menentukan customer experience.

Customer tidak peduli apakah kegagalan terjadi pada merchant, payment provider, atau middleware.

Mereka hanya melihat:

pembayaran gagal.

refund terlambat.

order tidak tercatat.

Karena itu partner integration adalah bagian dari product experience.

Treasury mendapat value paling nyata

Corporate treasury dapat memperoleh manfaat besar dari connected payment data.

Near-real-time collection visibility.

Better cash positioning.

Automated reconciliation.

Faster exception handling.

Improved cash forecast.

Tetapi manfaat ini muncul hanya jika transaction data memiliki identifier yang konsisten.

API tanpa data hygiene tetap menghasilkan kekacauan lebih cepat.

Jangan otomatis membangun semuanya sendiri

Perusahaan bisa:

build direct integration;

menggunakan middleware;

payment gateway;

ERP connector;

atau orchestration layer.

Tidak ada satu model terbaik.

Pilihan harus mempertimbangkan:

volume;

complexity;

control;

cost;

security;

vendor dependency;

dan internal engineering capability.

Architecture seharusnya mengikuti kebutuhan bisnis.

Pertanyaan yang perlu diajukan sebelum integrasi

Apa business outcome-nya?

Siapa owner-nya?

Data apa yang benar-benar perlu bergerak?

Apa failure mode terburuk?

Bagaimana reconciliation dilakukan?

Bagaimana system retry?

Siapa yang menangani incident?

Bagaimana akses dicabut?

Apa exit plan?

Jika pertanyaan ini belum terjawab, integration mungkin terlalu cepat dibuat.

Pembayaran sudah digital. Sekarang bisnis harus benar-benar terhubung

Indonesia sudah melewati fase ketika digital payment dianggap novelty.

Puluhan juta merchant menggunakan QRIS.

BI-FAST beroperasi dalam skala besar.

Open API memiliki standar nasional.

Regulasi industri juga semakin matang.

Tantangan berikutnya bukan membuat lebih banyak layer digital yang berdiri sendiri.

Tantangannya adalah membuat layer tersebut bekerja bersama.

Payment.

Order.

Accounting.

Inventory.

Treasury.

Customer service.

Financing.

Ketika semua terhubung dengan baik, customer mungkin bahkan tidak menyadarinya.

Dan justru itu tanda infrastructure bekerja.

Integrasi terbaik bukan yang paling terlihat. Ia adalah yang membuat proses kompleks terasa sederhana.