In a market where Thai sellers get burned by fake payment slips every day, trust IS Nava's product. This page is an honest, technical answer to 'how do you protect my money and my customers' data?'. Nothing here is a claim the app doesn't actually do today.
Four promises we don't compromise
Never custody buyer funds
PromptPay QRs are bound to your bank account directly. If Nava disappeared tomorrow, your money is safe.
Real bank verification
Checked against real bank data. Not solely image recognition. Duplicate slips are designed to be refused, not silently accepted.
Your data stays yours
Customer history, orders, slips. Export to CSV anytime. Even after cancellation you get 90 days of access.
AI drafts, humans confirm
AI drafts orders and reads slips. But 'paid' requires a human eye. The system does not mark orders paid on its own.
The money's path
Buyer scans QR
QR is bound to your PromptPay
Transfer straight to your bank
Does not pass through Nava
Nava verifies the slip
Against real bank data
Order marked 'paid'
In your Nava dashboard
Infrastructure
Nava runs on enterprise-grade infrastructure (hosting, database, bank-data slip verification, AI for draft-order help, courier integrations). Every provider sits under a signed Data Processing Agreement and is PDPA-compliant. The current provider list is confidential. If you need it for compliance review or under a lawful request, email support@navaseller.com and we'll provide it under NDA or a valid legal request.
Report a vulnerability
If you find a vulnerability that warrants disclosure, email support@navaseller.com with subject "Security", a description, and steps to reproduce. We reply on business days. We don't run a formal bug bounty yet, but we confirm fixes and credit reporters on this page when appropriate.
Please don't: test against real sellers' accounts without permission, run DoS or spam attacks, or exfiltrate real customer data. Use a test account we provide and give us notice in advance.
Detailed policy sections
Below is the full policy in structured Thai. Currently Thai-only. English version in progress. Meanwhile, reach support@navaseller.com if you need details in English.
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 ใช้ AI สำหรับช่วยสรุปออเดอร์จากข้อความแชท · ภายใต้ข้อตกลงกับผู้ให้บริการโมเดล AI ระดับองค์กร ข้อมูลที่ส่งไปประมวลผลจะไม่ถูกนำไปใช้ฝึกโมเดล (no-train / no-retention) · ข้อความที่ผู้ค้าแก้ไขคำสรุปของ AI จะถูกเก็บภายใน Nava เพื่อปรับปรุงคุณภาพระบบ แต่ไม่ถูกส่งออกไปฝึกโมเดลของบุคคลภายนอก
9. สิ่งที่ยังไม่ได้ทำ (โปร่งใสด้วย)
เรายังไม่ได้:
- ผ่านการรับรอง SOC 2 / ISO 27001 (Nava ยังใหม่ · เอกสารพวกนี้ปกติเริ่มทำเมื่อมีลูกค้าองค์กร)
- รองรับการเข้ารหัสข้อมูลระดับ column (นอกจากโทเคนที่กล่าวข้างต้น)
- รองรับ 2FA แยกสำหรับบัญชีผู้ใช้ (ยังพึ่ง OTP ของช่องทางเข้าสู่ระบบ)
Incident reporting · data access
Data-subject rights (access, correct, delete, export) and how to exercise them are on the Privacy policy and Data deletion pages.