เงินและข้อมูล · คำสัญญาที่ตรวจได้

1. เงินของลูกค้าไม่ผ่าน Nava

หลักการสำคัญที่สุด: Nava ไม่ถือเงินของลูกค้าเลยแม้แต่บาทเดียว · QR พร้อมเพย์ที่ Nava สร้างในทุกออเดอร์ จะผูกกับหมายเลขพร้อมเพย์ของร้านค้าโดยตรง · เงินไหลจากบัญชีลูกค้า ไปที่บัญชีธนาคารของท่าน โดยไม่มี Nava เป็นตัวกลาง

ผลที่ตามมา: ต่อให้ Nava ล่มหรือปิดกิจการ เงินของท่านและลูกค้ายังปลอดภัย เพราะไม่เคยอยู่กับเรา · Nava ไม่ได้รับใบอนุญาตประกอบธุรกิจการชำระเงินและไม่มีหน้าที่ต้องได้ เพราะเราไม่ได้ทำธุรกิจถือเงิน

2. การตรวจสลิปด้วยข้อมูลธนาคารจริง

สลิปที่ลูกค้าส่งเข้าระบบ Nava จะถูกตรวจสอบผ่านผู้ให้บริการตรวจสลิปของประเทศไทยที่เชื่อมกับข้อมูลของธนาคาร ก่อนที่ระบบจะเสนอสถานะ 'จ่ายแล้ว' ให้ผู้ค้ายืนยัน · เราไม่ตัดสินจากภาพสลิปอย่างเดียว

รายการที่ตรวจ:

• ยอดเงินตรงกับยอดที่ควรจ่ายหรือไม่
• เวลาโอนอยู่ในช่วงเวลาที่สมเหตุสมผล
• ปลายทางเป็นบัญชีพร้อมเพย์ของท่านจริงหรือไม่
• เลขอ้างอิงตรงกับข้อมูลธนาคารหรือไม่ (สลิปปลอมมักปลอมช่องนี้ไม่ได้)
• สลิปเคยถูกใช้กับออเดอร์อื่นแล้วหรือไม่ (กันสลิปซ้ำ)

3. การเข้ารหัสข้อมูลระหว่างจัดเก็บและระหว่างส่ง

ข้อมูลที่ท่านให้ Nava จัดเก็บ (ชื่อร้าน เบอร์โทร ที่อยู่ ประวัติลูกค้า) จะถูกส่งผ่านช่องทางที่เข้ารหัส HTTPS/TLS ในระดับที่ธนาคารใช้ · ที่ฝั่งเซิร์ฟเวอร์ ข้อมูลถูกจัดเก็บในฐานข้อมูลระดับองค์กรที่โฮสต์ในภูมิภาคเอเชียตะวันออกเฉียงใต้ ซึ่งเข้ารหัสระดับดิสก์ (encryption at rest)

โทเคนการเชื่อมต่อกับ LINE, Facebook, Instagram ถูกเข้ารหัสก่อนบันทึกลงฐานข้อมูล · หากฐานข้อมูลถูกเข้าถึงโดยไม่ได้รับอนุญาต โทเคนที่ได้ไปจะใช้งานไม่ได้ทันที

4. สิทธิ์การเข้าถึง: เจ้าของร้านและพนักงาน

Nava แยกสิทธิ์การใช้งานระหว่างเจ้าของร้านและพนักงาน · พนักงานสามารถช่วยรับออเดอร์ ตอบแชท แพ็คของ ได้ · แต่เฉพาะเจ้าของร้านเท่านั้นที่แก้ไขหมายเลขพร้อมเพย์ได้

ผลที่ตามมา: หากท่านจ้างพนักงาน 5 คนช่วยดูออเดอร์ ท่านไม่ต้องกังวลว่าพนักงานจะเปลี่ยนพร้อมเพย์ให้เงินไปเข้าบัญชีตัวเอง · การเปลี่ยนพร้อมเพย์ทุกครั้งจะถูกบันทึกใน audit log พร้อมชื่อผู้แก้ไข วันเวลา และค่าเก่า/ใหม่

5. การยืนยันตัวตนและการปกป้องบัญชี

Nava ใช้ระบบยืนยันตัวตนระดับองค์กร (managed authentication) สำหรับการเข้าสู่ระบบ · รองรับ:

• การเข้าสู่ระบบด้วยเบอร์มือถือ + OTP (สำหรับผู้ค้า)
• การเข้าสู่ระบบด้วยอีเมล + รหัสผ่าน (สำหรับบัญชีทดสอบและผู้ดูแล)
• การจัดการ session ผ่าน JWT ที่ตรวจสอบทุก request
• การเปลี่ยนรหัสผ่านและกู้คืนบัญชีผ่านช่องทางที่ยืนยันแล้ว

