發送和接收紅包； 普通紅包、幸運紅包； 我們必須熟悉用戶應用層，但許多人不知道紅包的底層支付流程、紅包算灋的規則以及所涉及的支持系統。 今天，我們將討論“紅包”背後的秘密，並教你如何設計紅包系統1。什麼是紅包對於用戶來說，紅包更多的是一種娛樂手段和生活工具； 對於企業來說，它更多的是一種行銷手段； 微信紅包是最常見的。 許多應用程序，如nailing和pulse，都具有紅包功能。紅包本質上是用戶虛擬帳戶之間的“傳輸”功能； 從使用者帳戶中扣除一筆錢，然後將其折開並轉移到多個帳戶； 至於從每個帳戶轉帳的金額，則是紅包金額的算灋。 普通紅包很簡單，平均總金額還可以； 爭奪幸運紅包有點麻煩。 既要確保紅包的最低金額，也要確保金額是隨機的； 已經收集的不能再收集了。 過期的紅包不能再收集了，應該退還給發送紅包的帳戶。今天，我們將重點介紹個人紅包的設計方法2。紅包類型個人到個人指定單個對象：固定數量不指定對象（單個/多個）：團體獎金， 隨機金額或相等金額企業向個人發送的紅包可以是隨機金額或固定金額3.紅包系統涉及的系統前端應用程序：前端顯示頁面、收銀機、EtRecorder系統：紅包支付訂單、用戶獲得後的轉帳訂單帳戶系統：金額査詢、， 紅包餘額的轉出和轉入行銷系統：創建和査詢紅包規則，如紅包的數量和類型作業系統：查看和管理紅包分發和收款記錄每個系統將有一篇單獨的文章詳細解釋，這裡不再介紹； 默認情况下，讀者熟悉所有系統。 如果有不熟悉的系統，您可以轉到支付主題，找到相關系統進行閱讀4.紅包業務框架5.紅包商業流程關注不同場景下每種紅包類型的分發和收集流程5.1指定用戶-一對一場景主要在一對一聊天場景中， 向朋友發送紅包相當於指定某個用戶接收紅包一般業務流程圖發送用戶1狀態：用戶1狀態必須為實名； 接收用戶2狀態：需要指定用戶，前端需要發送用戶2餘額支付的用戶ID：當用戶1使用餘額支付時，在用戶2接收之前，發送的金額以凍結狀態存儲在的資金帳戶中； 卡綁定支付：當用戶1使用銀行卡支付時，支付金額將首先充值到1的資本帳戶並凍結結算資金。 收款（紅包狀態可用）：用戶2確認收款後，解凍1的資金並將其轉移到2的資金帳戶； 返回用戶2未收到到期金額：發送金額解凍後，按照原返回原則返回給用戶1； 用戶1取消發送：只要用戶2沒有收到，資金就可以解凍並返回。 分發業務流程收集返回業務流程收款返回業務流程5.2沒有用戶指定您可以根據設定的紅包數量分發一個或多個紅包總體業務流程圖欄位描述：發送用戶：1； 接收用戶：n（n=2,3,4…）； 發送的紅包數：K； 發送的總金額：m； 關鍵點描述：1.發送用戶1狀態：用戶1狀態必須為實名； 2.接收用戶N狀態：收集時N狀態不需要是實名。 不需要指定用戶，並根據發送的紅包的設定數量/可以接收K的人數來確認是針對單個用戶還是多用戶場景； 3.紅包創建：資金凍結成功後，根據隨機規則直接創建K個子紅包。3.支付：3.1）餘額支付：當用戶1使用餘額支付時，只要任何用戶沒有收到，剩餘的發送金額將被凍結存儲在1的資金帳戶中； 3.2）卡綁定支付：當用戶1使用銀行卡支付時，支付金額將首先充值到1的資金帳戶，資金將被凍結。 確認收件流程與3.1.配送業務流程收件退回業務流程相同6.總結好，我們將統計紅包到現在為止； 讓我們至少考慮幾個問題：底層服務向應用程序提供了哪些服務介面，傳輸和輸出參數中應該包括哪些欄位？ 使用中間帳戶和不使用中間帳戶發放紅包有什麼區別，更好的管道是什麼？ 您如何看待微信紅包的隨機量算灋？
留言列表
