優惠碼流程看似已完成，但本地購買測試通過後，Sandbox 裡的兌換結果仍然無法確認。 最快的判斷方式：用 Xcode 的 StoreKit Testing 驗證購買與權益邏輯，再用 App Store Connect 建立的 Sandbox 優惠碼及 Sandbox Apple Account 驗收實際兌換；本地通過不代表 Sandbox 兌換成功。
正在為自動續期訂閱增加優惠碼入口的獨立開發者，可用本文區分本地邏輯測試與實際兌換驗收。
已建立優惠活動、準備測 Sandbox 兌換的開發者，可依照職責整理操作與證據。
維護訂閱交易及權益服務的小團隊，則可核對 App 與伺服器端的處理結果是否一致。
先依測試目的判斷 StoreKit 優惠碼測試範圍
本地 StoreKit Testing 適合快速檢查商品呈現、購買流程及 App 收到交易後如何處理權益；實際優惠碼是否能在 Sandbox 兌換，則必須在 Sandbox 流程中驗證。兩者不能互相代替，因為本地配置不會證明特定優惠碼已建立、可兌換，或已由 App Store 的測試流程接受。
| 測試選項 | 適合驗證 | 不能據此判定 |
|---|---|---|
| Xcode 的 StoreKit Testing | 商品與購買介面、交易處理、權益開通及復原邏輯 | App Store Connect 建立的優惠碼可否兌換 |
| Sandbox 優惠碼與 Sandbox Apple Account | 優惠碼兌換流程、測試交易及 App 對交易的處理 | 正式顧客優惠碼已上線或正式環境行為完全無誤 |
| App 內兌換入口 | App 是否能呈現兌換介面，以及兌換後能否接續處理交易 | 僅憑畫面顯示成功就證明伺服器權益已更新 |
StoreKit 優惠碼可以用 Xcode 本地配置測試嗎？
可以用本地配置檢查購買與權益處理邏輯，但這不等同於兌換 App Store Connect 建立的 Sandbox 優惠碼。Xcode 可將 StoreKit configuration 指派給專案的執行方案，讓測試使用本地商品與購買狀態；設定方式可參照 Apple 的 Xcode StoreKit Testing 說明。驗收紀錄應標明測試環境，避免把本地交易寫成 Sandbox 兌換證據。
負責購買邏輯的開發者：先驗證本地交易與權益
在本地測試中，先確認 App 使用的商品識別碼與 StoreKit configuration 相符，再執行購買流程，觀察交易交付後的畫面與權益狀態。測試重點不是只看購買按鈕是否有反應，而是交易結果能否進入 App 既有的訂閱處理流程。
若使用交易監聽或交易驗證邏輯，應確認 App 能辨識交易所屬商品、更新使用者權益，並在必要時處理交易撤銷或過期狀態。Apple 的 Transaction 參考文件列出交易物件可供 App 讀取的資料，例如 productID、transactionID 與 originalID；這些欄位可協助開發者把商品、單次交易與原始訂閱關聯起來。
本地驗收適合先排除商品 ID 錯誤、權益映射失效、畫面未更新等問題。若這些基本邏輯仍有缺陷，直接進入 Sandbox 測試會讓「兌換失敗」與「App 沒有正確處理交易」難以區分。
負責後台設定的開發者：分清測試碼與正式優惠碼
Sandbox 兌換前，先核對 App Store Connect 中的訂閱商品、優惠活動與測試目標是否一致。建立優惠碼時應明確區分供測試使用的碼與正式行銷用途的碼，並以不同標籤和保管方式記錄；不要把測試憑據放進顧客宣傳素材、公開文件或正式活動流程。
Sandbox 優惠碼要在哪裡建立和兌換？
優惠碼及訂閱優惠活動應依照 App Store Connect 的設定流程建立，再使用 Sandbox 測試流程驗證。可參照 Apple 的訂閱優惠碼設定文件核對後台操作；Sandbox 測試帳號則依照建立 Sandbox Apple Account 的官方說明準備。不要將正式顧客使用的優惠碼當成 Sandbox 測試憑據，也不要因為後台已建立活動，就推定裝置端兌換已成功。
| 後台或帳號項目 | 開始測試前核對 | 常見誤判 |
|---|---|---|
| 訂閱商品 | App 使用的商品與後台測試目標一致 | 商品存在就代表優惠活動已可測 |
| 優惠活動與代碼 | 測試用途、代碼來源及活動設定已確認 | 建立完成就代表代碼已在裝置兌換 |
| Sandbox Apple Account | 測試使用的帳號與測試流程相符 | 登入帳號就代表當前兌換必定使用 Sandbox |
| 測試紀錄 | 記下環境、代碼用途與操作入口 | 只留「成功」截圖，沒有交易或權益證據 |
負責裝置兌換的開發者：分開檢查系統入口與 App 內入口
先從系統提供的兌換入口執行測試，記錄裝置上使用的帳號環境、輸入的測試碼、提交後的系統回應，以及 App 最後顯示的訂閱狀態。Apple 對應的使用 Sandbox 測試 App 內購買說明可作為裝置端測試依據；若測試的是 App 外完成的購買，也應參照App 外購買測試文件核對應有的處理方式。
「代碼已提交」、「系統顯示兌換完成」與「App 已正確開通權益」是不同結果，測試紀錄應分開保存。若 App 有提供輸入優惠碼或開啟兌換介面的功能，也要獨立測該入口，不要用系統兌換入口的成功結果代替。App 內優惠碼支援需有相應的 StoreKit 流程，可對照 Apple 的 App 內優惠碼支援文件。
如何測試 App 內輸入優惠碼的兌換流程？
先確認 App 已實作 Apple 文件所述的優惠碼支援，再從 App 內入口啟動兌換，觀察介面是否正確呈現；完成兌換後，仍須檢查交易是否進入 App 的處理邏輯，以及訂閱權益是否更新。若 App 尚未實作相應能力，不能只靠本地 StoreKit Testing 就宣稱 App 內兌換已驗收。
負責訂閱服務的小團隊：用交易與權益狀態交叉驗證
裝置端畫面只能提供其中一部分證據。App 端應確認交易商品與使用者權益對應正確；若服務端負責訂閱狀態，還要核對服務端接收的交易資料及權益結果，避免 App 顯示已解鎖、伺服器卻仍標記未訂閱，或反過來發生狀態不同步。
優惠碼兌換成功後，如何確認訂閱權益已開通？
至少要把兌換後的交易證據、App 顯示的權益狀態，以及服務端保存的訂閱狀態互相比對。若專案使用 App Store Server Notifications，測試事件應與正式環境資料分開記錄；Apple 的通知設定文件可用來核對伺服器通知的設定方向。單一成功畫面不足以證明交易已完整傳遞並完成權益處理。
| 驗收證據 | 通過時應看到的結果 | 未通過或需補測的情況 |
|---|---|---|
| 兌換入口紀錄 | 可辨識由系統入口或 App 內入口開始 | 只有「已兌換」文字，無法確認使用哪個入口 |
| 交易資料 | 商品及交易資料能對應此次測試 | 找不到交易，或商品與預期不符 |
| App 權益 | App 顯示的訂閱權益與交易相符 | 交易已收到，但畫面未更新或權益錯誤 |
| 服務端狀態 | 測試環境資料與 App 端結果相符 | 通知未處理、資料未更新，或混入正式紀錄 |
發布負責人：按職責整理可勾選的驗收清單
以下清單應由負責相應環節的人員提供證據。任何一項沒有證據，都應標記為未完成或需補測，而不是用其他環境的成功結果代替。
- [ ] 購買邏輯負責人：StoreKit configuration 與 App 商品設定一致；本地購買後的交易處理和權益狀態已核對。
- [ ] App Store Connect 負責人：訂閱商品、優惠活動及 Sandbox 測試碼用途已確認，測試碼沒有混入正式顧客活動。
- [ ] 裝置測試負責人：已記錄 Sandbox Apple Account、系統兌換入口或 App 內入口，以及提交後的系統回應。
- [ ] 訂閱服務負責人：交易資料、App 權益與服務端訂閱狀態互相吻合；Sandbox 事件沒有被當成正式環境紀錄。
- [ ] 發布負責人：將本地測試與 Sandbox 實際兌換分別標示，並保留入口、交易及權益證據。
若只有本地 StoreKit Testing 成功，應判定為「本地購買邏輯通過，Sandbox 優惠碼待驗收」；若兌換已提交但交易或權益資料缺失，應判定為「需補測」；只有優惠碼兌換、App 交易處理及預期權益都有相應證據，才適合將整段功能標記為通過。
需要遠端 Mac 的團隊：確認它能完成哪一段工作
沒有本地 Mac 時，遠端 Mac 可用於開啟 Xcode 專案、執行本地 StoreKit Testing 與準備建構工作；但遠端建構成功本身不能證明 Sandbox 優惠碼已在實際測試流程中兌換，也不能代替裝置端檢查或服務端權益驗收。測試人員仍須安排合適的 Sandbox Apple Account、兌換裝置與測試會話，並確認交易證據能回到負責人手上。
是否租用遠端 Mac，應按測試環境和使用頻率決定。自備 Mac 適合長期高頻開發，並且需要本機裝置與周邊整合的團隊；臨時租用則可避免為短期建構或 Xcode 測試先承擔硬體購置、閒置與維護成本，但仍受網路連線和實際兌換裝置安排影響。需要評估遠端環境時，可先查看 RUVCLOUD 的方案與計費資訊，再判斷是否符合專案的測試週期；若已決定使用，也可由 RUVCLOUD 的訂購頁面了解後續安排。
對只需短期執行 Xcode 專案、手邊沒有可用 Mac 的開發者，租用 Mac 可省去先購買一台專用機器、承擔閒置及自行維護的負擔；但若測試必須長期依賴固定實體裝置或持續重載運作，自購設備可能更合適。無論採用哪種環境，RUVCLOUD 遠端 Mac 都只負責可在該環境完成的建構與測試工作，不會取代 Sandbox 帳號、實際兌換或交易與權益驗收。