Integrasi Mobile•E-Wallet

Bayar E-Wallet dari Native

Native memilih e-wallet, nominal, dan melakukan inquiry di UI-nya sendiri. WebView /payment/ewallet hanya meminta PIN lalu mengeksekusi top up. Ada dua cara top up e-wallet; pilih sesuai kebutuhan.

1. Pilih Cara Top Up

Cara	Rute WebView	Pembagian kerja
A. Full WebView	/qoincash/ewallet	WebView mengerjakan semuanya: pilih e-wallet, nomor HP, nominal, inquiry, PIN, dan pembayaran.
B. Native + PIN di WebView (halaman ini)	/payment/ewallet	Native memakai GETWALLETLIST, GETWALLETDENOM, GETWALLETINQUIRY. WebView hanya PIN dan pembayaran.

2. Alur Cara B

Native memanggil GETWALLETLIST lalu GETWALLETDENOM (walletType = pGroup) untuk menampilkan pilihan ke user.
Native memanggil GETWALLETINQUIRY dengan phoneNumber dan code (pCode). Balasannya memuat rincian dan inquiryToken.
Native membuka WebView (terlihat) ke {BASE_URL}/payment/ewallet.
Native mengirim inquiryToken lewat postMessage (kirim ulang tiap ±500 ms, maksimal ±15 detik).
WebView mengambil rincian dari token itu, menampilkan ringkasan (produk, nomor, nama, nominal, biaya admin, total, saldo), lalu layar PIN. User mengetik PIN di dalam WebView.
WebView mengeksekusi pembayaran dan mengirim hasilnya ke native.

Pesan ke /payment/ewallet (tanpa type, bukan query URL)

// inquiryToken = data.inquiryToken dari balasan GETWALLETINQUIRY
window.postMessage(JSON.stringify({ inquiryToken: "<token>" }), "*");

Kamus Parameter Pesan

Parameter	Tipe Data	Status	Deskripsi & Contoh
inquiryToken	string	Wajib	Token tersegel dari balasan GETWALLETINQUIRY (data.inquiryToken). Teruskan apa adanya sebagai string token buram (opaque). Terikat ke akun user dan berlaku singkat (±5 menit). Contoh: `<string token buram (opaque)>`

Hanya token yang dikirim

Nominal, nama, produk, dan nomor tujuan tidak dikirim native ke halaman ini. Semuanya diambil server dari token yang sama dengan yang dipakai saat debit, sehingga angka di layar PIN selalu sama dengan yang didebit dan tidak bisa berbeda karena kesalahan atau manipulasi di sisi native.

Aturan penerimaan pesan

Pesan lain (misalnya {Signature, Palette}) diabaikan. Pesan pembayaran dipakai sekali; pesan berikutnya diabaikan. Token yang bentuknya salah, kedaluwarsa, atau tidak diterima dalam ±15 detik menampilkan layar Transaksi Gagal.

3. Hasil yang Diterima Native

Event dari WebView

Parameter	Tipe Data	Status	Deskripsi & Contoh
{ STATUS: "TRUE", FOR: "EWALLET" }	object	Opsional	Top up berhasil (status final). Lalu { close: true, STATUS: "TRUE", FOR: "EWALLET" } saat user menekan Selesai.
{ STATUS: "FALSE", FOR: "EWALLET", MESSAGE? }	object	Opsional	Gagal, termasuk gagal sebelum bayar (token tidak valid/kedaluwarsa, data tidak diterima), atau dikembalikan/dibatalkan oleh sistem. Lalu { close: true, STATUS: "FALSE", FOR: "EWALLET" }.
{ close: true, FOR: "EWALLET" }	object	Opsional	Tanpa STATUS: user menekan kembali sebelum membayar (dibatalkan), atau transaksi masih diproses. Jangan dicatat sebagai sukses atau gagal.

Saldo tidak cukup: tombol bayar dinonaktifkan, tidak ada order yang dibuat.
PIN salah atau terkunci: pembayaran tidak dikirim; user bisa mengulang PIN selama token masih berlaku.
Sesi habis saat membayar: WebView meminta PIN login lebih dulu. Setelah kembali, data pesan hilang, jadi native perlu mengirim ulang token.
Hasil diproses/tidak pasti: jangan mengulang pembayaran. WebView menampilkan "sedang diproses" dan membaca status; tanpa STATUS sampai final.
Setelah halaman di-refresh: token hanya di memori, sehingga alur harus dimulai lagi dari GETWALLETINQUIRY.

PIN tidak pernah lewat postMessage

PIN hanya diketik di dalam WebView dan dikirim langsung ke server QoinCash. Native tidak pernah menerima atau mengirim PIN.

Bayar QRIS dari Native SDK Flutter