MDR QRIS 0%: Checklist Integrasi QRIS dengan Kasir

Pelanggan memindai QRIS. Printer nota berbunyi. Layar ponselnya menampilkan pembayaran berhasil, lalu ia pergi membawa pesanannya. Dari sisi pelanggan, transaksi selesai dalam hitungan detik. Dari sisi bisnis, pekerjaan belum tentu selesai.

“Saya sudah bayar, Pak.” Kasir melihat layar yang masih berputar. Di belakang pelanggan, antrean mulai memanjang. Ia tidak ingin meminta pelanggan membayar dua kali, tetapi juga tidak berani menyerahkan pesanan tanpa kepastian.

Bisa jadi kasir masih menulis nota di kertas. Notifikasi pembayaran masuk dua kali. Atau transaksi sudah tercatat sebagai penjualan, tetapi dana settlement baru terlihat di rekening pada hari berbeda. Di sinilah integrasi QRIS dengan kasir menjadi penting: bukan sekadar membuat pembayaran lebih praktis, melainkan memastikan setiap transaksi bisa ditelusuri dari order sampai dana diterima.

Momentum untuk mengecek alur ini cukup dekat. Bank Indonesia menyebut kebijakan MDR QRIS 0% untuk transaksi sampai dengan Rp100.000 mulai berlaku pada 1 Oktober 2026. Namun, tarif yang lebih ringan hanya berguna kalau data transaksi tetap rapi. Berikut checklist yang bisa kamu pakai untuk menyiapkan kasir, POS, dashboard, dan proses rekonsiliasi. Periksa ketentuan Bank Indonesia dan provider terbaru sebelum mengubah asumsi biaya atau menjalankan implementasi.

Photo by sam sul on Unsplash.

Checklist Persiapan Integrasi QRIS dengan Kasir untuk UMKM

Pembayaran berhasil belum tentu laporan benar

Bayangkan sebuah kedai dengan transaksi ilustrasi senilai Rp78.000. Seorang pelanggan membayar melalui QRIS. Kasir melihat notifikasi, lalu menekan tombol “selesai” di aplikasi kasir. Beberapa menit kemudian, notifikasi yang sama muncul lagi karena sistem menerima pengiriman ulang dari penyedia pembayaran. Kalau kasir mencatatnya secara manual, ada risiko satu transaksi dianggap dua kali.

Skenario lain juga sering menjadi sumber masalah. Pelanggan membayar, tetapi jaringan kasir sempat terputus. Layar masih menunjukkan status menunggu. Kasir tidak tahu apakah uang sudah masuk, sehingga pelanggan diminta membayar ulang. Padahal pembayaran pertama mungkin sudah berhasil.

Masalah seperti ini bukan selesai dengan menempelkan kode QRIS yang lebih besar. Yang perlu dibenahi adalah hubungan antara order, pembayaran, dan pencatatan kasir. Setiap order harus punya identitas yang jelas. Setiap perubahan status harus tersimpan. Setiap pengecualian harus punya jalur penyelesaian.

Batas kebijakan dan tanggal berlakunya

MDR QRIS 0% untuk transaksi sampai dengan Rp100.000 mulai berlaku 1 Oktober 2026 ^[1]. Jangan langsung mengasumsikan bahwa semua transaksi atau semua kondisi bisnis otomatis bebas biaya. Periksa ketentuan resmi terbaru, kategori usaha, penyedia layanan, serta komponen biaya lain yang mungkin tetap berlaku.

Untuk owner, pertanyaan praktisnya adalah:

• Berapa banyak transaksi harian yang nilainya sampai dengan Rp100.000?

• Apakah nominal di POS sama dengan nominal yang dibayar?

• Apakah refund dan pembatalan sudah dipisahkan dari penjualan?

• Kapan provider menandai dana sebagai settled, kapan dana masuk ke rekening, dan siapa yang memeriksanya?

Jawaban atas pertanyaan itu harus berasal dari data transaksi, bukan perkiraan. Jadi, persiapan kebijakan bukan hanya urusan finance. Tim kasir, admin, supervisor, dan pengembang sistem perlu melihat alur yang sama.

Mengapa Volume QRIS Membuat Rekonsiliasi Manual Makin Berisiko?

Angka Bank Indonesia yang perlu dibaca bersama

