สโคปประเภท User ส่งคืน app_not_approved
เมื่อเรียก API ที่ใช้สโคป
user.* เช่น user.receipts.read จะได้รับข้อผิดพลาด app_not_approved
สาเหตุ
สโคปประเภท User หากยังไม่ได้รับการอนุมัติผ่านการตรวจสอบของ ReceiptRoller จะใช้กับใครไม่ได้นอกจากผู้ใช้ทดสอบภายในบริษัทผู้ให้บริการ อาการนี้เกิดขึ้นในกรณีที่พยายามให้ผู้บริโภคทั่วไปอนุมัติ หรือใช้กับบุคคลอื่นที่ไม่ใช่ผู้ใช้ทดสอบที่ผ่านการตรวจสอบแล้ว
สามกรณี
กรณีที่ 1: อยู่ระหว่างการพัฒนาและยังไม่ได้ยื่นขอตรวจสอบ
การรับมือ: สร้างแอปสำหรับพัฒนา (แอปทดสอบ) และใช้ sandbox กับผู้ใช้ทดสอบภายในบริษัทผู้ให้บริการ (สมาชิกในทีมของคุณเอง) ไม่สามารถเปิดเผยฟลว์การอนุมัติต่อผู้บริโภคทั่วไปได้
กรณีที่ 2: อยู่ระหว่างยื่นขอตรวจสอบ
การรับมือ: ก่อนที่การตรวจสอบจะเสร็จสิ้น จะยังใช้กับผู้ใช้ production ไม่ได้ ตรวจสอบสถานะการตรวจสอบได้ที่ พอร์ทัลนักพัฒนา → แอป → แท็บ「สโคป」
กรณีที่ 3: ผ่านการตรวจสอบแล้วแต่ล้มเหลวกับผู้ใช้บางราย
การรับมือ: ผู้ใช้รายนั้นอาจถอนการอนุมัติแอปไปแล้ว โปรดนำผู้ใช้ไปที่ฟลว์การอนุมัติซ้ำ
ขั้นตอนการตรวจสอบ
- เปิด พอร์ทัลนักพัฒนา → แอป → แท็บ「สโคป」
- ตรวจสอบสถานะของสโคป
user.*ที่เกี่ยวข้อง- 「ยังไม่ยื่นขอ」→ ต้องยื่นขอ
- 「กำลังตรวจสอบ」→ รอเสร็จสิ้น
- 「อนุมัติแล้ว」→ ใช้งาน production ได้
- 「ถูกปฏิเสธ」→ ตรวจสอบเหตุผลแล้วยื่นขอใหม่
- หากสถานะเป็น「อนุมัติแล้ว」แต่ยังล้มเหลว ให้ระบุ
request_idของ error response พร้อม ID ของผู้ใช้ที่เกี่ยวข้อง แล้วติดต่อฝ่ายสนับสนุน
การพัฒนาในโหมด sandbox
หากเป็นสมาชิก (พนักงาน) ของบริษัทผู้ให้บริการ ก็สามารถทดลองสโคปประเภท User ได้แม้ก่อนการตรวจสอบ
- สร้างแอปสำหรับพัฒนา (แอปทดสอบ)
- เปิดใช้งาน「โหมด sandbox」
- ดำเนินฟลว์การอนุมัติด้วยสมาชิกของบริษัทผู้ให้บริการ
- เรียก API ได้
โหมด sandbox นี้จำกัดเฉพาะสมาชิกภายในบริษัทผู้ให้บริการเท่านั้น ไม่สามารถเปิดเผยต่อผู้ใช้ภายนอกหรือผู้ที่ไม่ใช่ผู้ทดสอบได้
การนำขึ้นสู่ production
เมื่อยืนยันการทำงานในโหมด sandbox เสร็จแล้ว ให้ลงทะเบียนแอป production แยกต่างหากและยื่นขอตรวจสอบ ไม่มีกลไกที่จะนำแอป sandbox ขึ้นสู่ production โดยตรง
คู่มือที่เกี่ยวข้อง
-
พอร์ทัลนักพัฒนาไม่แสดงเมื่อยังใช้แพลนฟรีขั้นตอนการตรวจสอบเมื่อพอร์ทัลนักพัฒนาของ ReceiptRoller ไม่แสดง อธิบายวิธีรับมือเมื่อใช้แพลนฟรี การสลับบัญชีธุรกิจ และช่วงเวลาที่การแสดงผลมีผล
-
ขอโทเคนไม่ได้ (ข้อผิดพลาดการยืนยันตัวตน)การแยกแยะสาเหตุเมื่อขอ access token ไม่ได้ อธิบายข้อผิดพลาดทั่วไป เช่น invalid_client, invalid_grant, redirect_uri_mismatch และวิธีรับมือ
-
Webhook ไม่มาถึงการแยกแยะสาเหตุเมื่อ Webhook ไม่มาถึง endpoint ผู้รับ อธิบายขั้นตอนการตรวจสอบตามลำดับ ทั้งการตั้งค่า endpoint การสมัครรับ event ความสามารถในการเข้าถึง ความล้มเหลวในการตรวจสอบลายเซ็น และไฟร์วอลล์
-
ได้รับ 403/401 (สิทธิ์และสโคป)การแยกแยะสาเหตุเมื่อการเรียก API ส่งคืน 401 หรือ 403 อธิบายกรณีทั่วไป เช่น โทเคนไม่ถูกต้อง สโคปไม่เพียงพอ ไม่มีสิทธิ์เข้าถึงร้านค้า และสโคปประเภท User ที่ยังไม่ผ่านการตรวจสอบ