背景痛點

這類振興活動的核心矛盾很簡單：要擋得住造假，又不能讓一般民眾覺得難用。門檻太鬆，活動預算被有心人洗走；門檻太嚴，真的去消費的人登錄失敗就客訴。

最直覺的做法是串接官方的電子發票查驗 API，一翻兩瞪眼。但實際評估後發現，該 API 的使用規範訂有資安驗證門檻，我們與主辦端都不具申請資格。

另一個現實是資料結構比想像複雜：合作旅宿有六百多家，但同一家旅宿常常有多組統一編號（不同營業項目或分館），實際要比對的是「旅宿 × 統編」的配對關係，將近千筆。

我們怎麼做

不繞過問題，換一個問法。 既然拿不到官方 API，就回頭問：一張真發票本身帶了哪些資訊、可以自己驗證？答案比想像中多 —— 電子發票的 QR Code 裡就包含號碼格式、開立日期、金額編碼與加密驗證資訊。

第一層，條碼結構檢核。 解析 QR Code，檢查發票號碼格式、開立日期是否合理、金額編碼與加密驗證資訊是否自洽。亂編的條碼在這一層就掉了。

第二層，統一編號檢查碼。 賣方統編必須通過財政部公布的檢查碼演算法。這是數學規則，不需要連線任何系統就能驗。

第三層，合作店家名單。 賣方統編必須落在主辦提供的合作旅宿名單內。這一層同時擋掉「發票是真的，但不是在合作旅宿消費」的情況。

第四層，唯一性檢核。 同一張憑證全站只能登錄一次，杜絕同一張發票重複參加。

第五層，多重來源交叉比對。 條碼解析的結果、民眾自己填寫的內容、OCR 讀到的文字，三者互相對照。手開發票沒有 QR Code，就靠 OCR 輔助加人工確認補上。

第六層，異常行為偵測。 同一位參加者或同一來源在短時間內大量登錄會被標記。前五層驗的是「這張發票對不對」，第六層驗的是「這個人的行為正不正常」。

每一層的結果都獨立記錄，不是單純的通過或不通過。後台看得到某筆登錄是卡在哪一層、原因是什麼，人工審查時才有依據，而不是只能看到一個「失敗」。

在不具備官方 API 申請資格的前提下，仍然建立了可運作的發票驗證機制，活動如期上線。

六層彼此獨立，任何一層被繞過，其他五層仍然有效 —— 這比單一驗證來源更耐打。

主辦後台九大類 59 項功能全數完成，資料型頁面一律具備新增、編輯、刪除、排序、篩選、搜尋、分頁，不做半套。

這套驗證思路可以直接搬到其他消費登錄型活動 —— 商圈振興、觀光票券、消費抽獎，只要涉及「用發票證明消費」就適用。