四合一會員儲值支付系統成功案例分享

　　筆者有幸於去年承接一家全台有兩百多間門市的大型便當業者，規劃設計其會員之訂餐支付等相關的管理資訊系統，並於去年順利結案使用至今。本文目的即是將這系統建置過程說明一二，供一些有被電子支付、晶片卡、條碼...搞得不知怎辦？但確有需要建置此類系統，以促進業績的商家參考。

　　在敘述系統之前，先說明對此系統思考的關鍵所在，以便讀者能掌握後續為何如此設計的原因。

1. 思考即是為何還需要卡片？

這問題對這家飯包業者而言，來買便當的不乏老人與小孩，不一定使用手機，卡片還是最方便的使用方式，而且此家還要推每日供一餐或兩餐的公益卡，考量使用晶片卡是很合理。

2. 為何不直接使用目前興起的電子支付？

不是同樣有卡片（一卡通）嗎？，這問題要細究，電子支付其實就只是支付，對消費者是方便但對商家的幫助卻不大，因資料庫不是自己的，活動辦法也不能自訂，如這家每日一餐或兩餐的公益卡，或是特定飯包優惠期間等。

3. 為何不仍如過往自行製作會員卡，而使用悠遊卡等市面有的卡？

關於這點要探討會員卡何以日漸式微，筆者認為一者是浮濫，極盛時幾乎人人身上一堆卡，尤其家庭主婦，再者更重要原因是卡片成本，只有少數如星巴克能賣卡片外，其他店家現下只能送，一張30元成本，幾萬會員下來所費甚鉅，所以商家目的既是讓消費者方便多消費，能使用隨身有的卡如悠遊卡何樂不為。

4. 真的可以幾乎所有卡都可以來登入會員？

這問題要先說明一下，現在市售讀卡器多可讀許多種卡，甚至手機只要有NFC也可以讀取，筆者試過只有金融卡不行其他包括一般各式會員卡，悠遊卡，甚至電梯門禁這種附在鑰匙圈中的晶片卡也可。當讀卡器讀取時會傳回一組唯一的識別ID，稱為UID，系統只要能辨識就可連接會員相關資料，完成整個系統運作。

　　談完了對於這套系統思考的問題點後，現在就來說明這套系統的建置，軟硬體需求大致示意如下圖：

　　其中獨立出的子系統計有「POS點餐交易」、「會員手機訂餐交易APP」、「雲端訂餐交易」、「後台管理統計」、「外送員手機收款APP」最後加上前述各子系統共同呼叫的「API-WCF 核心」組成，各子系統功用說明如下：

1. 「API-WCF 核心」子系統：

先說這部分是因其為現下軟體工程較佳製作方式，主要目的是讓各子系都能呼叫相同核心，不必各自為政，如上述的POS、前台手機APP、線上訂餐及外送APP這些都有消費支付交易，試想若是各自有處理程序並更新資料庫，一旦程式更改很容易出錯，系統也不穩定。

所以本系統建置首要即是撰寫並測試此API-WCF核心，將其他子系統所需各功能寫於API中，然後各子系統再依測試範例套上作業畫面即可，如此製作的系統又快又穩又好。

2. 「POS點餐交易」子系統：

顧客到門市點餐然後支付，POS系統即是執行此項功能，當顧客點完餐支付時即出示卡片，顧客可用自己的卡片或臨櫃購買悠遊卡，首次使用需先開卡，以便使卡片UID與資料庫虛擬卡號結合，下次使用時即可識別。完成的作業畫面如下圖：

3. 「會員手機訂餐交易APP」子系統：

顧客除了於門市刷卡消費外，也可以不帶卡片，使用手機由手機出示卡片的二維條碼來讀取交易。當然，過程必需要讓卡片與顧客綁定，首先使用APP註冊為會員，然後輸入卡片驗證碼，使卡片與會員綁在一起，於消費時即可使用二維條碼進行交易。使用手機APP好處除可不帶卡片，更可時時查詢卡片餘額。除此之外，系統一併將線上訂餐功能放入，完成的畫面如下：

4. 「後台管理統計」子系統：

系統運作前必需設定，運作後必需查詢統計，尤其帳務方面，必要時還要調帳，凡此總總都納入後台管理子系統中，由系統維護人員操作。完成後畫面如下：

5. 「外送員手機收款APP」子系統：

因是飯包業者，會有外送需要，而外送仍需要結帳收款，此與門市消費支付無異，特別的是雖不透過POS電腦掃碼槍或讀卡機，但仍有讀卡掃碼的需要，此幸好目前手機只要有NFC功能的皆可讀卡，而掃條碼更是手機已有功能。完成後如下圖：

6. 「雲端訂餐交易」子系統：

此即標準使用個人電腦上網進行訂餐及支付，此部分只要能鍵入會員帳號密碼即可交易，與傳統網站並無不同。完成後如下圖：

　　以上即是此實際案例的建置內容，因筆者從事此行業，了解商家對於導入會員系統以促進消費的認知是無庸置疑，但對於卡片及讀卡設備花費鉅大，使用電子支付方案又無法自有資料庫自訂活動，凡此總總，對會員系統望而卻步，實在遺憾。

　　商家若有幸能看到此文，知道卡片可用已有的，多用途讀卡器幾百塊一個，手機更是功能愈強大，建置如上看似龐大的會員系統實花不了多少錢，如此而能勇於建置系統以助企業成長，實是筆者撰寫此文之價值所在。