# 離線刷臉簽約狀態(tài)變更回調(diào)
# 1. 接口規(guī)則
● 認(rèn)證方式：HTTPS協(xié)議，SHA256 with RSA進行簽名；
● 返回和提交數(shù)據(jù)的簽名，商戶號，時間戳，隨機串等在HTTP頭中傳遞；
● 提交和返回結(jié)果采用JSON格式；
● 字符集默認(rèn)使用UTF-8，請勿使用其它字符集；
● 交互的返回和回調(diào)數(shù)據(jù)都需要校驗簽名。
# 2. 離線刷臉回調(diào)通知-用戶簽約狀態(tài)變更通知API
# 2.1 應(yīng)用場景
刷臉用戶在完成簽約或解約后，微信會通知商戶用戶簽約狀態(tài)變更。商戶需要接收處理，并返回應(yīng)答。出于安全的考慮，我們對數(shù)據(jù)進行加密，商戶需要先對通知數(shù)據(jù)進行解密，才能得到用戶簽約狀態(tài)信息。
對后臺通知交互時，如果微信收到應(yīng)答不是成功或超時，微信認(rèn)為通知失敗，微信會通過一定的策略定期重新發(fā)起通知，盡可能提高通知的成功率，但微信不保證通知最終能成功。
注意：同樣的通知可能會多次發(fā)送給商戶系統(tǒng)。商戶系統(tǒng)必須能夠正確處理重復(fù)的通知。
推薦的做法是，當(dāng)商戶系統(tǒng)收到通知進行處理時，先檢查對應(yīng)業(yè)務(wù)數(shù)據(jù)的狀態(tài)，并判斷該通知是否已經(jīng)處理。如果未處理，則再進行處理；如果已處理，則直接返回結(jié)果成功。在對業(yè)務(wù)數(shù)據(jù)進行狀態(tài)檢查和處理之前，要采用數(shù)據(jù)鎖進行并發(fā)控制，以避免函數(shù)重入造成的數(shù)據(jù)混亂。
# 2.2 簽約狀態(tài)變更通知業(yè)務(wù)序列圖
簽約: 服務(wù)商可以通過簽約小程序引導(dǎo)用戶完成簽約. 此時微信離線刷臉業(yè)務(wù)系統(tǒng)將會發(fā)送簽約變更狀態(tài)給到服務(wù)商提供的回調(diào)地址。
解約: 解約入口有兩個，一個是微信用戶通過微信客戶端發(fā)起解約，一個是商戶通過調(diào)用后臺API接口進行解約。解約后，微信K12業(yè)務(wù)系統(tǒng)將發(fā)送簽約變更狀態(tài)給到服務(wù)商提供的回調(diào)地址。
以下是簽約通知狀態(tài)變更業(yè)務(wù)中, 微信離線刷臉業(yè)務(wù)系統(tǒng)和商戶后臺系統(tǒng)交互的序列圖：
# 2.3 接口說明
環(huán)境：正式環(huán)境
請求方式：post
請求地址：該鏈接由商戶提供，微信審核通過后上線。URL必須為https協(xié)議。如果鏈接無法訪問，商戶將無法接收到微信通知。通知url必須為直接可訪問的url，不能攜帶參數(shù)。
notify_url：“https://api.yourcompany.com/notify/process.action”
# 2.4 請求參數(shù)
| 參數(shù)名 | 變量名 | 類型 | 必填 | 描述 |
| 通知ID | id | string（32） | 是 | 通知的唯一ID。 示例值：EV-2018022511223320873 |
| 通知創(chuàng)建時間 | create_time | string（16） | 是 | 通知創(chuàng)建的時間。 示例值：2020-05-20T10:23:14+08:00 |
| 通知類型 | event_type | string（32） | 是 | 通知的類型。 示例：FACEPAY.USER_STATE_CHANGE |
| 通知數(shù)據(jù)類型 | resource_type | string（32） | 是 | 通知的資源數(shù)據(jù)類型，支付成功通知為encrypt-resource。 示例值：encrypt-resource |
| 通知數(shù)據(jù) | resource | object | 是 | 通知資源數(shù)據(jù) |
| 回調(diào)摘要 | summary | string（64） | 是 | 回調(diào)摘要。 示例值：刷臉用戶簽約狀態(tài)變更 |
resource對象列表：
| 參數(shù)名 | 變量名 | 類型 | 必填 | 描述 |
| 加密算法類型 | algorithm | string（32） | 是 | 對支付結(jié)果數(shù)據(jù)進行加密的加密算法，目前只支持AEAD_AES_256_GCM；
示例值：AEAD_AES_256_GCM |
| 數(shù)據(jù)密文 | ciphertext | string（1048576） | 是 | Base64編碼后的支付結(jié)果數(shù)據(jù)密文； 示例值：dfewfewe== |
| 原始回調(diào)類型 | original_type | string（64） | 是 | 原始回調(diào)類型； 示例值：facepay |
| 附加數(shù)據(jù) | associated_data | string（16） | 否 | 附加數(shù)據(jù)； 示例值: fefwe |
| 隨機串 | nonce | string（32） | 是 | 加密使用的隨機串； 示例值：fdasflkja484w |
下面詳細描述對通知數(shù)據(jù)進行解密的流程：
A、用商戶平臺上設(shè)置的APIv3密鑰【微信商戶平臺—>賬戶設(shè)置—>API安全—>設(shè)置APIv3密鑰】，記為key；
B、針對resource.algorithm中描述的算法（目前為AEAD_AES_256_GCM），取得對應(yīng)的參數(shù)nonce和associated_data；
C、使用key、nonce和associated_data，對數(shù)據(jù)密文resource.ciphertext進行解密，得到JSON形式的資源對象；
注意：AEAD_AES_256_GCM算法的接口細節(jié)，請參考rfc5116。微信支付使用的密鑰key長度為32個字節(jié)，隨機串nonce長度12個字節(jié)，associated_data長度小于16個字節(jié)并可能為空。
解密后的resource對象列表：
| 參數(shù)名 | 變量名 | 類型 | 必填 | 描述 |
| 微信刷臉用戶ID | user_id | string（64） | 是 | 微信刷臉用戶唯一標(biāo)識； 示例：FUxxxfjeiofewfefw |
| 商戶刷臉用戶ID | out_user_id | string（64） | 是 | 商戶刷臉用戶唯一標(biāo)識； 示例值：fefwe33333333 |
| 機構(gòu)編號 | organization_id | string（32） | 是 | 機構(gòu)編號，代表一個學(xué)校、一個企業(yè)； 示例值：Ofewfwijifeeeex |
| 商戶號 | mch_id | string（32） | 是 | 微信支付分配的商戶號； 示例值：1333333333 |
| 通知創(chuàng)建時間 | notify_create_time | string（32） | 是 | 通知創(chuàng)建時間；示例值：xxxx |
| 微信APPID | appid | string（32） | 是 | 微信APPID； 示例值: wx3233223 |
| 微信用戶openid | openid | string（64） | 是 | 微信openid； 示例值: 3829323efdwef |
| 簽約ID | contract_id | string（32） | 是 | 用戶簽約ID |
請求示例
{
"user_id": "FUxxxfjeiofewfefw",
"out_user_id": "fefwe33333333",
"organization_id": "OPfefewwefwe",
"mch_id": "1233456",
"notify_create_time": "2020-05-20T10:23:14+08:00",
"appid": "fefefewfefew",
"openid": "fjeofejwofewfew"
}
# 2.5 通知簽名
加密不能保證通知請求來自微信。微信會對發(fā)送給商戶的通知進行簽名，并將簽名值放在通知的HTTP頭Wechatpay-Signature。商戶應(yīng)當(dāng)驗證簽名，以確認(rèn)請求來自微信，而不是其他的第三方。簽名驗證的算法請參考《微信支付APIv3簽名方案》。
# 2.6 通知應(yīng)答
商戶后臺在正確處理回調(diào)之后，需要返回200或者204的HTTP狀態(tài)碼。其他的狀態(tài)碼，微信支付均認(rèn)為通知失敗，并按照前述的策略定期發(fā)起通知。注意，當(dāng)商戶后臺應(yīng)答失敗時，微信支付將記錄下應(yīng)答的報文，建議商戶按照如下格式返回。
應(yīng)答示例
{
"code": "ERROR_NAME",
"message": "ERROR_DESCRIPTION",
}