Văn bản này chưa phải bản chính thức và nội dung có thể được sửa trước khi có hiệu lực. Còn 6 thông tin doanh nghiệp chưa được điền (in trong ngoặc vuông).
Việc chủ đầu tư và luật sư cần quyết trước khi công bố:
- Hạn mức nạp ví nhóm B và tiền nạp vượt hạn mức. Mã nguồn xếp mọi tài khoản hạng Đại lý vào nhóm B (hạn mức nạp cao hơn), trong khi đặc tả 7.3 chỉ cho nhóm B với Đại lý đã nộp và được duyệt giấy tờ định danh — mà Website chưa thu giấy tờ nào. Hạn mức hiện chỉ chặn lúc TẠO yêu cầu nạp: tiền chuyển tới mã của một lượt nạp được ghi có đủ vào ví, kể cả khi vượt số tiền đã chọn hay vượt hạn mức ngày, trong khi đặc tả 1.2 và 2.8 đòi phong tỏa phần vượt chờ Kế toán. Đây là quyết định phòng, chống rửa tiền. Văn bản hiện chỉ mô tả hạn mức như giới hạn của yêu cầu nạp, không như giới hạn số tiền được ghi có vào ví.
- Hoàn tiền về tài khoản ngân hàng. Đặc tả 3.4 giữ việc hoàn về tài khoản ngân hàng như một ngoại lệ có kiểm soát (1 người đề nghị, 2 Super Admin khác nhau cùng xác thực 2 lớp), nhưng hệ thống chưa có công cụ cho việc này. Văn bản đang viết: mặc định hoàn vào ví; hoàn về tài khoản ngân hàng là ngoại lệ do chúng tôi quyết định hoặc khi pháp luật bắt buộc. Luật sư chọn câu chữ cuối cùng.
- Tự sửa thông tin cá nhân và đổi email. Đặc tả 7.2 đòi khách tự sửa được thông tin cá nhân, nhưng hiện chưa có trang tự sửa họ tên, số điện thoại và chưa có chức năng đổi email. Văn bản ghi đúng hiện trạng: khách gửi yêu cầu qua bộ phận hỗ trợ. Có chức năng rồi thì sửa mục Quyền của bạn trong Chính sách bảo mật và mục Tài khoản trong Điều khoản sử dụng.
- Khoản tiền giữ riêng và đơn “Đang xem xét” đang xử lý tay. Chuyển thừa lớn, tiền không khớp đơn nào và đơn chuyển sang “Đang xem xét” vì tiền lệch đều chờ bộ phận kế toán, nhưng trang quản trị chưa có thao tác nhả khoản giữ riêng, khớp tiền vào đơn hay đóng đơn; việc đó hiện làm trực tiếp trên cơ sở dữ liệu. Văn bản chỉ hứa kế toán xử lý, không hứa thời hạn.
- Bản sao dữ liệu và ẩn danh hóa đang làm tay. Đặc tả 7.2 cho khách TỰ TẢI bản sao dữ liệu (mã thẻ chỉ hiện 4 số cuối) và đòi ẩn danh hóa trong 30 ngày khi khách yêu cầu xóa. Hệ thống chưa có chức năng tự tải bản sao, chưa có công cụ xuất dữ liệu cho nhân viên và chưa có công cụ ẩn danh hóa: bộ phận hỗ trợ và Super Admin làm tay theo quy trình apps/web/src/lib/legal/quyen-du-lieu.runbook.md (các câu SQL trong đó đã chạy thử trên cơ sở dữ liệu thật trong giao dịch quay lui). Nhân viên không có công cụ giải mã mã thẻ nên bản sao KHÔNG chứa mã thẻ, kể cả 4 ký tự cuối; khách tự xuất mã thẻ ở Kho thẻ đã mua. Văn bản viết: chúng tôi gửi bản sao qua email của tài khoản trong 72 giờ, không kèm mã thẻ; ẩn danh hóa trong 30 ngày, tài khoản không đăng nhập được nữa; tài khoản còn số dư ví chỉ ẩn danh hóa khi khách xác nhận bằng email bỏ số dư. Cần quyết: xây chức năng tự tải và công cụ ẩn danh hóa, hay giữ quy trình tay cùng câu chữ này; và câu về số dư ví bị bỏ khi xóa tài khoản.
- Thuế GTGT cạnh giá và hóa đơn đang làm tay. Đặc tả 7.1 đòi giá ghi rõ đã gồm hay chưa gồm thuế GTGT, khách nhập thông tin hóa đơn trong 24 giờ sau khi đặt, kế toán phát hành hóa đơn từ tệp dữ liệu xuất mỗi ngày, và đơn đã có số hóa đơn mà hoàn tiền phải báo kế toán trong 1 giờ. Hiện câu về thuế GTGT chỉ có trong Điều khoản sử dụng và Hỏi đáp, CHƯA hiện cạnh giá ở trang mua thẻ và trang thanh toán; không có biểu mẫu nhập thông tin hóa đơn (văn bản cho gửi qua email hỗ trợ trong 24 giờ); trang quản trị không có tệp xuất dữ liệu hóa đơn; đơn không có cột số hóa đơn nên việc báo kế toán khi hoàn tiền một đơn đã xuất hóa đơn không tự động. Văn bản chỉ hứa nhận thông tin qua email và điều chỉnh hóa đơn theo quy định. Cần quyết: câu thuế GTGT (ô vatStatement) và việc có xây biểu mẫu, tệp xuất hóa đơn hay không.
- Ngưỡng phòng, chống rửa tiền theo đơn và theo 24 giờ. Đặc tả 7.3 đòi hai mức cho mỗi đơn và cho tổng mua trong 24 giờ: mức kiểm sau (vẫn giao thẻ, mở hồ sơ nghi vấn, kế toán kết luận trong 24 giờ) và mức chặn (giữ đơn, không cấp thẻ) — nhóm A bị chặn từ 200.000.000đ một đơn hoặc 500.000.000đ trong 24 giờ. Hệ thống chưa có ngưỡng nào trong hai loại đó: luồng mua thẻ không có phép kiểm, không có hồ sơ nghi vấn (chỉ luồng nạp ví có hạn mức). Từ 06/10/2026 lưới chỉ còn mệnh giá lớn nhất 1.000.000đ nên một đơn 50 thẻ tối đa 50.000.000đ, không còn chạm mức 200.000.000đ một đơn; tổng mua trong 24 giờ thì nhiều đơn vẫn chạm được mức 500.000.000đ. Văn bản đang viết đúng hiện trạng: thẻ được cấp tự động ngay khi tiền về (Chính sách giao nhận); Điều khoản sử dụng chỉ giữ quyền tạm dừng giao dịch có dấu hiệu bất thường. Cần quyết: xây ngưỡng theo đặc tả hay chấp nhận lệch. Xây rồi thì Chính sách giao nhận (mục Thời điểm giao) và Điều khoản sử dụng phải thêm trường hợp đơn bị giữ chờ kiểm tra.
- Hủy dữ liệu khi hết thời hạn lưu, và thời hạn giữ bản sao lưu. Đặc tả 7.2 chỉ cấm xóa TRONG thời hạn lưu. Chưa có quy trình hủy khi hết hạn (5 năm, 10 năm), và các trigger cấm xóa (audit_logs, ledger_entries, order_items, order_transitions, ticket_events, bank_transactions, ticket_evidence, user_consents) chặn cả việc xóa sau hạn. Bản sao lưu tự động của Supabase còn dữ liệu như trước khi ẩn danh hóa cho tới khi bản sao lưu đó hết hạn theo gói dịch vụ. Văn bản đang viết: thời hạn lưu là thời hạn tối thiểu, hết hạn thì dữ liệu không tự động bị xóa; bản sao lưu còn dữ liệu cũ tới khi hết hạn, không ghi số ngày. Cần quyết: có hủy khi hết hạn không, ai duyệt và hủy bằng cách nào; và ghi số ngày giữ bản sao lưu của gói Supabase đang dùng.
- Đồng ý bằng nút Google và bỏ bước xác minh email. Chủ đầu tư quyết định ngày 28/09/2026: khách đăng nhập hoặc đăng ký bằng Google đồng ý Điều khoản sử dụng và Chính sách bảo mật bằng chính cú bấm nút Google (dòng “Bằng việc tiếp tục với Google, bạn đồng ý…” ngay dưới nút, bằng chứng lưu với nguồn DANG_NHAP_GOOGLE, kèm thời điểm, phiên bản, IP và trình duyệt) rồi đi thẳng tới trang mua, không qua trang Đồng ý điều khoản; khách tạo tài khoản bằng email không phải xác minh email khi “Confirm email” của Supabase Auth đã tắt. Văn bản phiên bản hiện hành còn viết theo cách cũ: Điều khoản sử dụng, mục chấp nhận điều khoản (khách Google tự tích ô ở trang Đồng ý điều khoản, ô không tích sẵn, tách riêng hai văn bản); Hỏi đáp (câu hỏi vì sao khách Google phải tích ô sau khi đăng nhập); Chính sách bảo mật, mục Cookie (chưa nêu riêng cookie ghi dấu bấm đồng ý, sống 15 phút). (Chữ “đã xác minh email” trong mục Tài khoản của Điều khoản sử dụng và trong Hỏi đáp đã được bỏ ở phiên bản -7, ngày 05/10/2026.) Trong lúc chờ, đồng ý bằng nút Google được ghi cho chính phiên bản đó. Cần luật sư: xác nhận một cú bấm cho cả hai văn bản đủ điều kiện “đồng ý” theo pháp luật bảo vệ dữ liệu cá nhân; sửa các câu trên rồi tăng phiên bản; và quyết khi văn bản lên phiên bản mới, khách Google đã đồng ý bản cũ chỉ cần dòng dưới nút hay phải qua trang Đồng ý điều khoản như khách mật khẩu.
- Quy trình sự cố lộ dữ liệu còn ô chờ điền. Chính sách bảo mật hứa đánh giá sự cố lộ dữ liệu trong 24 giờ, báo khách bị ảnh hưởng và cơ quan có thẩm quyền trong 72 giờ (đặc tả 7.2). Hệ thống không có công cụ cho việc này; quy trình tay nằm ở apps/web/src/lib/legal/su-co-du-lieu.runbook.md (các khối SQL trong đó đã chạy thử trên cơ sở dữ liệu thật trong giao dịch quay lui). Còn thiếu: người điều phối sự cố và người thay thế, cơ quan nhận thông báo, mẫu và kênh nộp theo văn bản pháp luật đang có hiệu lực, nơi lưu hồ sơ sự cố, và luật sư duyệt mẫu thư gửi khách.
- Tạm dừng gửi email cho khách (quyết định ngày 05/10/2026). Chủ đầu tư quyết định ngày 05/10/2026: tạm thời không gửi email cho khách (không dùng dịch vụ gửi thư). Văn bản phiên bản -7 nói đúng điều đó: Website không gửi email về đơn hàng, ví, nạp ví, khiếu nại; khách xem trên Website (trang đơn, Kho thẻ đã mua, Ví GCard365, Khiếu nại của tôi); quên mật khẩu và xác nhận email thì liên hệ hỗ trợ qua hotline hoặc email hỗ trợ; chỉ còn các email do nhân viên trả lời tay theo yêu cầu của khách. Việc này LỆCH đặc tả 1.2 (đòi gửi email cho đúng 11 sự kiện, trong 60 giây) và kế hoạch BUILD-PLAN. Khi bật gửi thư trở lại phải làm đủ: (1) viết lại các chỗ gắn MAIL_OFF (grep MAIL_OFF) và mục email của Chính sách bảo mật, thêm lại khóa nhà cung cấp gửi email; (2) bảo đảm không còn thư PENDING cũ trong hàng đợi để khách không nhận thư tồn đọng; (3) cấu hình MAIL_* của worker; (4) tăng phiên bản văn bản. Cần quyết: có chủ động gọi hoặc nhắn thủ công cho khách khi khiếu nại có kết luận không, và cách giúp khách quên mật khẩu (hiện trang quản trị chưa có công cụ đặt lại mật khẩu cho khách).