Gemini 3.6 Flash có thể phác thảo màn hình thanh toán trong vài giây. Những điều gì cần phải chính xác trước khi nhận thanh toán thật?

Tốc độ chưa bao giờ là mảnh ghép còn thiếu. Trước khi bất kỳ quy trình thanh toán nào do AI tạo ra thực hiện tính phí thực tế, 5 yếu tố sau phải hoàn toàn chính xác: quản lý tồn kho chịu được khi hai quầy bán cùng lúc, báo cáo đối soát (khớp với số tiền thực tế luân chuyển), tính thuế đúng với cơ quan tài chính địa phương, xử lý thanh toán tuân thủ PCI, và phần cứng thanh toán trực tiếp đã được chứng nhận. Gemini 3.6 Flash giúp việc tạo bản phác thảo đầu tiên cho màn hình thanh toán nhanh hơn và rẻ hơn bao giờ hết. Nhưng nó không làm thay đổi bất kỳ điều gì trong 5 yếu tố còn lại. Một bản mẫu Gemini 3.6 Flash POS là một khởi đầu tuyệt vời; nhưng một hệ thống điểm bán hàng có thể triển khai thực tế lại là một vạch đích hoàn toàn khác.

Tên mô hình, giá cả và điểm chuẩn kiểm thử thay đổi rất nhanh. Các thông tin chi tiết dưới đây chính xác tại thời điểm xuất bản; hãy xem đây là thông tin tham khảo tại một thời điểm.

Gemini 3.6 Flash thực sự đã thay đổi điều gì?

Nó giúp việc tạo mã nhanh và rẻ trở nên rẻ hơn và chính xác hơn nữa. Google đã phát hành Gemini 3.6 Flash vào ngày 21 tháng 7 năm 2026, cùng với Gemini 3.5 Flash-Lite¹. Mô hình này có giá $1,50 cho mỗi triệu token đầu vào và $7,50 cho mỗi triệu token đầu ra, sử dụng ít hơn khoảng 17% token đầu ra so với phiên bản tiền nhiệm và ghi nhận mức tăng vượt bậc về độ chính xác khi lập trình, đạt 49% trên bài kiểm thử DeepSWE so với 37% của 3.5 Flash².

Đối với một nhà bán hàng đang thử nghiệm các công cụ xây dựng bằng AI, điều đó mang lại một lợi ích cụ thể: việc phác thảo màn hình thanh toán giờ đây chỉ mất vài giây và tốn vài xu. Việc chỉnh sửa lặp lại cũng chỉ tốn vài xu. Điểm nghẽn trong việc sở hữu một điểm bán hàng tùy chỉnh đã dịch chuyển. Nó không còn là việc liệu mô hình có thể tạo ra các màn hình hay không. Nó nằm ở tất cả những gì vận hành phía sau các màn hình đó.

Tại sao màn hình thanh toán không phải là một điểm bán hàng?

Bởi vì màn hình thanh toán là đầu ra (output), còn điểm bán hàng là hệ thống lưu trữ dữ liệu gốc (system of record - nơi duy nhất mà các con số doanh số của bạn được coi là chuẩn xác). Màn hình chỉ là 10% bề nổi có thể nhìn thấy. Phía bên dưới là trạng thái hệ thống phải luôn chính xác trên mọi quầy bán, mọi khoản hoàn tiền và mọi sự cố mạng, cộng với luồng di chuyển của tiền tệ vốn bị quản lý chặt chẽ dù mã nguồn được viết tay hay do AI tạo ra. Chúng tôi đã phân tích sự khác biệt này khi GPT-5.6 ra mắt, và điều đó vẫn đúng với mọi mô hình tốc độ cao kể từ đó.

Phản biện dễ thấy là: các mô hình này giờ đây có thể viết mã nguồn đạt chuẩn vận hành (production-grade), vậy tại sao không để Gemini 3.6 Flash viết luôn logic tồn kho và thuế? Nó có thể làm được. Sự cố không nằm ở việc viết mã. Sự cố nằm ở việc chứng minh đoạn mã đó chính xác trong các điều kiện mà bạn không bao giờ thấy trong một bản thử nghiệm (demo), và nhận ra khi nó âm thầm hoạt động sai. Một màn hình thanh toán hiển thị sai sẽ bị phát hiện trong vài giây. Một sổ cái bị lệch số liệu chỉ được phát hiện vào cuối tháng bởi kế toán của bạn, và cho đến lúc đó, mọi báo cáo trông vẫn rất ổn.

Những gì cần phải chính xác trước khi thực hiện khoản tính phí thật đầu tiên?

Năm yếu tố, và không có yếu tố nào xuất hiện trong cửa sổ xem trước.

Quản lý tồn kho chịu được truy cập đồng thời

Truy cập đồng thời (hai quầy thanh toán cùng truy cập vào một mặt hàng tồn kho tại cùng một thời điểm) là nơi mà mã nguồn tồn kho do AI tạo ra thất bại đầu tiên. Hai quầy cùng bán sản phẩm cuối cùng trong cùng một giây. Đoạn mã đơn giản kiểm tra số lượng, thấy còn một sản phẩm và cho phép cả hai giao dịch thành công. Bây giờ bạn đã bán một thứ mà mình không có, và lỗi này sẽ âm thầm nhân lên sau mỗi giờ cao điểm. Một hệ thống chuẩn xác sẽ tuần tự hóa các thao tác ghi đó để một giao dịch thành công và giao dịch còn lại sẽ thấy kệ hàng trống. Đó là hành vi thuộc về hạ tầng, không phải hành vi của màn hình, và không bản xem trước nào hiển thị được điều đó.

