Gemini 3.6 Flash Saniyeler İçinde Bir Ödeme Ekranı Taslağı Oluşturabilir. Gerçek Bir Ödeme Almadan Önce Nelerin Doğru Olması Gerekir?

Hız hiçbir zaman eksik parça olmadı. Yapay zekayla oluşturulmuş herhangi bir ödeme ekranı canlı tahsilat almadan önce beş şeyin doğru olması gerekir: iki istasyon aynı anda satış yaparken dayanan stok, mutabakat sağlayan (fiilen hareket eden parayla eşleşen) raporlar, ilgili yargı alanına uygun vergi, PCI uyumlu ödeme yönetimi ve sertifikalı fiziki (card-present) donanım. Gemini 3.6 Flash, bir ödeme ekranının ilk taslağını hiç olmadığı kadar hızlı ve ucuz hale getiriyor. Ancak diğer beş şey hakkında hiçbir şeyi değiştirmiyor. Gemini 3.6 Flash POS prototipi gerçek bir avantajdır; yayına alınabilir bir satış noktası ise farklı bir bitiş çizgisidir.

Model isimleri, fiyatlar ve kıyaslamalar hızlı değişir. Aşağıdaki ayrıntılar yayın tarihi itibarıyla doğrudur; bunları bir anlık görüntü olarak değerlendirin.

Gemini 3.6 Flash gerçekte neyi değiştirdi?

Hızlı ve ucuz kod üretimini daha da ucuz ve hassas hale getirdi. Google, Gemini 3.6 Flash'ı 21 Temmuz 2026'da Gemini 3.5 Flash-Lite ile birlikte sundu¹. Milyon girdi token'ı başına 1,50 $ ve milyon çıktı token'ı başına 7,50 $ maliyete sahip olan model, selefine kıyasla yaklaşık yüzde 17 daha az çıktı token'ı kullanıyor ve DeepSWE kıyaslamasında 3,5 Flash'ın yüzde 37'lik puanına karşılık yüzde 49 alarak kodlama hassasiyetinde gerçek bir sıçrama sergiliyor².

Yapay zeka araçlarıyla deney yapan bir üye iş yeri için bu, somut bir anlama geliyor: Bir ödeme ekranı taslağı oluşturmak artık saniyeler sürüyor ve kuruşlara mal oluyor. Üzerinde yinelemeler yapmak da kuruşlara mal oluyor. Özel bir satış noktasına ulaşmadaki darboğaz yer değiştirdi. Artık sorun modelin ekranları üretip üretememesi değil. Sorun, ekranların üzerinde durduğu her şey.

Bir ödeme ekranı neden bir POS değildir?

Çünkü ödeme ekranı bir çıktıdır, POS ise bir kayıt sistemidir (satış rakamlarınızın doğru kabul edildiği tek yer). Ekran, görünen yüzde onluk kısımdır. Altında ise her istasyonda, her iade işleminde ve her ağ aksaklığında doğru kalması gereken bir durum (state) ve kod ister elle yazılmış ister üretilmiş olsun düzenlemelere tabi tutulan bir para hareketi yatar. GPT-5.6 çıktığında da aynı ayrımı ele almıştık ve bu durum o zamandan beri her hızlı model için geçerliliğini korudu.

Açıkça gelebilecek itiraz şu: Bu modeller artık üretim kalitesinde kod yazıyor, öyleyse neden Gemini 3.6 Flash'ın stok ve vergi mantığını da yazmasına izin vermeyelim? Yazabilir. Sorun kodu yazmak değil. Sorun, bir demoda asla göremeyeceğiniz koşullar altında bu kodun doğruluğunu kanıtlamak ve sessizce hatalı çalıştığında bunu fark etmektir. Yanlış oluşturulmuş bir ödeme ekranı saniyeler içinde yakalanır. Sapan bir muhasebe defteri ise ay sonunda muhasebeciniz tarafından fark edilir ve o zamana kadar her rapor sorunsuz görünür.

İlk gerçek tahsilattan önce nelerin doğru olması gerekir?

Beş şey; ve bunların hiçbiri bir önizleme penceresinde görünmez.

Eşzamanlılığa dayanan stok

Eşzamanlılık (iki ödeme noktasının aynı anda aynı stoğa erişmesi), üretilen stok kodunun ilk başarısız olduğu yerdir. İki istasyon bir ürünün son adetini aynı saniyede satar. İlkel bir kod adede bakar, bir tane mevcut olduğunu görür ve her iki satışa da izin verir. Artık elinizde olmayan bir şeyi satmış olursunuz ve bu hata her yoğun saatte sessizce katlanır. Doğru bir sistem bu yazma işlemlerini sıralar, böylece bir satış kazanır ve diğeri boş bir raf görür. Bu, ekran davranışı değil altyapı davranışıdır ve hiçbir önizleme bunu gösteremez.