6. การปฏิบัติตาม PDPA (พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล)

Nava ออกแบบมาให้สอดคล้องกับ PDPA ตั้งแต่ต้น · ท่านในฐานะเจ้าของร้านเป็น 'ผู้ควบคุมข้อมูล' ของลูกค้า และ Nava เป็น 'ผู้ประมวลผลข้อมูล' ที่ให้บริการเครื่องมือ

สิ่งที่เราทำเพื่อ PDPA:

• ระยะเวลาเก็บสลิป: ลบอัตโนมัติหลัง 90 วัน (เพื่อการเรียกดูของท่าน)
• ระยะเวลาเก็บข้อความ raw: ลบอัตโนมัติหลัง 90 วัน (เก็บเฉพาะ metadata ของออเดอร์)
• ท่านสามารถส่งออกข้อมูลลูกค้าเป็น CSV ได้ตลอดเวลา
• ท่านสามารถลบข้อมูลลูกค้ารายบุคคลตามคำขอ (สิทธิ์ในการถูกลืม)
• หน้า /data-deletion มีคำอธิบายและช่องทางร้องขอ

7. การรับมือเหตุการณ์ผิดปกติ

หาก Nava พบเหตุการณ์ที่อาจกระทบต่อความปลอดภัยของข้อมูลหรือเงินของท่าน:

• เราจะแจ้งท่านทางอีเมลที่ลงทะเบียนไว้และในระบบ Nava โดยไม่ชักช้าหลังยืนยันเหตุการณ์และตามที่กฎหมายกำหนด
• หากเป็นการรั่วไหลของข้อมูลส่วนบุคคล เราจะแจ้งสำนักงานคุ้มครองข้อมูลส่วนบุคคล (PDPC) โดยไม่ชักช้าตามที่ PDPA มาตรา 37 กำหนด
• เรื่องที่กระทบการชำระเงินหรือการตรวจสลิปถือเป็นเหตุการณ์เร่งด่วนที่สุดในกระบวนการภายในของ Nava

8. AI ช่วยร่างออเดอร์: ส่งอะไร ไปที่ไหน

Nava ใช้โมเดล Claude ของ Anthropic อ่านข้อความแชทเพื่อร่างออเดอร์ · ส่งเฉพาะข้อความในแชทของการสั่งซื้อนั้น (ไม่ส่งรูปภาพ รวมถึงรูปสลิป) · ตามเงื่อนไขของ Anthropic ข้อมูลที่ส่งผ่าน API ไม่ถูกนำไปฝึกโมเดล ถูกลบภายใน 30 วัน และจัดเก็บในสหรัฐอเมริกา · ถ้า Anthropic ใช้งานไม่ได้ ระบบจะลองใหม่ภายหลัง ไม่ส่งไปที่อื่นเอง · เฉพาะเหตุขัดข้องนาน Nava อาจเปิดใช้ผู้ให้บริการสำรอง (DeepSeek ซึ่งจัดเก็บข้อมูลในประเทศจีน และอาจใช้ข้อมูลปรับปรุงโมเดล เว้นแต่ขอยกเลิก ซึ่ง Nava ได้ขอแล้ว) และจะแจ้งที่หน้านี้ทุกครั้ง · ใน Nava เอง ข้อมูลส่วนตัวในร่างออเดอร์ถูกลบอัตโนมัติหลัง 30 วัน · การแก้ไขที่ร้านทำกับร่างของ AI เก็บไว้ใน Nava เพื่อปรับปรุงความแม่นยำ และไม่ส่งออกไปให้บุคคลภายนอก · AI ไม่เคยยืนยันการรับเงิน ไม่เปลี่ยนเลขพร้อมเพย์ และไม่ส่งของแทนร้าน

9. สิ่งที่ยังไม่ได้ทำ (โปร่งใสด้วย)

เรายังไม่ได้:

• ผ่านการรับรอง SOC 2 / ISO 27001 (Nava ยังใหม่ · เอกสารพวกนี้ปกติเริ่มทำเมื่อมีลูกค้าองค์กร)
• รองรับการเข้ารหัสข้อมูลระดับ column (นอกจากโทเคนที่กล่าวข้างต้น)
• รองรับ 2FA แยกสำหรับบัญชีผู้ใช้ (ยังพึ่ง OTP ของช่องทางเข้าสู่ระบบ)