Gemini 3.6 Flash Dapat Membuat Draf Tampilan Checkout dalam Hitungan Detik. Apa yang Harus Benar Sebelum Menerima Pembayaran Nyata?

Kecepatan bukanlah bagian yang hilang. Sebelum checkout yang dihasilkan AI menerima pembayaran langsung, lima hal harus benar: inventaris yang bertahan saat dua stasiun menjual secara bersamaan, laporan yang terrekonsiliasi (sesuai dengan uang yang benar-benar berpindah), pajak yang sesuai dengan yurisdiksi, penanganan pembayaran yang patuh pada PCI, dan perangkat keras bersertifikat untuk transaksi langsung (card-present). Gemini 3.6 Flash membuat draf pertama tampilan checkout lebih cepat dan lebih murah dari sebelumnya. Namun, model tersebut tidak mengubah apa pun terkait lima hal lainnya. Prototip POS Gemini 3.6 Flash adalah awal yang baik; tetapi sistem POS yang siap digunakan adalah garis akhir yang berbeda.

Nama model, harga, dan tolok ukur berkembang sangat cepat. Rincian di bawah ini akurat pada saat publikasi; anggap saja sebagai gambaran saat ini.

Apa yang sebenarnya diubah oleh Gemini 3.6 Flash?

Hal ini membuat pembuatan kode yang cepat dan murah menjadi semakin murah dan lebih presisi. Google merilis Gemini 3.6 Flash pada 21 Juli 2026, bersamaan dengan Gemini 3.5 Flash-Lite¹. Biayanya $1,50 per juta token input dan $7,50 per juta token output, menggunakan sekitar 17 persen lebih sedikit token output daripada pendahulunya, dan mencatatkan peningkatan nyata dalam presisi pengodean, dengan skor 49 persen pada tolok ukur DeepSWE dibandingkan dengan 37 persen untuk 3.5 Flash².

Bagi pedagang yang bereksperimen dengan pembuat AI, hal itu terwujud dalam sesuatu yang konkret: membuat draf tampilan checkout kini hanya butuh beberapa detik dan biaya sangat murah. Melakukan iterasi padanya juga sangat murah. Kendala dalam mendapatkan sistem POS kustom telah bergeser. Masalahnya bukan lagi apakah model dapat menghasilkan tampilan tersebut, melainkan semua infrastruktur yang menjadi landasan tampilan itu.

Mengapa tampilan checkout bukanlah sebuah POS?

Karena tampilan checkout adalah output, sedangkan sistem POS adalah system of record (satu-satunya tempat di mana angka penjualan Anda dianggap akurat). Tampilan hanyalah sepuluh persen yang terlihat. Di baliknya terdapat state yang harus tetap benar di setiap stasiun, setiap pengembalian dana (refund), dan setiap gangguan jaringan, ditambah pergerakan uang yang diatur oleh regulasi baik kodenya ditulis manual maupun dihasilkan otomatis. Kami telah mengulas perbedaan yang sama ketika GPT-5.6 dirilis, dan hal itu tetap berlaku untuk setiap model cepat sejak saat itu.

Sanggahan yang umum muncul: model-model ini sudah bisa menulis kode siap produksi sekarang, jadi mengapa tidak membiarkan Gemini 3.6 Flash menulis logika inventaris dan pajak juga? Model tersebut memang bisa. Masalahnya bukan pada penulisan kode, melainkan membuktikan bahwa kode tersebut benar dalam kondisi yang tidak akan pernah Anda lihat dalam demo, serta menyadari ketika kode itu secara diam-diam keliru. Tampilan checkout yang keliru akan ketahuan dalam hitungan detik. Pembukuan (ledger) yang melenceng baru akan ketahuan di akhir bulan oleh akuntan Anda, dan sampai saat itu setiap laporan terlihat baik-baik saja.

Apa yang harus benar sebelum pembayaran nyata pertama?

Lima hal, dan tidak ada satu pun dari hal tersebut yang muncul di jendela pratinjau.

Inventaris yang bertahan saat konkurensi

Konkurensi (concurrency—dua kasir mengakses stok yang sama di saat yang persis bersamaan) adalah titik di mana kode inventaris buatan AI gagal pertama kali. Dua stasiun menjual unit terakhir dari suatu barang dalam detik yang sama. Kode yang sederhana akan memeriksa jumlahnya, melihat ada satu yang tersedia, lalu meloloskan kedua penjualan tersebut. Sekarang Anda telah menjual barang yang tidak Anda miliki, dan kesalahan ini bertambah secara diam-diam di setiap jam sibuk. Sistem yang benar akan menyelaraskan (serialize) proses penulisan tersebut sehingga satu penjualan berhasil dan yang lainnya melihat rak kosong. Itu adalah perilaku infrastruktur, bukan perilaku tampilan, dan tidak ada pratinjau yang akan memperlihatkannya.

