背景
我們的付款流程分為兩層：
- 前端付款 UI：使用 Vendor A 的 SaaS。
- 後端訂價與帳款：由 Zuora 處理。
我們這邊的角色比較像中介，把資料 redirect 給 Vendor A，並把我們內部需要揭露給 Vendor A 的資料傳過去給他。雖然 Vendor A 的該產品是固定的服務，但我們有一些客製化需求。
近期我們正在準備 多國貨幣付款流程。Vendor A 本身有串接 Zuora 的多幣別功能，因此只要在 Zuora 和 Vendor A 後台設定好產品幣別，就能正常交易。
問題
在測試購買流程時：
- 使用者輸入地址（印度觀光局的合法地址）。
- 點選 confirm → 付款送出。
- 系統回傳錯誤：「地址驗證失敗」。
讓我感到問號的地方
- 我們 Zuora 中的 Avalara 地址驗證已經關閉。
- 地址本身也完全正確。
- Vendor A log system 中的錯誤訊息中提到的是 一個我們沒有要販賣的產品，還說「缺少印度盧比幣別」。
讓我感到氣餒的地方
- 來回跟 vendor 對話多次，他們只提到有上方的錯誤，並沒有跟我們說為何這樣錯。
調查過程
- 一週內我們與 Vendor A 工程師不斷交換 log 與測試案例。
- 發現 Vendor A 的 log system 裡，錯誤訊息總是指向某一個固定產品。
- 反覆測試後發現：錯誤並非來自地址本身，而是 Zuora 回傳該產品缺少幣別。
Root Cause
Vendor A 在執行 address validation 時，會對 Zuora 發出 Preview Call。我猜測應該是這個 api
- Zuora 的 Preview API 需要帶上一個產品 charge。
- Vendor A 的邏輯是：直接拿「第一個同步到資料庫的 active product」來做測試。
- 偏偏這個產品沒有設定印度盧比幣別 → 導致 Zuora 回傳錯誤 → Vendor A 誤解成「地址驗證失敗」。
解決方案（選配）新增邏輯：只針對特定國家進行地址驗證，避免不必要的錯誤。
- 對方建議在 Zuora 中建立一個 專用測試用 Product/RatePlan，例如：
- 名稱：Address Validation Plan
- 幣別：啟用所有需要支援的幣別
- 讓 Vendor A 的 address validation preview call 固定使用這個專用產品，而不是隨機挑選第一個同步產品。
教訓 (Lessons Learned)
- Vendor 文件要完整：多國貨幣這個功能我找好幾天，官方文件上完全沒有提到。至少也要找一個社群比較活躍的 vendor.
- Vendor 的黑箱邏輯要透明：如果 Vendor 在客製化流程中有 fallback 或假設值，必須清楚文件化，否則下游會 debug 到懷疑人生。
- 測試邏輯要與商業邏輯隔離：address validation preview 不應依賴真實商品，應有專用測試商品。
- 多國幣別要考慮完整性：一旦牽涉跨國驗證，測試商品必須涵蓋所有幣別，否則會造成誤導性的錯誤訊息。