Bank Indonesia mencatat volume pembayaran digital mencapai 5,50 miliar transaksi pada Juli 2026, dengan pertumbuhan 28,69% secara tahunan ^[1]. Pada bulan yang sama, volume transaksi QRIS tumbuh 82,42% secara tahunan ^[1]. Dalam laporan triwulan II 2026, pertumbuhan transaksi QRIS tercatat 100,12% secara tahunan, sementara volume pembayaran digital mencapai 16,07 miliar transaksi ^[2].

Angka bulanan dan kuartalan itu memiliki basis pengukuran yang berbeda, jadi jangan menjumlahkannya secara sembarangan. Konteksnya tetap jelas: QRIS makin sering menjadi bagian dari checkout. Bagi kedai, toko, salon, bengkel, atau usaha rumahan, kenaikan volume berarti semakin banyak transaksi yang harus dicocokkan dengan order dan laporan.

Proses yang masih aman pada volume rendah belum tentu aman saat jumlahnya naik berkali-kali lipat. Satu orang admin mungkin sanggup memeriksa notifikasi dan mutasi rekening pada sore hari. Tetapi ketika ada transaksi gagal, refund, pergantian shift, perangkat berganti, dan settlement yang tidak masuk bersamaan, pemeriksaan manual mudah berubah menjadi pekerjaan detektif.

Di kedai dengan dua shift, misalnya, supervisor sore perlu melihat transaksi yang dibuat kasir pagi tanpa mengubah catatan awal. Kalau data tidak punya identitas yang sama, rekap tutup kas hanya menyisakan pertanyaan: selisih ini muncul saat pembayaran, saat refund, atau saat dana dicairkan?

Biaya tersembunyi dari spreadsheet dan notifikasi tercecer

Biaya rekonsiliasi tidak selalu muncul sebagai pos pengeluaran yang jelas. Ia muncul sebagai waktu admin, keputusan yang tertunda, dan margin yang sulit dihitung. Jam tutup toko lewat. Selisihnya belum ketemu.

Contohnya begini. Nota kasir menunjukkan Rp78.000. Payment provider mengembalikan payment_reference dengan status pembayaran berhasil. Namun, dana settlement yang masuk ke rekening sudah dipotong biaya atau digabung dengan transaksi lain. Jika refund terjadi pada hari berikutnya, admin perlu membuka tiga tempat: aplikasi kasir, dashboard pembayaran, dan mutasi rekening.

Tanpa hubungan data yang konsisten, beberapa kesalahan mudah lolos:

1. Penjualan tercatat dua kali karena notifikasi diproses ulang.

2. Pembayaran masuk tetapi menempel pada order yang salah.

3. Refund mengurangi saldo, tetapi tidak mengubah status order.

4. Settlement dari provider dianggap sebagai penjualan baru, bukan pencairan transaksi lama.

5. Selisih kas ditutup dengan edit angka di spreadsheet tanpa jejak perubahan.

MDR adalah satu isu. Beban operasional untuk mencari transaksi yang tidak cocok adalah isu lain. Untuk memisahkan keduanya, bisnis perlu menyatukan identitas order, pembayaran, refund, dan settlement terlebih dahulu. Dari sinilah peta data dan kontrol sistem menjadi langkah berikutnya.

Peta Data Minimum dalam Integrasi QRIS dengan Kasir

Dari order_id sampai settlement

Sederhananya, setiap transaksi perlu membawa “nomor rumah” yang sama saat berpindah dari kasir ke penyedia pembayaran dan kemudian ke laporan. Peta berikut membantu tim nonteknis memahami data apa yang perlu dicocokkan, sebelum developer membahas API atau struktur database.

Pemetaan order, nominal, status pembayaran, refund, settlement, dan pencocokan transaksi pembayaran dengan catatan kasir/POS merupakan rekomendasi inti untuk kesiapan operasional. Tidak semua field harus terlihat di layar kasir, tetapi semuanya perlu tersedia untuk pemeriksaan dan audit.

Photo by Jonas Leupe on Unsplash.

Status transaksi yang tidak boleh disamakan

Gunakan status yang spesifik. pending berarti sistem masih menunggu konfirmasi. paid berarti pembayaran dikonfirmasi. failed berarti gagal. expired berarti batas waktu pembayaran lewat. refunded berarti dana sudah dikembalikan. partially_refunded berarti hanya sebagian yang dikembalikan.

