User 系權限範圍的審查申請
適用於使用 ReceiptRoller 的 User 系權限範圍（
user.receipts.read 等）的應用程式的開發者。說明審查申請的流程、必要文件、審查基準、常見退件理由。
ReceiptRoller 的權限範圍當中，以 user.* 開頭者是為了存取一般消費者的個人資料的權限範圍。這些不僅需要店鋪端的同意，還需經過消費者本人的同意與 ReceiptRoller 的審查後，才首次可以使用。
User 系權限範圍為審查制的理由
- 收據明細、購買紀錄相當於機微個人資訊
- 消費者不是與店鋪，而是與「ReceiptRoller」有直接的信賴關係
- 若資料交給不適當的應用程式，消費者、店鋪、ReceiptRoller 整體的信賴將受損
- 需要確認第三方提供、跨境傳輸等的合規性
因此，設有比店鋪系權限範圍更嚴格的審查流程。
作為審查對象的權限範圍
| 權限範圍 | 可存取的資料 |
|---|---|
user.profile |
顯示名稱、電子郵件地址、登錄地區 |
user.receipts.read |
本人的收據一覽、明細 |
user.receipts.write |
為收據加上標籤、追加備忘 |
user.purchases.aggregate |
本人的購買摘要（依類別彙總） |
user.coupons.read |
本人持有的優惠券 |
user.notifications.send |
對本人發送推播通知 |
所有 User 系權限範圍都必為審查對象。需要依每個權限範圍個別申請，無法「為了以防萬一」申請不使用的權限範圍。
申請的流程
[應用程式登錄完成]
│
▼
[必要文件的準備] ← 隱私權政策公開、設置刪除窗口 等
│
▼
[從開發者入口申請] ← 權限範圍選擇 + 申請表單輸入
│
▼
[一次審查]（營業日 1〜3 日） ← 文件不備檢查
│
├─→ 退件 → 修正後重新申請
│
▼
[二次審查]（營業日 5〜10 日） ← 實作、運用體制的審查
│
├─→ 追加提問 → 提出回答 → 再審查
│
▼
[核准]
│
▼
[在正式環境可使用 User 系權限範圍]
在標準的案例中，請預估從申請到核准約 2〜3 週。退件多次時，也可能花費 1〜2 個月。
必要文件、資訊
1. 隱私權政策（必填）
- 存在公開 URL
- 明記從 ReceiptRoller 取得的資料項目
- 記載利用目的、保管期間、刪除步驟、有無第三方提供
- 明記聯絡窗口
- 以日本的使用者為對象時，備妥日文版
2. 使用條款（建議）
消費者向應用程式的情況建議提供。即使是 B to B 向，若有明記處理消費者資料之旨，審查會較順利。
3. 刪除委託受理窗口（必填）
- 電子郵件地址或洽詢表單 URL
- 自受理起 30 日內完成資料刪除的體制
- 刪除完成通知的運用方法
4. 資料處理表（必填）
在申請表單內填寫下列項目。
| 項目 | 填入內容 |
|---|---|
| 取得資料 | 依每個權限範圍的具體項目名 |
| 保管場所 | 雲端業者、區域 |
| 保管期間 | 自最終取得起幾個月後刪除 |
| 第三方提供 | 有／無，有的情況填提供對象 |
| 跨境傳輸 | 有／無，有的情況填對象國 |
| 加密 | 保管時、通訊時的加密方式 |
| 存取控制 | 誰、在什麼條件下可以檢視 |
5. 動作確認用測試帳戶（視情況必填）
應用程式的實作已完成時，為了讓審查負責人實際確認 OAuth 授權流程〜資料取得〜顯示，可能會請您提供測試帳戶。
6. 螢幕截圖、影片（建議）
- OAuth 授權畫面上向使用者顯示的說明
- 取得的資料在應用程式內如何被使用的畫面
- 刪除委託的導引
影片 1〜2 分鐘左右即可。實作印象若能傳達，審查時間會縮短。
申請步驟
- 開發者入口 → 應用程式 → 「權限範圍」分頁
- 勾選想申請的 User 系權限範圍
- 點擊「申請審查」按鈕
- 在申請表單輸入必要事項（隱私權政策 URL、資料處理表等）
- 上傳附件資料（測試帳戶資訊、螢幕截圖等）
- 「送出申請」
申請後狀態會變成「審查中」，進度可在同一畫面確認。聯絡會寄到申請時的電子郵件地址。
審查基準
主要的審查觀點如下。
最小必要原則
確認申請的權限範圍，為達成申告的利用目的是否真的必要。廣泛取得的申請會被退件。
明確的利用目的
從消費者的角度來看，「為什麼這個應用程式需要拿到資料」須一讀即懂。像「為了提升服務」這樣抽象的記述不可。
資料保護體制
加密、存取控制、保管期間的設定、刪除流程的整備。須滿足最低限度的業界標準。
法令遵循
個人資訊保護法、特定商業交易法、贈品標示法、各國的隱私權法（有 GDPR 等對象的情況）的遵循。
營運主體的透明性
營運公司的所在地、代表人、聯絡方式須公開。無實體的業者、無法取得聯絡的業者不予核准。
UX 上的說明責任
OAuth 授權畫面上的權限範圍說明、初次啟動時的資料利用說明、刪除導引等須對消費者清楚易懂地呈現。
常見退件理由
| 退件理由 | 因應 |
|---|---|
| 隱私權政策未公開／URL 為 404 | 公開後重新申請 |
| 隱私權政策無收據資料的記載 | 追記取得的資料項目 |
| 利用目的抽象（僅「為了提升服務」等） | 記述具體的使用案例 |
| 權限範圍對目的而言過剩 | 縮減至必要的權限範圍 |
| 未記載刪除窗口 | 設置電子郵件地址或表單 URL |
| 第三方提供的有無不明確 | 明記「有／無」，有的情況也填提供對象 |
| 測試帳戶上授權流程無法運作 | 完成實作後重新申請 |
| 營運公司資訊未公開 | 記載於應用程式的網站、支援頁面 |
核准後的運用
被核准後，在正式環境即可使用 User 系權限範圍的授權流程。但請注意下列各點。
- 定期審查：每年 1 次，會有利用狀況、資料處理體制的確認
- 輕微的變更：保管場所的區域變更等輕微變更，僅事前通知即可
- 主旨的變更：變更利用目的、取得權限範圍、第三方提供的有無時須重新審查
- 違反時的措施：違反使用條款、客訴頻發時，可能經過警告→停止→核准取消的階段
申請前的自我檢查清單
申請前確認以下事項，可大幅減少退件。
- ☐ 隱私權政策 URL 已公開，且明記從 ReceiptRoller 取得的資料
- ☐ 刪除委託的窗口（電子郵件或表單）正常運作
- ☐ 利用目的記述了「為了誰」「做什麼」「送往何處」
- ☐ 申請的權限範圍對利用目的而言為最小必要
- ☐ 明記第三方提供、跨境傳輸的有無
- ☐ 資料的保管期間與加密方式已決定
- ☐ 測試環境上授權流程可運作
- ☐ 營運公司資訊已公開於網站
申請狀態與所需時間的參考
| 狀態 | 意義 | 標準所需 |
|---|---|---|
| 未申請 | 權限範圍選擇前 | — |
| 申請受理 | 送出完成 | 即時 |
| 一次審查中 | 文件確認中 | 1〜3 營業日 |
| 退件 | 有不備，需修正 | — |
| 二次審查中 | 實作、運用體制確認 | 5〜10 營業日 |
| 等待追加資訊 | 審查員提問中 | 回答後 3 營業日內再開 |
| 核准 | 可正式利用 | — |
| 駁回 | 申請內容有重大問題 | 附理由通知 |
常見問題
Q. 開發中無法試用 User 系權限範圍嗎？
A. 僅限開發用應用程式（測試應用程式），可使用僅營運公司內的測試使用者（自家成員）能授權的「沙盒框」。無法向一般消費者公開授權流程。
Q. 一旦被核准後，想追加新的 User 系權限範圍時？
A. 會成為僅追加該權限範圍的追加申請。既有權限範圍的審查結果會照樣沿用，只需提出追加部分的必要文件即可。
Q. 想撤下申請時？
A. 可從開發者入口的該申請畫面「撤下」。日後可重新申請。
Q. 審查拖延時，可以洽詢嗎？
A. 自申請起經過營業日 10 日仍無進展時，請洽開發者社群或支援窗口。附記申請 ID 的話確認會較順利。