Laporan yang terrekonsiliasi

Rekonsiliasi (laporan Anda yang sesuai dengan uang yang benar-benar berpindah) sering kali gagal pada kasus-kasus khusus (edge cases): pengembalian dana yang diterbitkan setelah sesi ditutup, pembatalan (void) setelah penghitungan laci kasir, pengembalian dana parsial untuk item berdiskon, atau pembayaran yang dicoba ulang setelah koneksi terputus. Setiap kasus khusus yang terlewatkan oleh laporan buatan AI adalah celah kecil antara apa yang tertera di laporan dan apa yang disetorkan oleh bank. Pedagang tidak menemukan celah ini saat pengujian, melainkan saat musim pajak.

Pajak yang sesuai dengan yurisdiksi

Pajak penjualan itu bertumpuk: tarif nasional di atas tarif regional, pembebasan pajak per produk, serta tarif yang berubah pada tanggal yang ditetapkan oleh undang-undang, bukan oleh jadwal rilis Anda. Melakukan kesalahan dalam hal ini bukan sekadar tiket bug, melainkan sebuah liabilitas hukum. Sistem yang nyata mengonfigurasi pajak sekali dan menerapkannya secara konsisten di mana saja, seperti cara kerja grup pajak di Merchant Hub.

Penanganan pembayaran yang memenuhi standar PCI

PCI DSS (standar keamanan industri kartu) ada agar data kartu hanya diolah oleh sistem yang diaudit. Kode buatan AI tidak boleh melihat nomor kartu sama sekali. Dalam praktiknya, ini berarti pembayaran dijalankan melalui sistem bersertifikat dari pemroses pembayaran, dengan data kartu yang ditokenisasi (ditukar dengan token pengganti) sebelum perangkat lunak Anda menyentuh apa pun. Ini adalah poin yang paling tidak bisa ditawar dalam daftar ini, dan sepenuhnya berada di luar apa yang dihasilkan oleh model mana pun.

Perangkat keras bersertifikat untuk transaksi langsung

Pembayaran tap dan chip hanya dapat berjalan di terminal yang telah disertifikasi oleh jaringan kartu, dan sertifikasi tersebut diperoleh per perangkat melalui pengujian laboratorium. Hal ini tidak dapat dihasilkan, di-prompt, atau ditambahkan belakangan. Jika pelanggan Anda membayar secara langsung, terminal bersertifikat harus berada di antara kartu mereka dan kode Anda.

Di mana model yang cepat benar-benar membantu?

Tepat di mana rilis ini memfokuskan keunggulannya: mendeskripsikan, membuat draf, dan melakukan iterasi. Model yang murah dan cepat adalah alat yang tepat untuk membentuk alur logika dan tampilan layar, mencoba lima tata letak sebelum makan siang, dan menyempurnakan checkout hingga sesuai dengan alur kerja kasir Anda. Pembagian kerja yang efektif adalah membiarkan model melakukan hal tersebut di atas infrastruktur perdagangan yang sudah mengelola inventaris, rekonsiliasi, pajak, dan pembayaran.

Begitulah cara Build dari Final memperlakukan model AI: Anda dapat menghubungkan Gemini atau klien MCP apa pun dan membiarkannya membangun alur Anda dengan pratinjau langsung, sementara Final Pay menyelesaikan pembayaran melalui pemroses pembayaran dan perangkat keras terminal bersertifikat di baliknya. Untuk panduan langkah demi langkah, lihat cara membangun dengan Gemini 3.6 Flash, atau perbandingan tiga model besar untuk pembuatan POS.

Jadi, apa yang harus benar sebelum Gemini 3.6 Flash menerima pembayaran nyata?

Inventaris saat konkurensi, laporan yang terrekonsiliasi, pajak yang sesuai dengan yurisdiksi, penanganan pembayaran yang patuh pada PCI, dan perangkat keras bersertifikat. Gemini 3.6 Flash baru saja menjadikan tampilan checkout sebagai bagian termurah dari proyek, dan model ini tidak menyentuh satu pun hal dalam daftar tersebut. Aturan praktisnya: jika kegagalan berdampak pada rekening bank Anda, bukan pada layar Anda, jangan biarkan kode buatan AI mengelolanya sendiri. Buat draf dengan model tercepat yang bisa Anda dapatkan, lalu terapkan pada infrastruktur yang dirancang untuk diaudit. Jika Anda ingin mencoba pembagian kerja ini sekarang, mulailah dengan Build.