settled perlu dibaca dengan lebih hati-hati. Dalam artikel ini, status tersebut berarti provider menyatakan proses settlement selesai. Itu belum otomatis sama dengan mutasi dana yang sudah tercatat masuk di rekening merchant. Bank statement tetap menjadi sumber pemeriksaan untuk penerimaan dana. Detail definisi dan waktunya mengikuti provider yang digunakan.

Kesalahan umum adalah menganggap paid sama dengan settled. Padahal keduanya menjawab pertanyaan berbeda. Status paid membantu kasir memutuskan apakah pesanan boleh diproses. Status settled membantu finance memeriksa proses pencairan dari sisi provider, sedangkan mutasi rekening membantu memastikan dana benar-benar terlihat di rekening.

Kalau dua status itu dicampur, owner bisa melihat omzet yang tampak benar, tetapi tetap kesulitan menjawab: “Transaksi ini sudah masuk rekening atau belum?”

Satu sumber kebenaran untuk laporan

Pembagian sumber data yang sederhana biasanya lebih mudah dirawat:

• POS menjadi sumber kebenaran untuk order dan item yang dijual.

• Payment service menjadi sumber kebenaran untuk status pembayaran dan payment_reference.

• Modul rekonsiliasi menjadi lapisan pencocokan antara order, pembayaran, refund, settlement provider, dan mutasi rekening.

Spreadsheet boleh dipakai untuk ekspor atau analisis sementara. Jangan menjadikannya tempat utama untuk mengubah nominal transaksi. Jika angka diedit tanpa menyimpan nilai awal, waktu, alasan, dan identitas pengguna, audit trail hilang.

Checklist Teknis Sebelum Volume Transaksi Bertambah

Bagian ini adalah rekomendasi desain integrasi, bukan ketentuan Bank Indonesia. Detail webhook, verifikasi signature, retry, refund, dan settlement tetap mengikuti dokumentasi resmi provider QRIS yang kamu gunakan.

Webhook, retry, dan idempotency

Webhook adalah notifikasi dari penyedia pembayaran ke sistem kamu. Notifikasi dapat terlambat, gagal diterima, atau dikirim ulang, tergantung perilaku provider dan kondisi jaringan. Karena itu, handler tidak boleh menganggap setiap request sebagai transaksi baru.

Gunakan payment_reference atau event_id sebagai kunci idempotensi. Jika event yang sama datang dua kali, sistem memeriksa apakah event tersebut sudah diterapkan. Efek sampingnya harus terjadi satu kali: penjualan tidak ditambahkan dua kali, dan pembaruan status hanya dilakukan jika event valid, belum diterapkan, serta tidak melanggar urutan atau transisi status yang diizinkan.

Sederhananya, tombol atau notifikasi yang sama tidak boleh menambah penjualan dua kali. Ini penting saat kasir menekan refresh, provider mengirim ulang webhook, atau jaringan membuat respons pertama terlihat gagal padahal server sudah memprosesnya.

Checklist teknis minimumnya:

• Verifikasi signature request sebelum memproses data.

• Simpan payload dan respons penting untuk debugging.

• Terapkan timeout agar proses tidak menggantung.

• Gunakan retry dengan batas percobaan dan jeda yang masuk akal.

• Pisahkan event yang gagal agar bisa diproses ulang tanpa mengulang transaksi sukses.

• Sediakan rekonsiliasi berkala sebagai pengaman ketika webhook tidak diterima.

Idempotency bukan jargon untuk dipajang di dokumen arsitektur. Ini kontrol desain untuk mencegah satu event menghasilkan dua pencatatan. Tetap uji aturan transisi statusnya; idempotensi saja tidak cukup jika event lama boleh menimpa status yang lebih baru.

Refund, pembatalan, dan hak akses

Jangan menghapus transaksi awal ketika pelanggan meminta refund. Simpan order awal sebagai fakta historis, lalu catat event pembalikannya.

Alurnya dapat dibuat seperti ini:

1. Kasir atau supervisor mengajukan refund dengan alasan.

2. Sistem memeriksa hak akses dan status order.

3. Permintaan dikirim ke kanal pembayaran.

4. Status refund dipantau sampai berhasil atau gagal.

5. POS memperbarui status order dan stok sesuai aturan bisnis.

6. Dashboard menampilkan refund sebagai pengecualian yang perlu dipantau.

Dengan cara ini, laporan tetap bisa membedakan omzet bruto, refund, biaya kanal, dan omzet bersih. Owner juga bisa melihat siapa yang menyetujui refund dan kapan prosesnya dilakukan.

