從 API 串接角度評估電子發票存摺 APP 可以怎樣出賣使用者個資
2023/3 財政部電子發票整合服務平台的 API 更新申請規範
財政部電子發票整合服務平台發了新公告 「電子發票應用程式介面使用規範」，自112年3月31日起生效
配合法制實務作業，修正名稱為「電子發票應用程式介面使用規範」；考量雲端發票使用率日益攀升，開發者使用電子發票應用程式介面(以下簡稱API)開發軟體產品供產品使用者查詢其消費發票行為亦隨之增加，為維護使用者及營業人權益，爰修正本規範，其修正重點如下：
一、配合修正規定第六點，開發者須通過CNS27001國家標準或ISO27001國際標準之認證。因該認證僅適用於企業及組織，爰個人申請部分將不再列入開發者範圍。(修正規定第三點)
二、為有效管理開發者及維持電子發票整合服務平台效能，增訂API流量管制及重行審核機制；另考量現行已審核通過之開發者，仍須適用本規範修正後規定，申請CNS27001國家標準或ISO27001國際標準認證，爰增訂須重新提出申請之緩衝期間，並定明已申請尚未經財政部財政資訊中心審核通過之案件適用原則。（修正規定第四點）
三、為維護產品使用者及營業人權益，避免開發者不當利用產品使用者之任何電子發票資料、使用紀錄及相關資訊，爰增訂開發者應留存產品使用者同意之軌跡紀錄，及提供產品使用者停止使用或利用其資料之權利，並應定期重新取得產品使用者同意。此外，開發者未提供電子發票資料予產品使用者前，不得逾越電子發票服務範圍，並限制開發者經產品使用者重新同意所為之電子發票服務範圍外利用時，仍不得從事之行為。（修正規定第五點）
四、為強化開發者資訊安全管理，增訂開發者之資訊安全制度應符合CNS27001國家標準或ISO27001國際標準認證，其認證範圍應包含利用API之軟體產品及加值衍生著作所有資訊業務活動。（修正規定第六點）
五、增訂得停止或終止開發者使用API之情事，以加強對開發者管理。(修正規定第十點)
六、統一規範開發者有第四點第一項第七款後段與第二項、第十點第一項及第三項規定情形，應停止、終止使用API或自行停用API，其於軟體產品及加值衍生著作使用API提供產品使用者使用電子發票服務功能及產品使用者載具資料等相關資訊之處理方式。（修正規定第十一點）
爾後除了完全禁止個人申請之外，
還針對本文的一些問題，增加了 API KEY、API 流量管制等機制，
最重要的一點是申請者需要有 CNS27001 國家標準或 ISO27001 國際標準認證，ISO27001認證的有效期限為三年，每年還會有年檢、合規和認證都是一筆不小的花費，一般小型接案公司可能玩不起。
爾後應該比較不用擔心有奇奇怪怪的民間發票應用，剩下的開發者都是大公司或有錢的財團了。
一些發票廠商的情況又如何呢?
2023/4/1，下文介紹的其中一款發票存摺服務，水滴發票宣布結束服務水滴發票 服務終止公告 (後來看到開發者訪談，水滴發票收掉不是因為政府的發票 API 改版搞的)。
2023/5，LINE 也加入發票存摺服務，商品叫做「LINE發票管家」，LINE發票管家其他利用目的同意條款跟LINE發票管家使用條款也沒有在客氣，直接寫說
– 向您投放您可能感興趣的廣告、推廣促銷資訊（包括本公司、LINE關係企業或第三方之商品或服務）；
– 提供服務、產品及優惠資訊給您，包括但不限於本公司之特別活動及推廣促銷；
– 將用戶資訊與為了其他目的或自其他來源（包括第三方）取得之資料進行比對，以優化本公司或LINE關係企業之服務；
之前本部落格在 2021/3 已經有文章投LINE廣告不用透過代理商了！會竊聽聊天訊息當廣告投放依據嗎？介紹過，LINE 的營收佔比最大部分不是賣貼圖、遊戲課金，而是廣告收入，台灣使用者又這麼多，會加入發票資料這塊戰場也不令人意外。
2023/9 新政策大約半年後，本文介紹的其中一款產品發票怪獸，在 FB 粉專發了一篇我們是發票怪獸開發團隊，針對近期所發生的「發票遲遲未進入APP」一事，提到財政部提供之API發票更新成功率為過往的10%以下，正積極與政府單位陳情與溝通..
以下是我於 2022/5 發的原始內文:
今天25號，又是統一發票開獎的日子，幾家歡樂幾家愁，社群網站上想必會看到有人 PO 這種圖片。
也會有人 PO 這個，一篇好幾年前(2020)年的討論串
這是不是在危言聳聽呢? 讓我來驗證一下，如果有人把發票照片給一間民間商業公司，或是把手機條碼載具編號&密碼給一間民間商業公司，就可以做出類似怎樣的線上應用。
註:本文是討論電子發票的「查詢」API，如果要找「開立」的，請找電子發票加值服務中心 內的訊航科技、鯨躍科技之類的，有的在年費、發票管理的軟體介面、一些雜項費用、是否有實體店面方案都不同，要自己查一下。
前言 : 先從一個活動網站需求說起
有一次接到一個行銷活動網站開發需求，消費者在特定通路買了特定商品，可以上活動網站登錄發票號碼、個資聯絡資訊…等等，工作人員(我)會公正的定期抽出中獎者並通知。
消費登錄抽獎這個題目基本上已經做到爛掉，市面上有各種網頁系統、聊天機器人、現成的 Saas，節省一點的直接用 google 表單，幾乎沒有什麼新意。但是因為通常包含活動策畫提案、媒體廣告預算、平面印刷物製作、網頁視覺設計、網頁系統…，要忙的可多了，辦活動讓行銷部門感覺比較有在做事，不是整天在社群網站發廢文、在電腦前不知道幹什麼(看報表)，所以還是會常常看到這類活動。
這次窗口給了一個範例網站，台灣的其他廠商在舉辦類似的活動，我發現裡面有2個神奇的功能:
1.輸入手機條碼載具編號和密碼，然後自動讀取載具內的電子發票是否有符合參加資格，也就是消費者不用一筆一筆去登錄發票號碼、購買日期…什麼的，只要輸入載具資訊，就可以參加抽獎。本來發票都習慣存載具的人，也不用為了參加抽獎活動特別去印出來。
2.把電子發票的正面拍照上傳，系統會檢查電子發票是否有符合參加資格，而且實測功能應該是能用的，拿加油站的發票拍照上傳果然判定不符合參加活動，但是還可以申請人工審查。
功能看似非常先進，但獎品很空虛，搞不好那個網站開發預算比獎品費用還高，但是網站開發一次，日後換個視覺樣式還有機會繼續用，獎品之類的都是消耗性預算。但這不是重點，總之先評估看看能不能製作。
仔細想想，覺得這種判斷方式好像很雷?
1.有些店的電子發票不一定在購買消費當下立刻開立並上傳到財政部，消費者買完東西出來要登錄發票，阿怎麼登錄不進去? 發票無效? 明明是店家還沒上傳電子發票，又是活動網站的客服或工程師要背鍋了。
2.承上，例如有人趕在活動期間最後一天晚上才去買，而店家的發票時間就是已經過了活動期間才開立，程式要怎麼驗證消費時是在活動期間內呢? 傳統抽獎登錄作法很單純，資料要儲存時若超過活動登錄時間，就是不給你 SQL INSERT，那現在改成判斷不知道何時會變動的 API 資料來源?
3.發票明細的品名仰賴店家自由心證，還有各種系統限制，要是店家品名亂打，程式要怎麼確定這張發票有買某某特定口味/規格? 又要再印一堆刮刮卡或是特殊包裝的商品嗎?
4.有些連鎖商店，開發票的店家名字是一些奇奇怪怪的名字，例如一般人認知的麥當勞、肯德基那個叫品牌名稱，或是有申請商標，但這些品牌名稱背後負責營運、登記稅籍資料的公司名稱，或是加盟分店的營業登記公司名稱，一般人可能沒聽過，那程式要怎麼確定這發票是在指定通路買的?
5.拍照辨識發票，碰到 QR Code 有印刷不好、折到…各種無法正常辨識影像的，還不是又要回到請使用者手工輸入發票號碼、購買日期的傳統方法?
可能就跟參考網站的人工審查一樣，還是要花費許多人力和客服待命。
但既然已經有人實做出來，就分析看看是怎麼做的?
一個最簡單的問題，可以從英文兩位數+8位數字發票號碼，就知道這張電子發票買了什麼東西嗎? 不行，還要再搭配發票的其他資訊(發票號碼+發票期別+開立日期+檢驗碼+店家統編+4位數隨機碼)，所以表單欄位不會減少，只會更多。
Google 查到財政部的「查詢電子發票」 API 可以做到輸入載具資訊，查詢載具裡面存的發票 ，API 還有提供其他功能，例如程式自動查詢某期發票中獎號碼、列出所有愛心碼的機構的清冊，透過使用者提供的發票號碼等基本資訊查詢明細、用消費者提供的載具編號和密碼，查詢那個月的電子發票是誰開立的、開立的電子發票明細…之類的。
這個 API 個人或公司行號都可以申請，而且不管發票是誰開立出去的，發票歸戶在誰的載具內，只要帶上對應的請求參數就可以查。
用發票資料當行銷數據庫可能不是新鮮事
電子發票應用程式介面使用規範都有明文寫到
六、 開發者應遵守注意事項
（一） 開發者利用或使用 API ，不得有違背法令或公序良俗、誤導社會大眾、妨礙或干擾第三人、侵害本中心利益或其他不當之行為。
（二） 開發者非依法令，不得於軟體產品及加值衍生著作下載、安裝及執行過程中，蒐集、儲存使用者之任何電子發票資料、使用紀錄及其他個人與營業資訊，並應避免前開資訊遭第三人使用、存取、發布或分享。
（三） 開發者應確保其提供與資訊平台之資訊，或其代替使用者執行軟體產品及加值衍生著作功能時，均已取得或已擁有使用者之同意或利用該資訊之必要權利。
（四） 開發者公開發行、展示或利用本中心 API 產生之軟體產品及加值衍生著作時，應以適當方式註明係由本中心授權。
（五） 開發者利用軟體產品或加值衍生著作應自行採取必要防護措施，且必須定期更新，以修復或防範安全性漏洞，並應以適當方式聲明本中心不擔保 API 使用之合適性、可依賴性、即時性、有效性及完整性。
（六） 開發者承諾，就 API 使用所為之相關研究或統計成果，無償提供本中心參考。
（七） 開發者承諾，如 有軟體產品使用目的或版本之變更，應通知本中心。開發者對於本中心提供之 API 如有其他建議，亦得一併提供。
有申請過的人也會不定期收到提醒，雖然我什麼壞事都沒有做
那回到一開頭的那則危言聳聽，一些民間的發票 app 其實都有拍照存發票的功能，也可以輸入手機號碼載具資訊然後查詢發票，理論上相關服務業者確實可以順便統計一下大家的發票裡面都買什麼東西，最後再統計出一些分析報告，賣給有需求的業者。
以下列舉幾個知名的發票 APP 跟所屬公司的「消費交易資料庫」行銷大數據相關商品介紹
1.引客數據 invos Data 的即時市場趨勢追蹤系統
粉專簡介開宗明義就寫說用發票資料做數據分析，那麼發票是從哪裡來的? 該公司另外還有幾個有名的產品，發票存摺和 Moneybook 麻布記帳，背後都是同一間公司，叫麻布數據。
(各位的發票都拿去當給人當素材了)
2.發票+的公司和角度數據
在創夢市集的新創專訪｜「發票特務」破關中 樂飛科技透過數據分析為品牌解鎖精準行銷中直接寫說「發票特務」APP是一個OMO(online merge offline)的生活平台，利用將發票載具任務遊戲化的方式，在蒐集與記錄消費者數據的同時，也讓品牌與顧客之間能以趣味的方式進行互動…
4.春樹科技的發票怪獸。有發票怪獸的企業合作方案和數據透MarTechGo
發票怪獸上了許多媒體報導、得了許多獎的，
他家產品 MarTechGo 還上了一些廣告雜誌報導，
「透過真實用戶數據加以分析品牌市佔狀況?」
「消費分析?」
「剖析真實消費行為?」
「為品牌客戶擴大行銷效益?」
現在大家看到這類行銷文案，在使用發票存摺類的 APP 時肯定別有一番風味。
這些只是做發票 APP 商品的民間公司，剛剛好也有提供一些廣告行銷數據相關服務而已，兩者的資料有沒有關聯、是否去識別化…等等就不得而知。
以前常說羊毛出在羊身上，但使用者用發票 APP 要付錢來支撐廠商的系統營運成本、資料儲存成本嗎? 不用。
幫使用者付錢的是一些有廣告投放或行銷活動需求的廠商，這就是前幾年最常講的一種網路商業模式：羊毛出在狗身上，豬來買單。
5.雲端發票與雲端行動科技股份有限公司的行銷科技服務 (ps.這家公司也是台灣100多家發票加值中心之一)
6.波波送點
7.發票集點王
這幾個比較接近，是在自己的發票 APP 裡面提供廣告版位曝光、行銷規劃、點數積分商城之類的，就是常常會跳廣告推播通知，APP 裡面卡一堆廣告，被人嫌又醜又難用，所謂觀感或 UX 很差、被社會唾棄的 APP，但是使用者個資看起來比較沒有被拿去其他地方賣錢。
反觀有些免費的發票 APP 裡面幾乎沒廣告，還會有每日簽到、一些回饋活動什麼的，廠商還會榮獲科技新創報導，消費數據可能都拿去變成他們家其他商品的數據研究資料來源之一，供我們這行用於規劃行銷活動、廣告投放、系統開發之類的做各種行銷決策用途，
然後大家還覺得這種沒廣告的發票 APP 很棒很好用?
資本主義真是太邪惡了。
還有兩個看起來比較新創、功能看似比較乾淨的
8.水滴發票 現階段看起來功能相對單純，真的只有存發票而已，這樣公司要怎麼賺錢哩?
9.aifian 享擁有 一樣是拍照發票上傳賺積分，不過他還有「資產庫」這個酷功能，能藉由平台媒合，進行物件的管理、租賃、購買、轉讓及回收
10.財政部電子發票 智慧好生活 服務平台
這個是政府自己的電子發票資料分析成果展示，有各種不同主題讓人公開瀏覽。
11.鷹眼數據有個 GUI發票數據系統，臉書貼文寫說「資料匯聚多個第三方雲端發票App」，號稱有四億筆以上的發票資料，但沒寫說是哪些發票 APP 出賣資料的。
12.國內知名財經平台 CMoney 和必富網(berich.com.tw)的發票載具 APP
標榜的是無廣告、發票對獎快速、消費加碼享回饋，但一樣會在發票載具的FB粉專 上用大家的發票資料，統計一些消費行銷數據。
APP 在 Google Play 的隱私條款，與公司內的其他商品共用Money錢管家 – 隱私權條款。
CMoney 不只是一個發佈財經新聞資訊的媒體業，背後是一個軟體公司，有許多設計與軟工職缺，App 市集中有非常多的產品，以下是人力銀行寫的資訊:
CMoney是全台最大財經軟體開發平台，擁有超過730萬名會員，以及各類型App、PC軟體，包含：籌碼K線、股市爆料同學會、以及與艾蜜莉、林恩如、陳重銘、權證小哥、愛德恩等財經達人合作的APP，還有CWMoney記帳與發票類的APP。
CMoney行銷部聚集各種專業數位行銷人才，包括內容運營、廣告投放、銷售活動規劃、用戶運營、拉新活動等，我們自操所有的行銷推廣，工作中有機會與各投資領域的財經達人合作，相信在這裡，能讓你找到最適合發揮的舞台。
商品如果是免費的，果然使用者就是商品…
用電子發票資料來做消費數據分析有參考性嗎?
生活中還有一堆免開發票的店家，更別提還有一堆為了怕發票開立失敗，為了保險起見，電子發票品名一律都用「XXX商品」的電商，或是某些產業為了隱私性，把消費品名明細都打得很籠統模糊的，分析發票這回事怎麼想都覺得有一定的失誤率，有一丁點不靠譜。
於是我又上網查一下可能還有哪些誤差跟偏差
研究後發現，玩弄發票、消費分析，似乎是不少商科、統計學科的碩博論文題目，不過國發會有一篇幾年前的期刊文章，初步證實了我的想法，確實有許多不準確的因素，有興趣的可以直接公開瀏覽: 由電子發票資料分析臺灣消費初探 – 黃鈺茹
摘錄幾點內文如下:
– 發現以電子發票計算之各縣市平均消費傾向，均明顯低於主計總處公布之數據，且由於各縣市所能取得之樣本數多寡，及電子發票普及程度不同，所呈現之邊際消費傾向也有相當大的差異。
– 零售業電子發票開立比重較高，2017 年達36.9%，餐飲業較低，為 28.9%。(各縣市又有2~4成不同的零售業電子發票開立比，詳見期刊內文)
– 每年導入電子發票之商家逐漸增加，電子發票張數、總金額持續上升，但並不代表消費持續增加，應排除廠商加入之效果，才能正確解讀民間消費的變化。
– 稅籍登記之行業別可能與實際營業項目不同，造成統計誤差。
– 發票品名不一致—不同商家的相同產品列示於電子發票之名稱可能不盡相同。
還有專業資料工程師的 這張發票透露了你的什麼訊息？ | 資料工程師的日常 一文中，也分析發票可以解讀哪些資訊，達成網路廣告業的精準行銷。
以下實測用財政部的查詢電子發票 API 做一些查詢發票資訊的實驗，看看拿使用者的發票當統計數據是否可行
用財政部的「查詢電子發票 API」從發票照片得到商品明細
API 也就是 Application Programming Interface 的縮寫，在應用程式和應用程式之間的溝通的手段，先來看一下要如何透過一張發票照片知道一個人買了什麼
從文件的「三、查詢發票明細」可以看到
喔，如果只有英文兩位數+8位數字發票號碼，而沒有發票開立日期、發票檢驗碼、商家統編、發票隨機碼，是壓根兒無法查詢別人的發票明細的。
但是如果我得到使用者上傳的電子發票照片，就有機會可以得到上面那些東西，看是要人工一張張辨識還是用公有雲的影像辨識，又去查了一下看有沒有其他專門搞影像辨識發票的，輸入發票照片，不只能辨識，還要把「發票號碼、發票開立日期、商家統編、發票隨機碼」格式自動整理好，例如把「2 0 2 2 – 0 4 – 1 9 1 7 : 3 4 : 2 7」變成API指定的格式「2022/04/19」
這種非常在地化、市場又小的東西，台灣竟然也有不少廠商在競爭了，像是力新號稱能處理台灣發票格式21-28，韜睿也有類似的 API 或本地部屬服務，不過台灣的 SaaS 服務比起國外的還是差一大截，什麼東西都沒有價錢，沒有試用，沒有立即可以看的公開 API 文件，什麼東西都要留資料洽詢，等留了資料又會看我的聯絡資訊是免費 email 或不是百大，當成我九成九只是來隨便問問，通常洽詢之後都沒人理。
從文件知道要從發票號碼查商品明細比想像中麻煩，需要至少快10個參數，少一個都不行。
其中有一個「發票檢驗碼 encrypt」，當 Type 為 QRCode 時為必填，這又是什麼? 文件上還沒寫範例? 查了一下才知道是電子發票底下有兩顆 QRCode，左邊那顆解析出來的字串，取第一個冒號前面的24個字，就是發票檢驗碼 encrypt。這又是一個眉角，寫在 電子發票證明聯一維及二維條碼規格說明 跟民間資料電子發票 API (三) 查詢發票表頭與明細 | brenthsieh.
以 HTTPS 協定對財政部電子發票整合服務平台網址：https://api.einvoice.nat.gov.tw/ 配上 3.查詢發票明細寫的要求路徑 /PB2CAPIVAN/invapp/InvApp，需求參數以 POST 傳送，回應以 JSON 方式傳送。
湊齊11個參數，簡單的透過一次呼叫，就成功得到一張發票的商品明細資料。
嗯…原來超商的兩件優惠，是用一個負數的商品品項來扣…
用財政部的「查詢電子發票 API」得到載具內發票的商品明細
有了載具編號和密碼，真的能得到一個人所有的發票，與每一張發票的購買明細嗎? 例如幾月幾月買了什麼尺寸的保險套。幾月幾號有旅館的發票?
使用各種民間公司開發出來的存電子發票的 app(如發票存摺、發票怪獸…)，還有一開頭的範例活動網站開發評估，都有一個功能：輸入載具編號和密碼，如下圖:
在財政部電子發票整合服務平台，一般消費者登入用的是「手機號碼」和密碼，而這類電子發票存摺 APP 都只有跟使用者要「載具編號」和密碼，雖然兩者的密碼是同一組東西，但「手機號碼」跟「載具編號」不一樣，應該沒差吧?
嗯，的確是沒差，反正一樣都可以取得使用者載具裡的發票跟商品明細。 用載具編號可以透過 API 全自動化撈取，還比較方便!
有的發票 APP 還要輸入手機號碼註冊，搞不好手機號碼就跟財政部電子發票整合服務平台的手機號碼是同一組呢。
各家使用者條款都有類似需要存入使用者密碼的文字，如下圖
為什麼使用發票 APP 要輸入載具密碼，
假如消費者不上傳照片，有什麼辦法知道使用者都買了些什麼?
這兩個其實是同一個問題，都需要參考財政部電子發票查詢 API 文件中的「六、載具發票明細查詢」
消費者不上傳照片，程式完全不知道發票號碼、日期等資訊的情況下，需要手機條碼/卡片(載具)隱碼、發票號碼、發票日期、手機條碼驗證碼/卡片(載具)驗證碼…等11項參數，才能一窺一張發票裡面買了什麼東西，但程式壓根沒有發票號碼、日期之類的，要怎麼查?
所以要回到文件「五、載具發票表頭查詢」
看到 cardNo 跟 cardEncrypt、cardType，現在就知道為什麼每個發票 APP 都會需要輸入載具編號和密碼，因為使用者給出載具編號和密碼之後，發票存摺 APP 程式就能透過 API 取得使用者這個月有幾張發票，還有要查詢每一張發票明細所需的必要資訊呀!
endDate 還要判斷這個月有幾號，不過用還沒到來的未來日期，也不會出錯，湊齊12項參數，之後初步拿到使用者這個月所有發票的表頭資訊。
本月所有發票的基本資料湊齊了，接下來要一張一張取得發票明細，但我們沒有每張發票的24個字那個檢驗碼，也沒有4個字的發票隨機碼，所以沒辦法沿用上一段的程式，要再透過「六、載具發票明細，得到發票明細」的參數說明，另外重寫一段…
成功取得發票明細和品名，嗯，金額還會有小數點，看來資料庫欄位不能開只能存整數的…
其他財政部電子發票查詢 API 的使用眉角
查詢發票明細需要使用者的密碼，這不是各家發票 APP 工程師的問題，而是 API 要求的必填資料就是這樣子，不然每個發票 APP 都會武功全廢，那財政部為什麼要這樣設計?
是怕例如有人拿到別人的手機條碼載具編號，就可以偷查到那個人的消費資訊，所以要拿使用者密碼當做多一道保護?
但這樣也導致使用者只要改個密碼，程式就無法透過 API 拿到新的發票資料了，我實在不太喜歡這種密碼當必要參數的 API 設計，一些郵件、簡訊的 API 也有這種情況，但凡使用者只要改個密碼，透過 API 運作的功能就整組壞了，
還有一個奇怪的開發雷點，例如有一張發票是存在信用卡的悠遊卡載具內，然後悠遊卡載具歸戶到手機條碼載具，所以用「五、載具發票表頭查詢」可以查得到這張發票。
但是在「五、載具發票表頭查詢」得到的資料，可以看到這張發票的 cardType 是 1K0001 (信用卡載具在這個 API 的代號)，cardNo 有一組沒看過的數字，但是在「六、載具發票明細查詢」步驟時，用這個參數是拿不到資料的，API 會回傳 {"v":"0.5","code":903,"msg":"參數錯誤"}，cardType 仍然要用 3J0002 跟手機條碼載具，才能得到發票商品明細資訊。
除了上述提到的，24個字那個檢驗碼要去另一份文件看才知道是什麼東西，存在悠遊卡載具的發票要用手機條碼載具當參數才能查，還有其他的特點:
– 申請時沒有任何域名限制，不用登記域名、呼叫 API 時也沒有限制域名、限制主機IP、限制接收回傳資料的網址，就算程式網址是 localhost 也可以正常取得資料。
– 每次要求只要一次往返就好，非常方便，沒有什麼 access_token 跟 refresh_token 之類的麻煩機制。
– 日期區間問題1，在「五、載具發票表頭查詢」的文件上說「限制開始及結束查詢時間為相同月份」，實測 startDate 跟 endDate 設超過一個月的 2022/01/01 跟 2022/02/28，不會得到任何錯誤訊息，但拿到的資料只會有2022/1月份的，故一次只能取一個月的敘述為真。
– 日期區間問題2，在「五、載具發票表頭查詢」的文件上有寫說最久可以查到查詢當日前 6 個月 1 日起的發票，文件給的範例是說例如今天是 9 月 5 日，那最早查詢起始時間為 3 月 1 日起。當我用 API 硬查超過半年的，實測會得到 {"v":"0.5","code":903,"msg":"參數錯誤"} 的訊息，但包含財政部自己的統一發票兌獎 APP ，基本上都可以看到載具裡超過半年前的發票，就不曉得大家是怎麼設計的。
– 不知道最遠可以查多久前的單張發票明細，現在是 2022/5，找出一張 2018 年的發票，用「三、查詢發票明細」還是查得到商品明細。
– API 不知道有沒有 limit rate，我不敢亂試，怕被鎖帳號。
– 使用者要授權給發票 app 或外部服務，沒有 token/過期時間之類的設計機制，所以每次發票 app 要查使用者有沒有新發票進來、消費分析，程式大概基本上就是讓使用者的密碼直接傳來傳去的，使用者能做的頂多就是改密碼，這樣發票 APP 就無法再透過 API 拿到之類的發票資料。
話說好像很難讓非軟工的人理解，使用者同樣在一個線上介面輸入帳號密碼，程式實際儲存跟拿來使用的，究竟是一組無法反解的特殊編碼字串、可以透過金鑰反解的加密字串、還是 token 或 access_key，還是原始的字串…這幾者的區別。
– 沒辦法從發票資料反查載具資訊，例如某發票開立時就屬於某組手機條碼載具，但即使有發票正面完整照片，也無法反查出所屬載具的資訊。
– 例如有人剛好知道我手機號碼，再配上密碼，去登入財政部 E-Invoice Platform電子發票整合服務平台，可以偷到什麼個資? 財政部 E-Invoice Platform電子發票整合服務平台 的個資有夠少，領獎設定裡面有銀行帳戶資訊，但是要先輸入身分證字號才能看，其他也沒有直接顯示會員個人的姓名、地址、身份證字號的地方。整個網頁裡面能拿到的資料跟從 API 能拿到的差不多，就是發票明細&歸戶的載具資訊。
– 以上方法只適用於查電子發票，不知道怎麼查那種很長一條的傳統紙本發票，所以不想消費資料被拿去分析的，就多多到免開發票，或是只有傳統紙本發票的店去消費? 不過發票 APP 也都很聰明，會要使用者輸入備註、金額，那輸入的備註會不會給數據分析人員看到? 就不得而知了。
結論
申請 API 只是用來自動判斷電子發票有沒有符合抽獎資格? 看來應該有不少更有趣的應用呢。
例如我腦洞大開，做一個輸入電子發票資訊可以推測今日運勢的，或是叫男女朋友兩個人都來輸入姓名、生日、拍一張臉的照片、手機條碼載具編號和密碼，然後診斷感情 match 程度的，然後這個診斷過程要跑三天三夜，需要留下手機或 email 等候通知，還可以留地址參加抽獎，這樣一整套下來，豈不是又來輕鬆收割一波個資?
發票明細只是消費資料而已，那行銷數據裡的年齡、消費者地址、性別是哪來的? 發票存摺的 app 註冊時通常有輸入聯絡地址、性別、生日的欄位啊，真的有什麼隱私問題，還不就是使用者自己提供的嗎?
用發票APP會導致密碼外洩? 密碼不也是使用者自己心甘情願輸入的嗎?
消費地點是哪來的? 發票明細的資料有賣方營業人地址(sellerAddress)呀，雖然有時候企業登記的地址跟商店地址可能有點差異，或是有的地址是「桃園市中壢區中美路二段157號及中豐路225號」，或是有的時候地址是空值(例如主機商或是 Apple iCloud+ 的發票)，這就屬於數據分析的偏差之一，不曉得統計時有沒有排除這些資料就是了。
消費商品類別是哪來的? 品名有滴雞精，這總該不會是寵物用品吧? 這應該算資料科學中的常講的資料前處理/資料清理，就雇個工讀生和實習生來弄就好了，剩下能用的，把規則理出來之後再用程式去分類或貼標就可以完成大半的工作。
(春樹科技是發票怪獸的開發公司，如果只是幫大家把發票存著，方便大家對獎，幹嘛還有請人來整理資料呢?)
回到最初那篇推特文章的問題點，這種民間公司的發票 APP 或是財政部的 API 功能可能有什麼問題?
1.使用者以為只是一個更方便的存發票、對獎的APP，沒仔細看條款、沒搞懂背後的軟體系統機制，結果把個人消費資料送給人家做 martech。
2.擔心民間發票 APP 公司內部監管不力，有人可以:
-輕易調閱會員資料
-根據會員資料，調閱所屬載具內的所有發票，進而知道特定某人哪一天、去哪邊、買了什麼東西
-依據載具號碼調閱該載具內的所有發票，進而知道特定某人哪一天、去哪邊、買了什麼東西
-檢視該人在發票上額外輸入的任何備註資料
-根據某商店開出的發票，反查出發票所屬會員的個人資料，及上傳的其他發票。(例如店員知道店裡某時間開出的一張發票，存在一個女子的某個發票載具編號內，然後店員剛好有某個民間發票 APP 的系統權限，就用發票號碼或載具編號去查詢民間發票 APP 的系統資料&女子的會員資料)
3.承上一點，當我的電子發票載具密碼(就是用來登入電子發票平台的密碼)，剛剛好我很懶，其他網路服務也用一模一樣的密碼，理論上有人就可以拿那組密碼來登入我註冊過的其他服務，可以先從社群網站、gmail、一些知名購物網站開始試，沒開 2FA 多因素驗證的網路服務，都可以讓人來去自如。
4.我把信用卡載具、一些網路購物的會員載具歸戶在手機條碼裡，這些也是可以透過 API 的「八、手機條碼歸戶載具查詢」查詢到的，我愛用的信用卡、在哪些網路購物註冊過會員，都被看光光，再透過發票 APP 裡面的會員卡條碼、記帳等功能，就有機會貢獻更精準的行銷受眾輪廓，發票 APP 可能是世界上最了解我的人了。
5.發票資料配上手機 APP 要求的權限，還能組合出怎樣的有效行銷數據? 我沒在開發 APP，這部分就不清楚了。
6.有那套 API 使用權限的程式開發人員，只要拿到別人的載具編號(例如有些人把載具條碼貼在手機背後，或是放在手機桌面吧?)，再猜到密碼，然後就可以看到別人每天的發票明細了，可用於監視情侶、小孩消費等各種不當用途。
發票存摺 APP 免費給大家使用，
是方便使用者使用各種理財小幫手服務、更快秀出載具條碼、更方便對獎?
還是使用者被拿來作為公司行銷數據平台的人柱力?
這就是話術跟包裝方式不同而已。