Mutabakat sağlayan raporlar

Mutabakat (raporlarınızın fiilen hareket eden parayla eşleşmesi) uç durumlarda bozulur: oturum kapandıktan sonra yapılan bir iade, kasa sayımından sonraki bir iptal, indirimli bir kaleme uygulanan kısmi iade, ağ kesintisinden sonra yeniden denenen bir ödeme. Üretilen bir raporun gözden kaçırdığı her bir uç durum, raporun söylediği ile bankanın yatırdığı miktar arasında küçük bir deliktir. Üye iş yerleri bu delikleri test ederken keşfetmezler. Bunları vergi zamanı keşfederler.

Yargı alanıyla eşleşen vergi

Satış vergisi katmanlıdır: bölgesel oranın üzerine eklenen ulusal bir oran, ürün bazlı muafiyetler, sürüm takviminiz yerine yasama organının belirlediği bir tarihte değişen oranlar. Yanlış yapmak basit bir yazılım hatası değil, bir yükümlülüktür. Gerçek bir sistem vergileri bir kez yapılandırır ve Merchant Hub'daki vergi grupları gibi her yerde tutarlı bir şekilde uygular.

PCI standartlarını karşılayan ödeme yönetimi

PCI DSS (kart sektörünün güvenlik standardı), kart verilerinin yalnızca denetlenen sistemler tarafından işlenmesini sağlamak için vardır. Üretilen kod asla bir kart numarası görmemelidir. Pratikte bu, ödemelerin bir ödeme kuruluşunun sertifikalı altyapısı üzerinden çalışması ve yazılımınız herhangi bir şeye dokunmadan önce kart verilerinin belirteçleştirilmesi (geçici bir token ile değiştirilmesi) anlamına gelir. Bu, listedeki en az pazarlık edilebilir maddedir ve herhangi bir modelin ürettiği çıktının tamamen dışındadır.

Sertifikalı kartlı (card-present) donanım

Temassız ve çipli ödemeler yalnızca kart ağları tarafından sertifikalandırılmış terminallerde çalışır ve sertifikasyon laboratuvar testleriyle cihaz bazında kazanılır. Kodla üretilemez, komutla oluşturulamaz veya sonradan eklenemez. Müşterileriniz yüz yüze ödeme yapıyorsa, kartları ile kodunuz arasında sertifikalı bir terminal durmalıdır.

Hızlı bir model gerçekte nerede işe yarar?

Aynen bu sürümün odaklandığı yerde: tanımlama, taslak oluşturma ve yineleme yapma. Ucuz ve hızlı bir model; ekranları ve akış mantığını şekillendirmek, öğleden önce beş farklı yerleşim denemek ve ödeme akışını tezgahınızın gerçek çalışma şekline uyana kadar geliştirmek için doğru araçtır. İşe yarayan yaklaşım, modelin bu işlemleri zaten stok, mutabakat, vergi ve ödemelere sahip olan bir ticaret altyapısı üzerinde yapmasına izin vermektir.

Final'ın Build özelliği modelleri tam olarak bu şekilde ele alır: Gemini veya herhangi bir MCP istemcisini bağlayabilir ve alt tarafta Final Pay ödemeleri bir ödeme kuruluşu ve sertifikalı terminal donanımı aracılığıyla çözerken modelin canlı önizlemeyle akışınızı oluşturmasına izin verebilirsiniz. Adım adım kılavuz için Gemini 3.6 Flash ile nasıl geliştirme yapılır veya üç büyük modelin POS geliştirmede nasıl karşılaştırıldığı yazılarımıza göz atın.

Peki, Gemini 3.6 Flash gerçek bir ödeme almadan önce nelerin doğru olması gerekir?

Eşzamanlılık altında stok, mutabakat sağlayan raporlar, yargı alanıyla eşleşen vergi, PCI uyumlu ödeme yönetimi ve sertifikalı donanım. Gemini 3.6 Flash ödeme ekranını projenin en ucuz parçası haline getirdi ancak bu listedeki hiçbir şeye dokunmadı. Genel kural: Bir hata ekranınız yerine banka hesabınızda görünecekse, bunun tek sahibinin üretilen kod olmasına izin vermeyin. Alabileceğiniz en hızlı modelle taslak oluşturun, ardından denetlenmek üzere inşa edilmiş altyapı üzerinde yayına alın. Bu ayrımı bugün denemek istiyorsanız Build ile başlayın.