Tidak semua pengguna perlu punya hak yang sama. Kasir dapat membuat order dan melihat status pembayaran. Supervisor dapat menyetujui pembatalan dalam batas tertentu. Admin keuangan dapat menjalankan rekonsiliasi dan ekspor laporan. Owner dapat melihat ringkasan serta riwayat perubahan.

Audit log setidaknya menyimpan siapa yang melakukan perubahan, kapan perubahan terjadi, status sebelum dan sesudah, alasan, serta payment_reference. Kalau ada selisih, tim tidak perlu menebak-nebak dari ingatan.

Dashboard Rekonsiliasi yang Berguna untuk Owner dan Admin

Tampilkan pengecualian sebelum total

Dashboard yang hanya menampilkan total penjualan terlihat rapi, tetapi belum tentu membantu. Panel pertama sebaiknya menunjukkan hal-hal yang membutuhkan tindakan:

• transaksi yang belum cocok dengan order POS;

• nominal tagihan dan nominal pembayaran yang berbeda;

• pembayaran pending terlalu lama;

• refund yang masih terbuka;

• settlement provider yang belum cocok dengan mutasi rekening;

• transaksi yang terindikasi duplikat.

Setelah itu, barulah tampilkan total omzet dan tren harian. Prinsipnya sederhana: dashboard harus membantu orang menemukan masalah, bukan sekadar mengagumi grafik.

Photo by Stephen Dawson on Unsplash.

Filter yang menjawab pertanyaan bisnis

Admin perlu dapat memfilter berdasarkan rentang tanggal, cabang, kasir, kanal pembayaran, status, rentang nominal, dan payment_reference. Dari kartu contoh “12 transaksi belum cocok”, pengguna harus bisa masuk ke daftar transaksi, melihat detail order, lalu membuka bukti pembayaran atau riwayat event.

Jangan paksa admin mencari dengan mengunduh banyak file CSV lalu menggabungkannya secara manual. Ekspor tetap berguna, terutama untuk kebutuhan akuntansi, tetapi pencarian transaksi nyangkut sebaiknya tersedia di aplikasi.

Laporan omzet setelah biaya kanal

Pisahkan lima komponen utama: omzet bruto, refund, biaya kanal, nominal dana settlement provider, dan omzet bersih. Buat juga laporan transaksi sampai dengan Rp100.000 agar dampak MDR QRIS 0% bisa dinilai berdasarkan kondisi bisnis sendiri.

Laporan itu tidak perlu langsung menjadi modul keuangan yang besar. Yang penting definisinya konsisten. Misalnya, “omzet bersih” harus jelas apakah dihitung setelah refund saja atau juga setelah biaya kanal lain. Kejelasan definisi lebih bernilai daripada grafik tiga dimensi.

UX Kasir: Mencegah Pembayaran Ganda dan Salah Konfirmasi

Rancangan layar untuk empat status dan satu pengecualian

Layar kasir perlu mengelola setidaknya empat status—menunggu, berhasil, gagal, dan kedaluwarsa—serta satu kondisi pengecualian: pembayaran berhasil tetapi notifikasi belum diterima.

Untuk status menunggu, tampilkan timer dan tombol cek status. Untuk berhasil, tampilkan nomor order dan instruksi proses pesanan. Untuk gagal atau kedaluwarsa, tawarkan pilihan membuat pembayaran baru. Untuk notifikasi terlambat, sediakan pemeriksaan status berdasarkan order atau payment_reference sebelum kasir meminta pembayaran ulang.

Microcopy yang membantu keputusan

Kalimat pendek dapat mencegah kesalahan mahal. Contohnya:

“Cek status pembayaran sebelum meminta pelanggan membayar lagi.”

Jangan mengandalkan warna hijau dan merah saja. Gunakan label, ikon, waktu pembaruan terakhir, dan instruksi yang jelas. Kasir seharusnya tidak perlu menerka arti ikon ketika antrean pelanggan sedang panjang.

Edge case di toko dan koneksi tidak stabil

Uji kondisi ketika koneksi terputus, pelanggan menutup aplikasi, perangkat kasir berganti, atau pembayaran masuk saat layar masih menunjukkan pending. Aplikasi perlu melakukan sinkronisasi ulang dan menyediakan tombol refresh yang aman, bukan membuat order baru setiap kali layar ditekan.

