TICKET · 一次性憑證核銷引擎
到場驗證、課程扣點、票券兌換、集點入帳——同一套核銷引擎，五個場域的變體。
沒有 AI 判讀，也不需要。憑證是你發的，我們驗的是數學。
已完成開發與客戶驗收 · 內測準備中
本頁所有能力皆有可指認的程式碼路徑，見頁尾技術證據表。
下面五張卡的欄位完全一樣：誰掃、掃什麼、驗什麼、失敗時螢幕上寫什麼、月底對帳看哪一欄。
我們刻意不讓任何一張看起來比較厲害——你要比較的是「哪一張長得像我的現場」。
第三方報名名單（CSV）可匯回主系統做差集對帳，避免「平台說 300 人、現場只掃到 240 人」無解。
票券簽章刻意不綁使用者——只簽票券碼與活動 id，所以票可以轉讓給朋友，而簽章仍然驗得過。驗證用時序安全比較（timing-safe compare），零第三方依賴。
防重複領有兩道——資料庫層的複合唯一鍵（使用者 × 券 × 通訊軟體帳號），加上前端裝置指紋。兩道都過不了才算領到。
AMAX 尚未交付過展覽案。這張卡描述的是引擎既有能力（多入口、多場次、逐憑證）在此場域的套用方式，不是既有案例。
門禁涉及個資與人身安全，導入前需要一次法遵與硬體評估。同上，這是適用場景說明，不是既有案例。
上面五個場域，換掉的只有「驗什麼」的規則。核銷本身——那個決定「這張到底能不能用」的動作—— 五個場域跑的是同一段程式碼，而且它不在應用程式裡，在資料庫裡。
活動入口有兩個人在收票。同一張券被截圖轉傳，兩支手機在同一秒各掃了一次。
如果核銷寫成「先查這張用過沒 → 沒有 → 那就標記成已使用並入帳」， 這兩支手機會在「查」的那一刻同時得到「還沒用過」，然後各自入帳一次。 這不是機率問題，是設計問題；活動當天人越多，它越會發生。
AMAX 的做法
示範 · 同一張票掃兩次
TK-8F2A-0C41
這是踩過的坑：把整串網址包進 QR，掃出來的字串會與資料庫存的對不上， 而且失敗訊息會長得像「找不到這張券」，讓現場人員以為系統壞了。
重複核銷回的是明確的狀態（何時、被誰、在哪裡核銷），不是安靜地成功、也不是丟一個 500。 現場人員需要的是「這張誰用掉了」，不是「錯誤代碼 409」。
憑證的產生與驗證都在你控制的那一側，前端只是顯示。
這兩件事有專屬的資料庫 migration，代表它們是被設計進來的功能， 不是「請工程師去後台改一下」。
一個核銷系統會不會出事，通常不是看它正常時多好用，是看它出錯時你有沒有正規的回頭路。
目前的核銷需要連線。核銷的原子性由資料庫保證，這是它擋得住重複核銷的原因， 也是它現在無法離線的原因——離線裝置無法知道另一台裝置在同一秒做了什麼。
AMAX 尚未實作離線核銷。我們不會在這一頁上寫「支援離線」。
場域自備網路：多數展場提供工作人員專用 Wi-Fi；行動網路分享通常足以支撐核銷流量 （每次核銷的傳輸量極小）。
降級為記錄模式：斷線時改為記錄掃到的憑證碼與時間，恢復連線後批次核銷。代價要講清楚：這段期間無法即時擋下重複使用，重複會在批次入帳時才被發現並標記。
關鍵閘口不離線：付費入場、餐券兌換這類直接對應金額的閘口，建議一律維持連線； 人流計數這類事後可補的，才使用降級模式。
如果你的場域確定沒有網路，請在第一次通話時就說——這會直接影響方案，我們不會事後才告訴你。
核銷系統真正被檢驗的時刻不是活動當天，是月底那個要簽名的人問「這個數字怎麼來的」。
欄位設計示意，數值為示例值，非實際客戶資料
| 憑證碼 | 類型 | 核銷時間 | 核銷人 | 場域 | 狀態 | 入帳 | 備註 |
|---|---|---|---|---|---|---|---|
| TK-8F2A-0C41 | 課程票 | 08/12 19:02 | 櫃檯 A | 中山館 | 已核銷 | +1 堂 | — |
| TK-8F2A-0C41 | 課程票 | 08/12 19:02 | 櫃檯 B | 中山館 | 重複掃描 | 0 | 同一秒第二次掃描，未入帳 |
| TK-33B9-71E0 | 餐券 | 08/12 12:41 | 店員 C | 信義店 | 已核銷 | −1 張 | — |
| TK-33B9-71E0 | 餐券 | 08/13 12:05 | 店員 D | 南港店 | 已使用 | 0 | 已於 08/12 在信義店核銷 |
| TK-5A17-9D22 | 報到碼 | 08/12 09:41 | 工作人員 E | A 館入口 | 已撤銷 | 0 | 09:43 由 主管 F 撤銷，原因：掃錯人 |
我們寧可在第一次通話就講清楚不適用，也不想在活動當天讓你發現。
20 分鐘。你講一次現場怎麼跑——誰掃、掃什麼、出錯時現在怎麼處理、月底誰在對帳。 我們會直接告訴你這套適不適用，以及哪一段要客製。
目前狀態：已完成開發與客戶驗收，內測準備中。本頁不宣稱已上線服務中。