1. 為什么要在O2O票務(wù)系統(tǒng)里接入運(yùn)營商二要素核驗(yàn)做過O2O票務(wù)的人都知道這個(gè)行業(yè)最頭疼的不是高并發(fā)搶票也不是座位鎖定而是實(shí)名制合規(guī)。一場演唱會(huì)、一趟景區(qū)直通車、一次線下劇本殺只要涉及真實(shí)身份入場就繞不開“人證合一”這道坎。早些年大家用短信驗(yàn)證碼糊弄一下后來監(jiān)管收緊必須做身份證實(shí)名核驗(yàn)再后來發(fā)現(xiàn)光有身份證號(hào)還不夠——號(hào)碼可能是買來的、借來的、甚至是從某些渠道批量搞來的于是運(yùn)營商二要素核驗(yàn)就成了票務(wù)系統(tǒng)里繞不過去的一環(huán)。所謂運(yùn)營商二要素說白了就是姓名手機(jī)號(hào)拿去和運(yùn)營商數(shù)據(jù)庫比對(duì)確認(rèn)這個(gè)手機(jī)號(hào)是不是登記在這個(gè)人名下。相比身份證二要素姓名身份證號(hào)運(yùn)營商二要素的優(yōu)勢在于手機(jī)號(hào)是活的是人在用的能過濾掉大量“身份證是真的但人不對(duì)”的情況。對(duì)于票務(wù)場景尤其是需要現(xiàn)場核銷、入場檢票的O2O業(yè)務(wù)這個(gè)核驗(yàn)環(huán)節(jié)直接決定了黃牛能不能批量囤票、代搶能不能繞過實(shí)名。我接手這個(gè)項(xiàng)目的時(shí)候系統(tǒng)已經(jīng)有一套身份證實(shí)名認(rèn)證但黃牛依然能通過“收身份證收手機(jī)號(hào)”的方式繞過。問題出在兩點(diǎn)一是身份證核驗(yàn)只驗(yàn)號(hào)碼真?zhèn)尾或?yàn)持有人二是手機(jī)號(hào)沒有做歸屬核驗(yàn)隨便填一個(gè)能收短信的號(hào)就能過。后來我們決定接入海宇運(yùn)營商二要素V即時(shí)版用PHP做數(shù)據(jù)工程層的改造把核驗(yàn)鏈路重新梳理了一遍。這篇文章就把整個(gè)改造過程拆開講包括為什么選這個(gè)接口、PHP側(cè)怎么設(shè)計(jì)、踩了哪些坑、以及最后怎么把合規(guī)體驗(yàn)做順。適合誰看如果你是PHP后端、票務(wù)系統(tǒng)開發(fā)者、或者正在做實(shí)名合規(guī)改造的技術(shù)負(fù)責(zé)人這篇內(nèi)容可以直接抄作業(yè)。如果你只是好奇“運(yùn)營商二要素到底怎么玩”也能從里面看到完整的落地邏輯。2. 海宇運(yùn)營商二要素V即時(shí)版的核心機(jī)制與選型考量2.1 運(yùn)營商二要素到底核驗(yàn)什么先把這個(gè)東西講透。運(yùn)營商二要素核驗(yàn)輸入是姓名和手機(jī)號(hào)輸出通常是三種狀態(tài)一致、不一致、無記錄。一致代表這個(gè)手機(jī)號(hào)在運(yùn)營商側(cè)登記的機(jī)主姓名和你傳入的姓名匹配不一致代表號(hào)碼存在但機(jī)主不是這個(gè)人無記錄代表號(hào)碼不存在或者運(yùn)營商沒有收錄。這里有個(gè)細(xì)節(jié)很多人搞混運(yùn)營商二要素不是查身份證它查的是手機(jī)號(hào)的實(shí)名登記信息。也就是說如果一個(gè)人用別人的身份證辦了手機(jī)號(hào)那這個(gè)手機(jī)號(hào)的登記姓名就是別人的你拿本人的姓名去核驗(yàn)結(jié)果就是“不一致”。這恰恰是票務(wù)場景需要的——我們要確認(rèn)“買票的人”和“用手機(jī)的人”是同一個(gè)。海宇這個(gè)V即時(shí)版相比普通版最大的區(qū)別是即時(shí)性。普通版可能是異步回調(diào)或者有緩存延遲V即時(shí)版是同步返回毫秒級(jí)響應(yīng)。對(duì)于票務(wù)系統(tǒng)來說用戶點(diǎn)“提交訂單”之后你不可能讓他等幾秒鐘再告訴他核驗(yàn)結(jié)果必須是實(shí)時(shí)反饋。這也是我們選V即時(shí)版的核心原因。2.2 為什么不用身份證二要素或者三要素這里要解釋一下選型邏輯。身份證二要素姓名身份證號(hào)的核驗(yàn)成本低但問題是它只驗(yàn)證“這個(gè)身份證號(hào)是不是這個(gè)人的”不驗(yàn)證“這個(gè)人是不是在用這個(gè)手機(jī)號(hào)”。黃牛完全可以拿一批真實(shí)身份證信息配上虛擬手機(jī)號(hào)繞過身份證二要素。三要素姓名身份證號(hào)手機(jī)號(hào)當(dāng)然更嚴(yán)格但成本高而且很多票務(wù)場景不需要這么重。比如景區(qū)門票、展覽票用戶可能只是臨時(shí)買一張你讓他填身份證號(hào)手機(jī)號(hào)姓名體驗(yàn)太重轉(zhuǎn)化率會(huì)掉。運(yùn)營商二要素剛好卡在中間比身份證二要素多了一層手機(jī)號(hào)歸屬驗(yàn)證比三要素輕量成本也可控。我們實(shí)測下來運(yùn)營商二要素能攔掉大約70%以上的黃牛批量下單因?yàn)辄S牛手里的手機(jī)號(hào)大多是養(yǎng)號(hào)或者虛擬號(hào)登記姓名和買票姓名對(duì)不上。剩下30%是真人代搶那種只能靠限購和風(fēng)控策略補(bǔ)。2.3 海宇V即時(shí)版的接口特性海宇這個(gè)接口是HTTP POST返回JSON。核心參數(shù)就三個(gè)name、mobile、key或者簽名。V即時(shí)版的響應(yīng)時(shí)間實(shí)測在200-500ms之間取決于運(yùn)營商側(cè)的網(wǎng)絡(luò)。返回碼里1000代表一致1001代表不一致1002代表無記錄其他是異常。有一點(diǎn)要注意運(yùn)營商二要素的核驗(yàn)結(jié)果不是100%準(zhǔn)確的。因?yàn)檫\(yùn)營商數(shù)據(jù)更新有延遲比如一個(gè)人剛過戶手機(jī)號(hào)運(yùn)營商側(cè)可能還沒同步這時(shí)候核驗(yàn)就會(huì)失敗。所以我們?cè)跇I(yè)務(wù)層做了容錯(cuò)如果返回“無記錄”允許用戶走人工審核通道而不是直接拒絕。這個(gè)后面會(huì)細(xì)講。3. PHP數(shù)據(jù)工程層的架構(gòu)設(shè)計(jì)與核驗(yàn)鏈路改造3.1 整體鏈路怎么走原來的票務(wù)下單鏈路是這樣的用戶選票 - 填實(shí)名信息 - 提交訂單 - 身份證二要素核驗(yàn) - 生成訂單 - 支付。改造之后我們?cè)凇疤峤挥唵巍焙汀吧捎唵巍敝g插入了運(yùn)營商二要素核驗(yàn)并且把核驗(yàn)結(jié)果和訂單狀態(tài)綁定。具體鏈路用戶提交訂單攜帶姓名、手機(jī)號(hào)、身份證號(hào)PHP側(cè)先做本地格式校驗(yàn)姓名長度、手機(jī)號(hào)正則、身份證校驗(yàn)位調(diào)用海宇V即時(shí)版接口傳入姓名手機(jī)號(hào)根據(jù)返回碼決定下一步1000核驗(yàn)通過繼續(xù)生成訂單1001核驗(yàn)不通過返回錯(cuò)誤提示要求用戶確認(rèn)信息1002無記錄進(jìn)入人工審核隊(duì)列訂單狀態(tài)置為“待審核”其他記錄日志降級(jí)到身份證二要素核驗(yàn)允許下單但標(biāo)記風(fēng)險(xiǎn)這個(gè)鏈路的關(guān)鍵在于不能因?yàn)檫\(yùn)營商核驗(yàn)失敗就完全阻斷下單否則會(huì)誤傷真實(shí)用戶。我們的策略是“核驗(yàn)通過直接放行核驗(yàn)不通過攔截?zé)o記錄轉(zhuǎn)人工”這樣既保證合規(guī)又不影響正常轉(zhuǎn)化。3.2 PHP側(cè)的類設(shè)計(jì)我設(shè)計(jì)了一個(gè)OperatorVerifier類專門負(fù)責(zé)運(yùn)營商二要素核驗(yàn)。這個(gè)類不依賴框架純PHP方便在不同項(xiàng)目里復(fù)用。核心方法就一個(gè)verify($name, $mobile)返回一個(gè)結(jié)構(gòu)化的結(jié)果對(duì)象。class OperatorVerifier { private $apiUrl; private $apiKey; private $timeout 3; private $retryTimes 1; public function __construct($apiUrl, $apiKey) { $this-apiUrl $apiUrl; $this-apiKey $apiKey; } public function verify($name, $mobile) { $params [ name $name, mobile $mobile, key $this-apiKey, ]; $result $this-request($params); return $this-parseResult($result); } private function request($params) { $ch curl_init(); curl_setopt($ch, CURLOPT_URL, $this-apiUrl); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($params)); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_TIMEOUT, $this-timeout); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); $response curl_exec($ch); $error curl_error($ch); curl_close($ch); if ($error) { return [code -1, msg $error]; } return json_decode($response, true); } private function parseResult($result) { if (!isset($result[code])) { return [status error, msg 接口返回異常]; } switch ($result[code]) { case 1000: return [status pass, msg 核驗(yàn)一致]; case 1001: return [status fail, msg 姓名與手機(jī)號(hào)不一致]; case 1002: return [status unknown, msg 無記錄轉(zhuǎn)人工]; default: return [status error, msg 接口異常 . $result[code]]; } } }這個(gè)類里我加了timeout和retryTimes因?yàn)檫\(yùn)營商接口偶爾會(huì)超時(shí)。超時(shí)之后不能直接判失敗而是要走降級(jí)邏輯。retryTimes設(shè)1次避免重試太多拖慢整體響應(yīng)。3.3 數(shù)據(jù)庫表設(shè)計(jì)核驗(yàn)記錄必須落庫一是為了審計(jì)二是為了后續(xù)風(fēng)控分析。我設(shè)計(jì)了一張operator_verify_log表字段名類型說明idbigint自增主鍵order_idvarchar(32)關(guān)聯(lián)訂單號(hào)namevarchar(50)姓名脫敏存儲(chǔ)mobilevarchar(11)手機(jī)號(hào)verify_statustinyint0待核驗(yàn) 1一致 2不一致 3無記錄 4異常verify_codevarchar(10)接口返回碼verify_msgvarchar(100)接口返回信息request_timedatetime請(qǐng)求時(shí)間response_timedatetime響應(yīng)時(shí)間created_atdatetime創(chuàng)建時(shí)間姓名和手機(jī)號(hào)要做脫敏姓名只存姓星號(hào)手機(jī)號(hào)存前3后4。這是合規(guī)的基本要求別問為什么問就是踩過坑。4. 實(shí)操過程從零接入海宇V即時(shí)版4.1 申請(qǐng)接口與配置第一步是找海宇申請(qǐng)接口權(quán)限。需要提供企業(yè)資質(zhì)、使用場景說明審核通過后會(huì)拿到apiUrl和apiKey。這里有個(gè)經(jīng)驗(yàn)申請(qǐng)的時(shí)候把使用場景寫清楚是“票務(wù)實(shí)名核驗(yàn)”不要寫“用戶注冊(cè)驗(yàn)證”因?yàn)槠眲?wù)場景的審核通過率更高而且后續(xù)如果被抽查場景一致也省事。拿到key之后不要硬編碼在代碼里。我用的是環(huán)境變量配置文件的方式// config/operator.php return [ api_url env(OPERATOR_API_URL, ), api_key env(OPERATOR_API_KEY, ), timeout 3, retry 1, ];.env文件里配置實(shí)際值這樣不同環(huán)境測試、生產(chǎn)可以切換也避免key泄露。4.2 核驗(yàn)邏輯的完整實(shí)現(xiàn)在訂單提交的控制器里我這樣調(diào)用public function submitOrder(Request $request) { $name $request-input(name); $mobile $request-input(mobile); $idCard $request-input(id_card); // 本地格式校驗(yàn) if (!preg_match(/^1[3-9]\d{9}$/, $mobile)) { return response()-json([code 400, msg 手機(jī)號(hào)格式錯(cuò)誤]); } // 先做身份證二要素原有邏輯 $idVerify $this-idCardVerifier-verify($name, $idCard); if ($idVerify[status] ! pass) { return response()-json([code 400, msg 身份證核驗(yàn)失敗]); } // 再做運(yùn)營商二要素 $operatorVerifier new OperatorVerifier( config(operator.api_url), config(operator.api_key) ); $result $operatorVerifier-verify($name, $mobile); // 記錄日志 $this-logVerify($request-input(order_id), $name, $mobile, $result); switch ($result[status]) { case pass: // 核驗(yàn)通過繼續(xù)下單 return $this-createOrder($request); case fail: return response()-json([code 400, msg 姓名與手機(jī)號(hào)不匹配請(qǐng)確認(rèn)后重試]); case unknown: // 轉(zhuǎn)人工審核 return $this-createPendingOrder($request); default: // 接口異常降級(jí)處理 return $this-createOrderWithRiskFlag($request); } }這里的關(guān)鍵是降級(jí)邏輯。如果海宇接口掛了或者超時(shí)不能直接讓用戶下不了單而是允許下單但標(biāo)記風(fēng)險(xiǎn)后續(xù)人工抽檢。這個(gè)策略是我們和法務(wù)、運(yùn)營一起定的既保證合規(guī)底線又不影響業(yè)務(wù)連續(xù)性。4.3 人工審核隊(duì)列的處理對(duì)于返回“無記錄”的訂單我們建了一個(gè)人工審核隊(duì)列。運(yùn)營后臺(tái)可以看到這些訂單手動(dòng)核對(duì)用戶信息。審核通過后訂單狀態(tài)從“待審核”變?yōu)椤耙汛_認(rèn)”用戶可以繼續(xù)支付。這個(gè)隊(duì)列的處理時(shí)效我們定的是2小時(shí)內(nèi)因?yàn)槠眲?wù)場景用戶等不了太久。如果2小時(shí)沒審核訂單自動(dòng)取消釋放庫存。這個(gè)邏輯用PHP的隊(duì)列任務(wù)實(shí)現(xiàn)每10分鐘跑一次檢查超時(shí)訂單。// 隊(duì)列任務(wù)檢查超時(shí)未審核訂單 public function handle() { $timeout now()-subHours(2); $orders Order::where(status, pending_review) -where(created_at, , $timeout) -get(); foreach ($orders as $order) { $order-status cancelled; $order-cancel_reason 人工審核超時(shí); $order-save(); // 釋放庫存 $this-releaseStock($order); } }4.4 核驗(yàn)結(jié)果的緩存策略運(yùn)營商二要素核驗(yàn)是要花錢的每次調(diào)用都有成本。為了省錢我們對(duì)同一用戶做了短期緩存同一個(gè)姓名手機(jī)號(hào)24小時(shí)內(nèi)只核驗(yàn)一次。緩存用Rediskey是operator_verify:{md5(namemobile)}value是核驗(yàn)結(jié)果過期時(shí)間24小時(shí)。$cacheKey operator_verify: . md5($name . $mobile); $cached Redis::get($cacheKey); if ($cached) { return json_decode($cached, true); } $result $operatorVerifier-verify($name, $mobile); Redis::setex($cacheKey, 86400, json_encode($result));這個(gè)策略實(shí)測能省30%-40%的核驗(yàn)成本因?yàn)楹芏嘤脩魰?huì)在短時(shí)間內(nèi)重復(fù)下單比如選座猶豫、支付失敗重試。但要注意如果用戶修改了手機(jī)號(hào)或姓名緩存要失效否則會(huì)用到舊結(jié)果。5. 常見問題與排查技巧實(shí)錄5.1 接口超時(shí)怎么辦海宇V即時(shí)版雖然叫“即時(shí)”但運(yùn)營商側(cè)偶爾會(huì)抽風(fēng)超時(shí)率大概在1%-2%。我們的處理是超時(shí)后重試1次如果還超時(shí)走降級(jí)邏輯允許下單但標(biāo)記風(fēng)險(xiǎn)。這里有個(gè)坑不要設(shè)置太長的timeout。我一開始設(shè)了10秒結(jié)果用戶等10秒才拿到“核驗(yàn)失敗”體驗(yàn)極差。后來改成3秒超時(shí)就降級(jí)用戶幾乎無感。5.2 返回“無記錄”的比例太高如果發(fā)現(xiàn)大量訂單返回1002先檢查手機(jī)號(hào)是不是虛擬號(hào)段。虛擬號(hào)段比如170、171、165等在運(yùn)營商側(cè)登記信息往往不完整容易返回?zé)o記錄。我們的做法是對(duì)虛擬號(hào)段單獨(dú)處理直接轉(zhuǎn)人工審核不調(diào)用接口省成本也省時(shí)間。另外新辦的手機(jī)號(hào)也可能返回?zé)o記錄因?yàn)檫\(yùn)營商數(shù)據(jù)同步有延遲。這種情況只能靠人工審核兜底。5.3 姓名中有生僻字導(dǎo)致核驗(yàn)失敗生僻字是運(yùn)營商二要素的老大難問題。有些生僻字在運(yùn)營商側(cè)存儲(chǔ)的是拼音或者編碼你傳漢字過去就匹配不上。我們的解決方案是對(duì)生僻字做轉(zhuǎn)碼處理先嘗試傳漢字如果返回不一致再嘗試傳拼音。這個(gè)邏輯寫在OperatorVerifier里作為兜底策略。if ($result[status] fail $this-hasRareChar($name)) { $pinyinName $this-convertToPinyin($name); $result $this-verify($pinyinName, $mobile); }5.4 并發(fā)調(diào)用導(dǎo)致接口限流海宇接口有QPS限制具體多少要看合同。我們一開始沒注意大促的時(shí)候并發(fā)調(diào)用直接把接口打限流了返回大量異常。后來加了令牌桶限流用Redis實(shí)現(xiàn)控制在合同約定的QPS以內(nèi)。$bucketKey operator_verify_bucket; $bucket Redis::get($bucketKey) ?: 0; if ($bucket $maxQps) { // 超過限流走降級(jí) return $this-degrade(); } Redis::incr($bucketKey); Redis::expire($bucketKey, 1);5.5 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案接口返回超時(shí)運(yùn)營商側(cè)網(wǎng)絡(luò)波動(dòng)查看curl_error日志重試1次超時(shí)降級(jí)大量返回1002虛擬號(hào)段或新號(hào)統(tǒng)計(jì)手機(jī)號(hào)號(hào)段分布虛擬號(hào)段轉(zhuǎn)人工姓名核驗(yàn)不一致生僻字或姓名順序?qū)Ρ扔脩糨斎牒瓦\(yùn)營商返回嘗試拼音轉(zhuǎn)碼接口返回限流QPS超限查看接口返回碼加令牌桶限流緩存導(dǎo)致結(jié)果錯(cuò)誤用戶修改了信息檢查緩存key是否包含姓名手機(jī)號(hào)修改后清除緩存6. 合規(guī)體驗(yàn)優(yōu)化的幾個(gè)關(guān)鍵決策6.1 用戶提示文案怎么寫核驗(yàn)失敗的時(shí)候提示文案很關(guān)鍵。寫“姓名與手機(jī)號(hào)不匹配”用戶會(huì)懵寫“請(qǐng)確認(rèn)手機(jī)號(hào)是否本人實(shí)名”用戶才知道怎么改。我們的文案是您填寫的手機(jī)號(hào)與姓名不匹配請(qǐng)確認(rèn)手機(jī)號(hào)是否為本人實(shí)名登記。如果剛過戶請(qǐng)等待24小時(shí)后再試。這樣既解釋了原因又給了解決方案還降低了客服壓力。6.2 核驗(yàn)失敗后的重試策略用戶核驗(yàn)失敗后不能讓他無限重試否則會(huì)被黃牛用來試探。我們的策略是同一用戶24小時(shí)內(nèi)最多核驗(yàn)3次超過就鎖定需要聯(lián)系客服解鎖。這個(gè)限制寫在Redis里key是用戶IDvalue是核驗(yàn)次數(shù)。6.3 和風(fēng)控系統(tǒng)的聯(lián)動(dòng)運(yùn)營商二要素核驗(yàn)結(jié)果會(huì)同步到風(fēng)控系統(tǒng)。如果同一個(gè)手機(jī)號(hào)關(guān)聯(lián)了多個(gè)不同姓名或者同一個(gè)姓名關(guān)聯(lián)了多個(gè)手機(jī)號(hào)風(fēng)控系統(tǒng)會(huì)標(biāo)記為高風(fēng)險(xiǎn)后續(xù)下單直接攔截。這個(gè)聯(lián)動(dòng)是通過消息隊(duì)列實(shí)現(xiàn)的核驗(yàn)完成后發(fā)一條消息到風(fēng)控隊(duì)列風(fēng)控系統(tǒng)異步處理。6.4 數(shù)據(jù)脫敏與存儲(chǔ)合規(guī)前面提到過姓名和手機(jī)號(hào)必須脫敏存儲(chǔ)。我們的做法是核驗(yàn)日志里只存脫敏后的信息原始信息不落庫。如果后續(xù)需要審計(jì)通過訂單號(hào)關(guān)聯(lián)到用戶表用戶表里的信息是加密存儲(chǔ)的。加密用AES-256密鑰存在KMS里不在代碼里硬編碼。7. 實(shí)際運(yùn)行效果與后續(xù)擴(kuò)展方向這套改造上線之后黃牛批量下單量下降了約75%人工審核隊(duì)列每天大概200-300單審核通過率在60%左右也就是說有40%的“無記錄”訂單確實(shí)是風(fēng)險(xiǎn)訂單。整體下單轉(zhuǎn)化率只下降了不到2%因?yàn)榇蟛糠终鎸?shí)用戶都能通過核驗(yàn)少數(shù)無記錄的走人工審核也能完成下單。后續(xù)我們計(jì)劃做兩件事一是把運(yùn)營商二要素和活體檢測結(jié)合對(duì)高風(fēng)險(xiǎn)訂單要求人臉核驗(yàn)二是把核驗(yàn)結(jié)果和用戶信用分綁定信用分高的用戶可以直接跳過核驗(yàn)提升體驗(yàn)。這兩個(gè)方向都在測試中等跑通了再分享。我個(gè)人在實(shí)際操作中的體會(huì)是運(yùn)營商二要素不是萬能的但它是票務(wù)合規(guī)里性價(jià)比最高的一環(huán)。關(guān)鍵是要把降級(jí)邏輯和人工審核做好不能因?yàn)楹蓑?yàn)失敗就一刀切拒絕用戶。另外緩存和限流一定要做否則成本會(huì)失控。最后再分享一個(gè)小技巧把核驗(yàn)日志和訂單日志分開存儲(chǔ)核驗(yàn)日志可以定期歸檔訂單日志要長期保留這樣既滿足審計(jì)要求又不會(huì)讓主庫壓力太大。