Kalau pembayaran sudah terkonfirmasi tetapi perangkat kehilangan koneksi, order tetap harus bisa ditemukan setelah koneksi kembali. Ini alasan lain mengapa order_id dan payment_reference harus dibuat sejak awal.

Blueprint MVP Software Integrasi QRIS untuk UMKM

Fitur fase pertama

MVP yang sehat tidak harus besar. Untuk kebutuhan inti, prioritaskan:

1. POS order service untuk membuat dan menyimpan order.

2. Payment adapter agar koneksi ke penyedia pembayaran tidak tersebar di banyak layar.

3. Webhook handler dengan verifikasi dan idempotency.

4. Status transaksi yang terpisah dari status settlement provider dan penerimaan dana di rekening.

5. Rekonsiliasi harian dan daftar pengecualian.

6. Ekspor CSV untuk tim keuangan.

7. Audit log dan kontrol akses berbasis peran.

8. Notifikasi untuk transaksi pending, duplikat, refund terbuka, atau settlement yang belum cocok.

Fitur ini langsung menyasar pekerjaan manual dan risiko laporan. Ini rekomendasi scope, bukan rancangan wajib dari Bank Indonesia. Mulai dari data order, pembayaran, refund, settlement provider, dan mutasi rekening yang memang dipakai dalam proses bisnis.

Fitur yang ditunda agar tidak over-engineering

Loyalty, prediksi penjualan, orkestrasi banyak kanal, dan dashboard eksekutif kompleks boleh masuk backlog. Jangan membangun semuanya sebelum data transaksi dasar konsisten.

Untuk UMKM dengan satu cabang, prioritasnya jelas: tunda dashboard eksekutif dan bereskan status pending, refund, serta rekonsiliasi lebih dulu. Fitur lebih sedikit berarti kebutuhan bisnis tertentu belum terlayani, tetapi tim bisa menguji alur utama dengan lebih cepat. Untuk banyak UMKM, sistem sederhana yang mencatat transaksi dengan benar dapat lebih sesuai daripada platform besar yang sulit dipakai kasir.

Kalau volume transaksi masih kecil dan settlement dapat diperiksa sekali sehari, spreadsheet belum tentu perlu diganti minggu ini. Batasnya muncul ketika spreadsheet dipaksa menjadi database transaksi, sistem approval, log audit, dan dashboard real-time sekaligus.

Build versus buy

Gunakan provider pembayaran dan POS yang sudah memenuhi kebutuhan dasar jika alurnya cocok dengan proses bisnis. Pertimbangkan software custom untuk bisnis ketika kamu membutuhkan multi-cabang, integrasi ERP, aturan refund khusus, atau laporan yang tidak tersedia di SaaS.

Keputusan ini dimulai dari gap proses, bukan dari daftar teknologi. Tulis dulu pekerjaan yang masih dilakukan manual, frekuensi selisih, dan data yang tidak bisa ditelusuri. Baru setelah itu bandingkan biaya langganan, biaya integrasi, fleksibilitas, serta dukungan pascapeluncuran.

Roadmap Implementasi 14 Hari Menjelang 1 Oktober 2026

Hari 1–3: audit proses dan data

Ikuti satu transaksi dari pelanggan memesan sampai dana terlihat di rekening. Catat siapa yang membuat order, siapa yang mengonfirmasi pembayaran, bagaimana refund diproses, kapan provider menandai settlement selesai, dan di mana mutasi rekening dicatat.

Kumpulkan sampel transaksi normal dan bermasalah. Jangan hanya mengambil transaksi yang sukses karena sistem justru diuji oleh kondisi pengecualian.

Hari 4–7: integrasi dan status transaksi

Implementasikan mapping order_id, payment_reference, webhook, idempotency, dan log untuk transaksi gagal atau duplikat. Pastikan POS tidak menambah penjualan hanya karena menerima request kedua untuk event yang sama. Pastikan juga event lama tidak menimpa status yang lebih baru.

Hari 8–10: dashboard dan rekonsiliasi

Uji pencocokan otomatis memakai sampel transaksi nyata. Buat daftar pengecualian untuk nominal berbeda, status pending, refund, settlement provider yang belum cocok dengan rekening, dan payment_reference yang tidak ditemukan. Tetapkan siapa yang bertugas menyelesaikan setiap jenis masalah.

Hari 11–14: uji skenario dan pelatihan kasir

