禮品卡平台無中斷移轉:餘額、資料與延續性

禮品與忠誠度方案可以在顧客毫無察覺的情況下更換平台——前提是在任何資料搬動之前,先把餘額、卡片庫存與資料格式對應清楚。

移轉首先是一項資料對應工作

Ogloba 已為零售商建立一站式的移轉路徑,可將既有的禮品與忠誠度方案、有效卡片餘額與卡片庫存,從原有平台整體搬遷過來。工作的起點是把舊系統的資料對應到 Ogloba 的資料結構(schema),由此產出擷取與載入的設計——也就是把舊有格式與新系統的需求逐一對照。程式化的移轉可能分成許多階段,但最基本的形式就是從舊系統讀出、寫入新系統。實務上的限制很少來自技術。能否延續,取決於原供應商是否配合,或零售商自己的 IT 團隊是否有能力把資料匯出。

當轉換不是解答

並不是每一個方案都需要轉換。當地法規若要求第三方處理商必須繼續存在,那麼要改變的是介接方式,而不是資料。2013 年為一家中國大型零售連鎖交付的行動禮品卡方案就是這樣運作:以專屬 API 將 Wincor 結帳系統連到 Ogloba,餘額查詢與交易查詢則由 China Union Pay 的 Web 服務處理。在櫃檯,收銀機把卡號 PAN 與持卡人的手機號碼傳給 Ogloba,由 Ogloba 把卡片送到手機上——必要時則以簡訊傳送應用程式商店連結。

移轉風險多半是資料對應的問題。及早解決,顧客就不會察覺這次更換。

FAQ

搬移任何餘額之前,必須先完成哪些對應?

每一種舊有資料格式都要先與 Ogloba 的資料結構對照。這份對應正是擷取與載入設計的來源,涵蓋有效餘額、卡片庫存,以及附帶其上的方案規則。

平台移轉最常被什麼拖延?

通常不是技術。常見的限制是把資料從原有系統取出——不是原供應商願意配合,就是由零售商自己的 IT 團隊執行匯出。

什麼情況下轉換資料是錯誤的作法?

當地法規要求第三方處理商必須繼續留在架構中的時候。此時方案改變的是介接方式而非資料,既有的處理商仍在底層持續運作。

後端平台更換時,結帳流程如何維持不變?

靠收銀機與平台之間的專屬 API。在一項中國零售的導入案中,櫃檯把卡號 PAN 與持卡人手機號碼傳給 Ogloba,由 Ogloba 將卡片送到手機,結帳流程完全不必更動。