獨立開發：支付接入只是開始，業務邏輯才是真正的深水區
整理版優先睇
支付接入只係開始，業務邏輯先係真正嘅深水區
呢篇文章係一位獨立開發者嘅親身經驗分享。佢原本以為接入咗 Creem、PayPal 呢啲支付平台之後就可以躺着收錢，但隨住對四種定價模式嘅深入理解，先發現業務邏輯先係最難搞嘅部分。佢逐一拆解咗純積分、買斷制、無限訂閲同訂閲+配額呢四種模式入面嘅具體問題，點出咗好多支付平台文檔唔會講嘅坑，例如併發扣減、試用期扣款失敗之後嘅寬限期、升級降級套餐時權限點樣同步，同埋積分系統嘅過期規則同消費優先級。
佢嘅結論係：支付唔係技術問題，而係業務問題；接入API可能只需要一粒鐘，但處理好業務細節可能需要一百粒鐘。佢選擇用「穩」嘅策略，先做好支付基礎設施，避免日後翻工。
- 支付接入只係開始，複雜嘅業務邏輯先係真正嘅深水區，需要獨立開發者自己寫 code 處理。
- 四種定價模式（純積分、買斷制、無限訂閲、訂閲+配額）各有隱藏嘅坑，例如併發扣減、試用期扣款延遲、升級降級權限同步等。
- 無限訂閲模式最易出投訴，扣款失敗後嘅寬限期處理不當會觸發支付平台凍結帳號。
- 訂閲+配額模式需要管理三種積分系統，消費優先級嘅設計直接影響用戶體驗，建議先扣即將過期嘅積分。
- 做支付要抱持「穩」嘅心態，寧願花多啲時間處理邊界 case，避免上線之後反覆出問題。
以為支付平台搞掂曬？原來惡夢先啱啱開始
作者原本以為接入咗Creem、PayPal之後就可以唔使理，但隨住對四種定價模式嘅深入研究，發現好多業務邏輯要自己搞。佢話：「支付平台只係按照你傳入嘅決定收錢或者終止收錢，但收錢後做乜、終止收錢後做乜，全部要你自己寫。」呢句真係講到重點。
四種定價模式嘅隱藏陷阱
作者詳細拆解咗四種模式，每種都有唔同嘅難度同潛在問題。
- 1 純積分模式：特徵係積分永不過期，支付最簡單，但隱藏咗併發扣減</highlight>嘅坑。兩個請求同時扣，餘額可能變負數。解決方法係數據庫層面做併發控制。
- 2 買斷制模式：支付同積分制一樣直接，但最難嘅係交付</highlight>。要令用戶感知到價值，幫佢哋省時間省心。
- 3 無限訂閲模式：複雜度指數上升，要處理試用期、活躍狀態、升降級、取消</highlight>。最易引發用戶投訴，搞到支付平台警告甚至凍結帳號。
- 4 訂閲+配額模式：最複雜，涉及三種積分系統——贈送、訂閲期每月給、額外購買嘅積分包</highlight>。要自訂過期規則同消費優先級。
作者特別提到，呢啲問題無標準答案，要自己根據場景做決策</highlight>。佢分享咗個人嘅選擇：升級要早，降級要慢；先扣即將過期嘅積分，再扣贈送，最後扣購買嘅。
邊界 case 背後係真實用戶嘅等待
作者話自己晚晚發夢都諗支付決策，雖然傷神，但令佢越嚟越瞭解呢個領域。佢認為每個邊界 case 背後都係一個真實用戶，處理好佢哋先可以避免風險。
唔好畀自己挖坑，支付係基本功
作者總結：支付唔係技術問題，係業務問題。如果想做長期項目，就一定要將支付呢個基建做好。佢提議用「穩」嘅策略，寧願慢啲都唔好畀自己留低尾巴。
- 俾自己做事，就唔好俾自己找麻煩。
- 支付做好等於規避風險，係項目上線嘅前提。
- 每個邊界 case 背後，都有一個真實用戶喺度等你嘅決策。
01
其實我原本以為，個項目接入咗 creem、PayPal之後，就萬事大吉，捱過咗最難嘅階段，我就可以完全唔使理，支付平台會幫我搞掂曬，我就可以坐喺度等收錢。
但隨住我對 4 種定價模式同埋項目業務嘅深入理解，我發現，遠遠冇我諗得咁簡單。
一齊睇下。
02
一、純積分模式（睇落簡單，細節都好多）
呢度嘅積分可以係，個數、次數、積分數、點數、頁數、流量數等等，佢嘅特徵係永遠唔會過期。
呢種模式，支付係最容易實現嘅。我做嘅第一個項目就係咁樣。
過程係， call 支付平台嘅支付接口地址，然後用戶俾錢就得。用戶再買，繼續 call 平台嘅接口。
但就算係咁簡單嘅模式，都有陷阱。
陷阱1：併發扣減
如果兩個請求同時嚟，用戶餘額100，兩個請求都扣50，可能搞到餘額變0（而唔係出錯「餘額不足」）。
呢個陷阱好隱蔽。
本地測試唔會遇到（得你一個人用）
上線之後間中出現（用戶同時撳咗兩次）
好難重現（唔係次次都發生）
解決方法係，需要喺數據庫層面做併發控制。
具體點做呢，有好多方案，各有優劣，要根據場景揀。
二、買斷制模式（支付簡單，交付先係關鍵）
我做嘅第二個項目就係呢種。
其實佢同積分制一樣。都係直接 call 一個結賬接口就得。冇乜複雜邏輯。
補充一句，買斷制最難嘅唔係支付，而係交付。
交付之前，點樣令用戶感受到價值？ 交到俾用戶之後，可唔可以幫用戶慳時間、慳心？
呢啲先係最緊要嘅。
三、無限訂閲模式（複雜程度開始指數上升）
無限訂閲模式就係，按月/年購買，喺有效期內，就可以無限使用。
例如，YouTube Premium、Grammarly。
去到呢度，就複雜咗。
開始有試用期、活躍狀態嘅判斷、升級降級套餐、取消套餐。呢啲平台唔會幫你處理㗎。佢哋只係根據你傳入嘅決定收錢或者唔收錢，但收咗錢之後做咩、唔收錢之後做咩，業務就要自己想清楚，自己寫。
呢啲處理得唔好，用戶實會嬲，投訴。唔應該扣錢嘅時候扣咗，應該開服務嘅冇開，總之，呢塊特別考你對業務嘅理解。
我喺人哋嘅帖下面就見到好多呢啲用戶投訴，然後後果就係，支付平台提你，凍結賬號。
如果真係功能唔好用，用戶大可以走人。
如果冇傷害到佢哋嘅核心利益，點解要投訴呢？
係咪，我覺得呢樣嘢我哋需要諗同重視，做好支付，就係規避風險，係項目上線嘅前提。
具體嘅陷阱如下，呢啲支付平台嘅文檔都唔會話你知。
陷阱1：試用期結束嘅一刻
用戶7日試用期，第 8 日淩晨 0 點扣錢。
問題：扣錢成功咗，但用戶權限幾時開通？
如果 webhook 延遲 5 分鐘，用戶呢5 分鐘用得唔得？用戶登入之後，有冇兜底處理？
如果扣錢失敗（卡冇錢），用戶可以繼續用嗎？用幾日？
陷阱2：扣錢失敗之後嘅寬限期
用戶2月1日訂閲咗月費$10，2月15日取消。
問題：2月16日到22日，用戶可以繼續用嗎？（畢竟啲錢已經俾咗）
部分支付平台默認有寬限期，例如，creem。
但係 code 邏輯，寫啱未？好多人以為，「扣錢失敗=即刻失效」，咁樣有問題，外國同內地嘅支付規則，講真有好大分別。
陷阱3：升級套餐
用戶買咗 $10/月 套餐，用咗 15 日，升級到$30/月。
支付平台會自動計：應該補返幾多錢？
但我哋嘅業務邏輯要同步，升級之後，權限幾時變？
如果 webhook 遲到，用戶會見到「我已經俾咗錢，點解仲係舊套餐？」，體驗就會好差好差。
陷阱4：降級套餐
用戶從10/月。
問題：幾時生效？
即刻生效？（用戶會話「我$30嘅錢白俾咗？」）
下個週期生效？（咁呢個月用戶仲可以用$30嘅功能嗎？）
默認，下個週期生效。但你嘅 code 要配合，如果唔係會亂，係啊，呢個週期唔改得。
呢塊，我都係來回試咗好幾次，但係試通咗。
四、訂閲+配額模式（最複雜，但最靈活）
呢個，比上一個更難，難喺邊？三種積分系統。
例如，送嘅、訂閲期內每個月俾嘅、仲有額外買嘅積分包。
呢啲問題，冇標準答案，喺書度都學唔到，都要自己決定。
問題1：邊個可以過期？邊個唔可以過期？
訂閲送嘅積分：過期（每個月刷新）
買嘅積分：永遠唔過期（買咗就係你嘅）
送嘅積分：有一個週期過期，例如，一個自然月。
問題2：消費優先級？
先扣邊個？再扣邊個？
我嘅諗法——先扣訂閲送嘅（因為佢會過期，唔用就浪費咗）再扣送嘅，最後扣單獨買嘅積分包（唔過期，可以慢慢用）
點解唔掉轉？
如果先扣買嘅，用戶會覺得，「我買嘅積分俾人強制消耗咗，訂閲送嘅反而過期，好蝕底！」
問題3：升級套餐，積分點搞？用戶由每月100積分嘅套餐，升級到每月500積分。
升級之後，即刻俾 500 嗎？
定係按比例俾？（用咗15日，俾500 × 15/30 = 250？）
支付平台會計補差價嘅錢，但積分點俾，要你自己定。
我嘅諗法係，升級即刻俾滿 500 。
理由：用戶俾錢升級，係想即刻用多啲，唔係想計數，大方啲。
問題4：降級呢？
用戶由500積分/月，降到100積分/月。點搞？
我嘅選擇：
升級要快，降級要慢，降級應該喺下一個週期，而唔係呢個週期。
問題5：取消訂閲之後，買嘅積分仲用得嗎？
取消訂閲，視乎取消嘅時機，取消分 2 種，一種係到期取消，一種係即時取消。即時取消嘅肯定唔用得，但到期取消嘅，仲有積分就可以用。
其次，單獨買嘅積分係永遠唔過期，唔可以整冇用戶呢啲積分包購買嘅。
問題6：統一送 vs 按需要送？
做活動嘅時候，要唔要送積分俾所有用戶？
統一送？統一過期？覺得冇理由，會令付費用戶唔舒服。
我嘅選擇係——睇情況。例如，拉新活動，新用戶送。
激勵活動，都主動送，但送嘅唔可以太多，都要衡量成本，照顧下付費用戶嘅感受。
呢啲決定，AI 可以俾方向，但最終要我自己判斷：
邊個選擇，長遠嚟講維護成本最低？
邊個選擇，用戶體驗最好？
邊個選擇，唔會自己挖坑？
相信每個做過開發嘅，都會明白呢種 bug 反覆折磨人嘅痛苦，所以，自己做嘢，就唔好俾自己惹麻煩，係咪。
03
除咗呢 4 種定價模式，仲有各個支付平台嘅對接，呢個工作量又係一部分。應該點樣規劃做呢啲先至效率最高？返工最少？
呢幾日，每日我幾乎都要處理十幾個咁樣嘅決定，連夢都係做支付決定，hah。
雖然有啲傷神，但的確令我對支付呢塊，越來越瞭解。
支付唔係技術問題，係業務問題。
接入支付平台嘅 API，可能只需要1個鐘，但業務問題同用戶體驗方面，可能要集中精神，花 100 個鐘嚟處理。
我之所以今次將支付做得咁透徹，係因為我知道，佢係基礎設施。係我做任何 SaaS 項目都唔少得嘅基礎設施。好多人喺項目開始嗰陣，都追求速度，2、3日上一個站。但我追求嘅係，穩，咁首先地基就要穩。佢喺未來好長一段時間裏，可唔可以令我唔使操心？可唔可以令我專注提供核心價值？可唔可以令我避免風險？同埋令用戶體驗達到最好？
而且，我將基礎設施做完整咗，之後只需要專注核心功能嘅開發就得，咁之後上線速度先會越來越快。
而且，做好咗，將來佢就唔會帶嚟麻煩，因為今次我將麻煩同各種邊界問題都處理曬。
每一個邊界 case 背後，都有一個真實用戶喺度等我哋嘅決定。
01
其實我原本以為，項目接入了 creem、PayPal以後，就萬事大吉了，度過最難的階段了，我就能夠完全不用管了，支付平台都替我處理好了，我就可以直接躺着收入了。
但隨着我對 4 種定價模式，以及項目業務的深入理解，我發現，遠沒有我以為的那麼簡單。
一起看看。
02
一、純積分模式（看起來簡單，細節也多）
這裏面的積分可以是，個數，次數、積分數、點數、頁數、流量數等等，它的特徵是永不過期。
這種模式，支付是最容易實現的。我做的第一個項目就是這樣的。
過程是，調用支付平台的支付接口地址，然後用戶支付即可。用戶再買，繼續調用平台的接口。
但即使是這麼簡單的模式，也有坑。
坑1：併發扣減
如果兩個請求同時來，用戶餘額100，兩個請求都扣50， 可能導致餘額變成0（而不是報錯"餘額不足"）。
這個坑很隱蔽。
本地測試不會遇到（只有你一個人用）
上線後偶爾出現（用戶同時點了兩次）
很難復現（不是每次都發生）
解決方法是，需要在數據庫層面做併發控制。
具體怎麼做呢，有很多方案，各有利弊，要根據場景選擇。
二、買斷制模式（支付簡單，交付才是關鍵）
我做的第二個項目就是這種的。
其實它和積分制是一樣的。都是直接調用一個結賬接口就行了。沒有什麼複雜的邏輯。
多說一句，買斷制最難的並不在支付，而在於交付。
交付前，如何讓用戶感知到價值？ 交付給用戶後，能不能讓用戶省時間，省心？
這些才是最關鍵的。
三、無限訂閲模式（複雜度開始指數上升）
無限訂閲模式，就是，按月/年購買了，在有效期內，就可以無限使用。
比如，YouTube Premium、Grammarly。
到這裏，就複雜了。
開始有試用期、活躍狀態的判斷、升降級套餐、取消套餐。這些平台可不會給處理的。他們只是按照你傳入的決定收錢還是終止收錢，但收錢後幹什麼、終止收錢後幹什麼，業務是要自己想清楚，自己寫的。
這些沒處理好，那用戶肯定會生氣啊，投訴啊。不該扣錢的時候扣了，該開業務沒開，總之，這塊特別考驗你對業務的理解。
我在別人帖子下面，就看到好多這種用戶投訴的，然後呢，後果就是，支付平台提醒，凍結賬號。
如果說功能真的不好用，那用戶乾脆離開就行了。
如果沒有傷害他們的核心利益，他們為什麼要投訴呢？
是吧，我覺得這是我們需要思考和重視的，把支付做好，就是在規避風險，是項目上線的前提。
具體的坑如下，這些支付平台的文檔都不會告訴你。
坑1：試用期結束的那一刻
用戶7天試用期，第 8 天凌晨 0 點扣款。
問題：扣款成功了，但用戶權限什麼時候開通？
如果webhook延遲 5 分鐘，用戶這5 分鐘能用嗎？用戶登錄後，有兜底處理麼？
如果扣款失敗（卡里沒錢），用戶能繼續用嗎？用幾天？
坑2：扣款失敗後的寬限期
用戶2月1日訂閲了月費$10，2月15日取消。
問題：2月16日-22日，用戶能繼續用嗎？（畢竟錢已經付了）
部分支付平台的默認是有寬限期的，比如，creem。
但代碼邏輯，寫對了嗎？很多以為，"扣款失敗=立即失效"，這是有問題的，國外和國內的這些支付規則，說實話是有很大不同的。
坑3：升級套餐
用戶買了 $10/月 套餐，用了 15 天，升級到$30/月。
支付平台會自動計算：應該補交多少錢？
但我們的業務邏輯要同步，升級後，權限什麼時候變？
如果webhook晚到，用戶會看到”我已經付錢了，怎麼還是舊套餐？”，體驗就會很差很差。
坑4：降級套餐
用戶從10/月。
問題：什麼時候生效？
立即生效？（用戶會說"我$30的錢白花了？"）
下個週期生效？（那這個月用戶還能用$30的功能嗎？）
默認，下個週期生效。但你的代碼要配合，不然會亂，是啊，本週期不能改。
這塊，我也是來回測試了好幾遍，但是測通了。
四、訂閲+配額模式（最複雜，但最靈活）
這個，比上一個更難，難在哪裏？三種積分系統。
比如，贈送的、訂閲期內每月給的、還有額外購買的積分包。
這些問題，沒有標準答案，在書上，也學不來，都要自己決策。
問題1：哪個能過期？哪個不能過期？
訂閲送的積分：過期（每月刷新）
購買的積分：永不過期（買的就是你的）
贈送的積分：有一個週期過期，比如，一個自然月。
問題2：消費優先級？
先扣哪個？再扣哪個？
我的思考——先扣訂閲送的（因為它會過期，不用就浪費了）再扣贈送的，最後扣單獨購買的積分包（不過期，可以慢慢用）
為什麼不反過來？
如果先扣購買的，用戶會覺得，“我買的積分被強制消耗了，訂閲送的反而過期了，好虧誒！”
問題3：升級套餐，積分怎麼辦？用戶從每月100積分的套餐，升級到每月500積分。
升級後，立即給 500 嗎？
還是按比例給？（用了15天，給500 × 15/30 = 250？）
支付平台會算補差價的錢，但積分怎麼給，要你自己定。
我的思考是，升級立即給滿 500 。
理由：用戶花錢升級，是想立即用更多，不是想算賬，大方一點。
問題4：降級呢？
用戶從500積分/月，降到100積分/月。怎麼辦？
我的選擇：
升級要早，降級要慢，降級應該在下一週期，而不是在本週期。
問題5：取消訂閲後，購買的積分還能用嗎？
取消訂閲，這取決於取消時機，取消分 2 種，一種是到期取消，一種是立即取消，立即取消的肯定不能再用，但到期取消的，還有積分的就能用。
其次，單獨購買的積分，是永不過期的，不能給用戶的這些積分包購買的弄沒了。
問題6：統一贈送 vs 按需贈送？
做活動時，要不要給所有用戶送積分？
統一送？統一過期？感覺沒有理由，會讓付費用戶覺得不舒服。
我的選擇是——看情況。比如，拉新活動，新用戶送。
激勵活動，也主動送，但送的不能太多，也要衡量成本，照顧付費用戶的感受。
這些決策，AI能給方向，但最終要我自己判斷：
哪個選擇，長期來看維護成本最低？
哪個選擇，用戶體驗最好？
哪個選擇，不會給自己挖坑？
相信每個做過開發的，都會理解這種 bug 反覆折磨人的痛苦，所以，給自己做事，就不能給自己找麻煩，是吧。
03
那除了這 4 種定價模式，還有各個支付平台的對接，這個工作量又是一部分。應該怎麼規劃做這些才是效率最高的？返工率最小的？
這幾天，每天我幾乎都要處理十幾個這樣的決策，連夢裏都是在做支付決策，hah。
雖然有點傷神，但的確讓我對支付這塊，越來越瞭解了。
支付不是技術問題，是業務問題。
接入支付平台的API，可能只要1小時，但業務問題，以及用戶體驗上，可能要集中精力，花 100 小時來處理。
我之所以，這次把支付做的這麼透，是因為我知道，它是基礎設施。是我做任何 SaaS 項目不可或缺的基礎設施。很多人在做項目開始，都在追求速度，2，3天上一個站。但我追求的是，穩，那首先地基就要穩。它在未來的很長一段時間裏，能不能讓我不操心？能不能讓我專注的提供核心價值？能不能讓我避免風險？且同時讓用戶體驗達到最好？
且，我把基礎設施完整了，後續只需要關注核心功能的開發就好了，那麼後續上線速度才會越來越快。
且，做好了，以後它就不會給我帶來麻煩，因為這次我把麻煩和各種邊界問題，都處理掉了。
每一個邊界 case 背後，都是一個真實用戶在等我們的決策。