Simulasikan pembayaran berhasil, timeout, refund, nominal berbeda, webhook ganda, dan settlement terlambat. Latih kasir menggunakan microcopy dan tindakan pemulihan yang sama dengan kondisi produksi.

SOP harus menjawab satu pertanyaan penting: apa yang dilakukan kasir ketika pelanggan mengaku sudah membayar, tetapi layar masih pending? Jawabannya bukan otomatis meminta pembayaran kedua. Periksa status transaksi lebih dulu. Kembali ke adegan antrean tadi: keputusan kasir menjadi lebih aman karena sistem menyediakan jalur pemeriksaan, bukan sekadar tombol “ulang bayar”.

Kapan UMKM Perlu Meminta Bantuan Pengembangan Software?

Sinyal spreadsheet sudah melewati batas

Mulai evaluasi lebih serius ketika bisnis memiliki lebih dari satu kanal pembayaran, lebih dari satu kasir atau cabang, rekonsiliasi memakan waktu setiap hari, atau tidak ada jejak perubahan. Sinyal lainnya adalah owner baru mengetahui selisih saat tutup buku dan admin harus membuka banyak file untuk menemukan penyebabnya.

Spreadsheet bukan musuh. Ia cocok untuk analisis ringan dan prototipe proses. Masalah muncul ketika spreadsheet dipaksa menjadi database transaksi, sistem approval, log audit, dan dashboard real-time sekaligus.

Scope yang bisa dibawa ke vendor

Saat berbicara dengan vendor, minta pembahasan yang konkret: integrasi POS dan pembayaran, rancangan UI kasir, status transaksi, dashboard rekonsiliasi, audit log, keamanan akses, backup, serta dukungan pascapeluncuran.

Tanyakan juga bagaimana sistem menangani webhook ganda, pembayaran terlambat, refund parsial, perubahan perangkat, dan kegagalan koneksi. Jawaban terhadap edge case lebih informatif daripada demo layar yang hanya menampilkan transaksi sukses.

Ukur hasil dengan metrik operasional

Sebelum implementasi, catat baseline. Setelah implementasi, ukur waktu rekonsiliasi harian, jumlah transaksi tidak cocok, jumlah duplikasi, umur transaksi pending, waktu penyelesaian refund, dan selisih laporan.

Dengan metrik itu, kamu bisa menilai apakah software benar-benar mengurangi pekerjaan atau hanya memindahkan pekerjaan manual ke layar baru.

Kesimpulan: Manfaat MDR QRIS 0% Harus Terlihat di Data, Bukan Hanya di Tarif

MDR QRIS 0% untuk transaksi sampai dengan Rp100.000 dijadwalkan mulai berlaku pada 1 Oktober 2026 ^[1]. Pada Juli 2026, Bank Indonesia mencatat pertumbuhan tahunan volume pembayaran digital sebesar 28,69% dan pertumbuhan volume transaksi QRIS sebesar 82,42%. Laporan triwulan II 2026 juga mencatat pertumbuhan tahunan transaksi QRIS sebesar 100,12% 1. Angka-angka itu menunjukkan pertumbuhan pada periode yang dilaporkan, bukan jaminan bahwa trennya akan terus naik tanpa jeda.

Kunci integrasi QRIS dengan kasir ada pada alur yang bisa ditelusuri: order_id, nominal, status pembayaran, refund, settlement provider, mutasi rekening, dan catatan POS. Webhook yang aman, idempotency, audit log, dashboard pengecualian, serta UX kasir yang jelas membantu tim mengurangi duplikasi dan salah konfirmasi.

Mulai dari MVP yang menjawab masalah inti. Hitung transaksi sampai dengan Rp100.000, refund, biaya kanal yang masih ada, nominal dana settlement, dan omzet bersih. Kalau pelanggan kembali berkata, “Saya sudah bayar,” tim seharusnya punya cara memeriksa status tanpa mengandalkan ingatan kasir atau membuka lima file berbeda.

Bawa sampel transaksi sukses, pending, refund, dan settlement-mu. Satmaxt Developer dapat membantu memetakan mana yang perlu diintegrasikan lebih dulu melalui konsultasi kebutuhan POS dan dashboard rekonsiliasi, lalu menyusun software custom sesuai scope yang realistis.

Sumber

^[1] Bank Indonesia — Memperkuat Stabilitas, Mendorong Pertumbuhan Ekonomi

^[2] Bank Indonesia — Laporan Kebijakan Moneter Triwulan II 2026