一、技術挑戰
雖然虛擬校園卡可以通過微信、支付寶等互聯網產品的成熟技術架構實現認證、支付等基本功能，但這並不意味著大學可以"拎包入住"，或是"拿來即用"。
要使虛擬校園卡建設可持續發展，高校要特別重視與技術相關的基礎設施建設。
在實踐中，我們認為虛擬校園卡存在以下技術挑戰：
1.虛擬支付的財務問題
引入虛擬校園卡的重要目的之一是引入微信/支付寶等移動虛擬支付功能，開放線上線下，提升師生支付體驗。
引入支付將不可避免地涉及會計問題。傳統上，校園卡系統與學校財務系統之間存在成熟的對賬系統。虛擬支付的引入應采用什麼樣的對接模式和兩種方案。
（1）校園卡系統對接
該方案實際上是將虛擬校園卡作為整個校園卡系統的子模塊。使用虛擬校園卡的金額必須由校園卡系統充值。虛擬校園卡的消費也是通過校園卡系統產生的。校園卡系統將與學校財務系統進行對賬。
（2）與財務系統直接對賬
該方案將虛擬校園卡視為學校支付系統的獨立應用系統，並直接與財務系統對接會計。由於微信/支付寶等互聯網支付產品相當完善API界面，所以虛擬校園卡的支付訂單可以直接與校園支付平臺對接，財務方面可以直接獲得虛擬支付的流程明細來核對賬戶 方案一大型的優點是不會"驚動"沒有跨部門協調的成本。信息辦公室的內部系統相對更容易操作。然而，由於虛擬校園卡是一項純在線業務，如果校園卡系統的會計基於數據庫，則兩者之間的對接相對容易。如果校園卡系統的賬戶是基於卡的，那麼兩者結構上存在自然矛盾。無論如何調整，都很難有一個完美的計劃來完全保證賬戶的一致性。在方案二中，師生可以直接在微信/支付寶上使用錢包。支付模式與其他場景沒有區別。用戶體驗最好，賬戶最準確。然而，在這一計劃下，財務系統必須涉及接口對接的調整，因此跨部門協商是不可避免的。 從"玩一玩"，做個"試驗"從角度看，部門內部操作當然更容易落地，更容易快速實現"DEMO"。然而，從信息頂層設計的角度來看，我們不能避免跨部門的業務集成，因為信息的核心是過程的再造。在定位方面，支付平臺是承擔校園支付業務的整合作用；在體驗方面，直接連接虛擬校園卡的用戶體驗是最好的。因此，我們認為方案二是更合適的選擇。
二、身份數據對接問題
虛擬校園卡的本質是校園用戶身份屬性對虛擬空間的映射。
隨著虛擬校園卡業務的推廣，越來越多的業務需要獲取用戶的身份信息進行更準確的授權。傳統上，我們將向虛擬校園卡系統同步用戶屬性信息，虛擬校園卡系統提供身份數據接口。
如果沒有增量接口，數據同步必然會滯後一天。
對於一些時間敏感的業務（如會議室預約等。），數據滯後可能導致業務無法正常使用。
另一種模式是虛擬校園卡ID實時推送到用戶基礎數據庫，即作為用戶基礎數據的一部分，然後用戶基礎數據庫直接提供身份接口對接應用程序。該方案可以保證數據的實時性，消除多餘的接口（對於應用程序系統），但需要修改用戶基礎數據的結構，以增加虛擬校園卡ID如圖4所示。
信息基礎設施--API網關
事實上，在所有的信息化建設中，技術挑戰最關鍵的部分是數據對接，即數據對接API的治理。
在API統一的治理API承載一切的網關API對接業務，提供統一的授權、流程控制和聚合能力；
具體數據由業務系統提供API接口，通過API網關進行具體的路由調度，由業務系統維護數據，保證數據質量。
每個提供數據的業務系統都可以被視為數據"生產者"，每個需求數據的業務系統也可以被視為數據"消費者"。
連接"消費者"與"生產者"之間的即為API網關。API基於用戶授權，網關應提供多種不同的授權模式oAuth二、基於應用授權internaltoken等等；#p#分頁標題#e#
API網關應提供流控限速等控制能力，減輕後端數據接口的負擔；同時，結合聚合API，API網關可以提供數據聚合能力，簡化"消費者"數據調用。
從誰提供數據和誰管理數據的角度來看，數據制造商API接口由業務系統本身負責。
然而，我們應該考慮實際情況。信息基礎設施的推廣不能一刀切地拒絕舊系統。
對於新建的應用系統，我們需要開放API能力並接入API網關。
不支持API對於接口舊業務系統，我們可以由信息部定制開發相應的系統API快速納入接口API開放系統，督促應用系統盡快整改，後期提供API開放能力。
這逐漸過渡到所有業務系統都是原生提供的API開放能力。
綜上所述，校園卡的虛擬化隻是學校信息化建設的冰山一角。就虛擬卡本身而言，實際上是基於信息化建設應用場景身份識別方式的變化，涉及到各種身份識別方式（包括實體校園卡、虛擬校園卡、指紋識別、人臉識別、虹膜識別等）的關聯。）從內部用戶身份的獨特性到技術的發展；另一方面，更重要的是，如何進行背後的頂層設計，以虛擬校園卡為建設內容的一部分，實現基礎數據、身份認證和行為數據的統一，以更科學的技術架構支持校園信息化的可持續發展。
<制卡熱線

1369164563全國服務熱線
商業合作:15112655843（微信同號）
<