Báo cáo đối soát chính xác

Rủi ro đối soát (báo cáo của bạn khớp với số tiền thực tế đã di chuyển) thường xảy ra ở các trường hợp ngoại lệ: khoản hoàn tiền được thực hiện sau khi đóng phiên làm việc, lệnh hủy giao dịch sau khi đã kiểm đếm tiền trong ngăn kéo, hoàn tiền một phần cho sản phẩm đang giảm giá, giao dịch thanh toán được thử lại sau khi rớt mạng. Mỗi trường hợp ngoại lệ mà báo cáo do AI tạo ra bỏ sót là một lỗ hổng nhỏ giữa những gì báo cáo ghi nhận và những gì ngân hàng đã gửi vào tài khoản. Nhà bán hàng không phát hiện ra những lỗ hổng này khi thử nghiệm. Họ chỉ phát hiện ra chúng khi đến kỳ quyết toán thuế.

Tính thuế đúng theo quy định pháp lý

Thuế doanh thu có tính chất xếp chồng: thuế quốc gia chồng lên thuế địa phương, miễn thuế theo từng loại sản phẩm, mức thuế thay đổi theo ngày do cơ quan lập pháp quy định chứ không theo lịch phát hành phần mềm của bạn. Tính sai thuế không phải là một lỗi phần mềm đơn thuần, đó là trách nhiệm pháp lý. Một hệ thống thực tế cấu hình thuế một lần và áp dụng nhất quán ở mọi nơi, giống như cách các nhóm thuế hoạt động trong Merchant Hub.

Xử lý thanh toán tuân thủ chuẩn PCI

PCI DSS (tiêu chuẩn an ninh của ngành thẻ thanh toán) tồn tại để dữ liệu thẻ chỉ được xử lý bởi các hệ thống đã qua kiểm toán. Mã nguồn do AI tạo ra không bao giờ được phép tiếp xúc với số thẻ. Trong thực tế, điều đó có nghĩa là các khoản thanh toán được chạy qua hạ tầng đã được chứng nhận của đơn vị xử lý thanh toán, với dữ liệu thẻ được mã hóa thành token (thay thế bằng một token đại diện) trước khi phần mềm của bạn chạm vào bất kỳ dữ liệu nào. Đây là điều khoản bắt buộc nhất trong danh sách và nó nằm hoàn toàn ngoài những gì bất kỳ mô hình AI nào có thể tạo ra.

Phần cứng thanh toán trực tiếp đã qua chứng nhận

Thanh toán chạm và thẻ chip chỉ hoạt động trên các thiết bị chấp nhận thanh toán đã được các mạng lưới thẻ chứng nhận, và chứng nhận này đạt được cho từng thiết bị thông qua kiểm thử trong phòng thí nghiệm. Nó không thể được tạo tự động, tạo bằng câu lệnh hay vá lỗi sau đó. Nếu khách hàng của bạn thanh toán trực tiếp, một thiết bị thanh toán đã được chứng nhận phải nằm giữa thẻ của họ và đoạn mã của bạn.

Một mô hình tốc độ cao thực sự giúp ích ở đâu?

Chính xác ở những gì phiên bản này tập trung vào: mô tả, phác thảo và chỉnh sửa lặp lại. Một mô hình giá rẻ, tốc độ cao là công cụ phù hợp để định hình màn hình và logic quy trình, thử 5 bố cục trước giờ ăn trưa và hoàn thiện quy trình thanh toán cho đến khi nó phù hợp với cách quầy hàng của bạn thực tế vận hành. Mô hình hoạt động hiệu quả là để AI làm điều đó trên nền tảng hạ tầng thương mại đã làm chủ phần tồn kho, đối soát, thuế và thanh toán.

Đó là cách Build của Final xử lý các mô hình: bạn có thể kết nối Gemini hoặc bất kỳ MCP client nào và để nó xây dựng quy trình của bạn với bản xem trước trực tiếp, trong khi Final Pay xử lý thanh toán thông qua đơn vị xử lý thanh toán và phần cứng thiết bị đã qua chứng nhận ở bên dưới. Để xem hướng dẫn từng bước, hãy xem cách xây dựng với Gemini 3.6 Flash, hoặc so sánh ba mô hình lớn nhất khi xây dựng POS.

Vậy, những gì cần phải chính xác trước khi Gemini 3.6 Flash nhận một khoản thanh toán thật?

Quản lý tồn kho khi truy cập đồng thời, báo cáo đối soát, tính thuế phù hợp với quy định địa phương, xử lý thanh toán tuân thủ PCI, và phần cứng đã qua chứng nhận. Gemini 3.6 Flash vừa biến màn hình thanh toán thành phần rẻ nhất của dự án, và nó không can thiệp vào bất kỳ điều nào trong danh sách trên. Quy tắc nằm lòng: nếu một sự cố xuất hiện trong tài khoản ngân hàng thay vì trên màn hình của bạn, đừng để mã do AI tạo ra tự chịu trách nhiệm một mình. Hãy phác thảo với mô hình nhanh nhất bạn có, sau đó triển khai trên hạ tầng được xây dựng để có thể kiểm toán. Nếu bạn muốn thử mô hình kết hợp đó ngay hôm nay, hãy bắt đầu với Build.