為什麼做海外 SaaS 訂閲，會比國內複雜這麼多？看完你就懂了
整理版優先睇
海外SaaS訂閲複雜在於用戶權益意識與支付標準，唔可以簡單用「付錢取消」搞掂
呢篇文章係一位開發者做海外SaaS訂閲功能嘅經驗分享。佢一開始以為訂閲好簡單，淨係用戶畀錢同取消，但真正落手做先發現一大堆狀態：升級、降級、試用期、支付失敗、年轉月、月轉年等等，搞到頭都大埋。
佢慢慢理解到，海外SaaS環境同國內好唔同。國內用戶習慣一次性付費，狀態簡單；但國外主流係月費制，用戶同產品係長期關係，加上用戶權利意識強，會要求隨時取消、升級補差價等。最重要係，Stripe呢啲支付平台本身就內置咗一套狀態機，唔跟就跟唔到行業標準。所以呢啲複雜性唔係多餘，而係對用戶嘅基本尊重，亦係打入國際市場嘅必要條件。
佢最後將每個場景嘅邏輯捋順曬，發現最麻煩嘅係邊界情況，例如試用期最後一日升級、年付第11個月降級呢類。佢用大量測試用例反覆驗證，確保無漏洞。而家佢已經將呢啲處理邏輯整合成一個叫Pay4SaaS嘅方案，俾其他人直接使用。
- 海外SaaS訂閲嘅複雜性來自用戶權利意識同支付平台標準，唔可以為咗簡化而省略狀態處理。
- 國內同海外用戶預期唔同：國內習慣一次性付費，海外默認月費制同隨時取消權利。
- 支付平台如Stripe內置proration、grace period等機制，跟隨標準係專業表現。
- 邊界情況（例如試用期最後一日升級）先係真正難搞嘅地方，需要大量測試驗證。
- 作者已將所有場景整合成Pay4SaaS方案，可直接使用，減少開發訂閲功能嘅麻煩。
Pay4SaaS
作者整好嘅海外SaaS訂閲解決方案，處理曬升降級、試用期、支付失敗等邊界情況，可直接整合使用。
最初以為好簡單，點知狀態多到嚇親
作者一開始諗住訂閲功能好簡單，就係用戶畀錢同取消。點知真係開始做，先發現狀態多到頭皮發麻。
「訂閲唔係訂閲一下然後取消就得咩？」呢個係作者最初嘅想法，但現實完全唔係咁。
國內場景大概得自動續費、試用期、到期前取消、立即取消四種。但海外SaaS仲要處理升級套餐、降級套餐、即時生效定下個週期生效、按比例補差價、年轉月、月轉年、支付失敗、多個Webhook接收等等。
簡化做唔到，用戶體驗會差好多
你可能會諗，簡單啲唔得咩？只支援續費同取消。當然可以，但用戶體驗會差好遠。
如果唔做升降級，用戶想換高級套餐就要先取消再重新付費，要行兩步。
但係有咗升降級，用戶只需點一下確認，立即升級，差價自動補，錢入你賬，用戶又滿意。用戶體驗差少少，可能就變成流失。
海外訂閲咁複雜嘅三大原因
- 1 國內用戶習慣一次性付費或包年，海外主流係月費制，用戶同產品建立長期關係，狀態自然複雜。
- 2 海外用戶對訂閲權利意識強，會認真睇條款，期望隨時取消同升級只補差價，呢啲係默認消費預期。
- 3 主流支付平台如Stripe本身已經內置狀態機，包括proration、grace period、trial等，繞開佢就等於唔跟行業標準。
呢啲狀態唔係可以揀做唔做，而係支付標準嘅一部分。
所以狀態多係對用戶嘅尊重，亦係打入國際市場嘅入場券。
最難搞嘅唔係邏輯，而係邊界情況
作者硬住頭皮將每個場景邏輯捋順咗，發現真正麻煩嘅係邊界情況。
「訂閲嘅60多個測試用例反覆測咗幾遍，都快翻爛埋」
例如用戶喺試用期最後一日升級、年付用戶第11個月降級、支付失敗等等，每個未處理好嘅場景都係潛在漏洞。
作者已經整合好方案，可直接用
作者將所有場景（升降級、試用期、年轉月、月轉年等邊界情況）整合到Pay4SaaS，可以直接使用。
有興趣可以去pay4saas.cn瞭解，慳返自己重新摸索嘅時間。
01
做訂閲之前，我以為得兩件事，用戶俾錢，用戶取消。
真係開始做先發現，狀態多到令我頭皮發麻。
當時心諗第一反應係，訂閲咪即係訂閲咗然後可以取消，咁就得啦，點解咁麻煩？
結果越深入越發現，呢個「麻煩」唔係多餘嘅，係真係存在嘅業務需求。
02
先講國內嘅場景，自動續費、試用期、到期前取消、立即取消，大概都係呢4種。
但係我睇咗支付平台嘅開發文檔同埋學習訂閲之後，發現海外嘅SaaS，仲有呢啲，升級套餐、降級套餐、升降級立即生效定係下個週期生效、升級時按比例補差價、降級時在下個週期、年付轉月付、月付轉年付、支付失敗，同埋多個Webhook嘅接收處理……
第一次見到呢啲詞嘅時候，我心入面直接打出個問號，呢個都太多喇掛？
淨係「取消」呢一個動作，就分兩種，立即取消同到期取消，處理嘅邏輯係唔同嘅，處理得唔好就係用戶抱怨、甚至投訴。
03
你可能會話，我簡單啲唔得咩，淨係支援續費同取消，慳事啲。
可以，但係用戶體驗有好大差距。
例如，如果我哋唔做升降級，用戶想換高級套餐，步驟係，佢要先取消當前套餐，然後再俾錢，需要兩步。
但如果做咗升降級，用戶有幾慳事？㩒一下確認，立即升級，差價自動補，錢入你户口，用戶體驗又好，何樂而不為呢？係咪？
而用戶體驗上差咗嗰少少，可能就會變成流失。
有啲設計，應該極簡，例如，昨日嘅支付按鈕數量分析，但係呢個，係真係唔可以慳。
04
咁點解海外訂閲，會有咁多場景呢？
因為，國外嘅SaaS環境同國內完全唔一樣。
國內用戶買軟件，習慣一次性俾錢，或者包年，續唔續睇心情。但係國外SaaS嘅主流模式係按月訂閲，用戶同你嘅產品係長期關係，關係越長，狀態越複雜。
其次呢，國外用戶對訂閲嘅權利意識好強。佢哋會認真睇條款，知道自己有權隨時取消，有權喺升級時只補差價。呢個唔係挑剔，係佢哋默認嘅消費預期。我哋唔做，佢哋就覺得我哋嘅產品唔專業。
更加重要嘅係，國外主流支付平台，無論係Stripe定係Creem，本身已經將呢套狀態機整咗入去。
Creem。
Stripe。
proration、grace period、trial、immediate cancel、cancel at period end……呢啲唔係我哋可以選擇做唔做嘅嘢，呢啲係支付標準。如果繞過佢，就係唔跟隨行業標準，心入面總會擔心出問題嘅。
所以狀態多，唔係過度開發，過度設計，係基本嘅用戶尊重，亦都係融入國際市場嘅入場券。
05
當時我硬住頭皮將每個場景嘅邏輯都捋咗一次，捋完之後反而釋然咗。真正麻煩嘅唔係邏輯，係邊界情況。因為呢啲狀態雖然多，但背後嘅邏輯係自洽嘅，做完一個，下一個就順咗。
而家我行完曬成個訂閲嘅生命週期，就特別自如喇。畢竟訂閲嘅60幾個測試用例反覆測咗幾次，都快俾我翻爛咗，哈哈。
例如用戶喺試用期最後一日升級，例如年付用戶喺第11個月降級，例如用戶支付失敗咗，每一個冇處理好，冇諗到嘅場景，都係一個潛在嘅漏洞。
淨係將呢啲邊界情況一個個列出來，測試，驗證，就已經花咗我大量時間。
畢竟，出咗問題，唔係我哋損失，就係用戶損失，冇第三種結果。
06
呢啲場景，無論係升降級、試用期、年付轉月付，月付轉年付等等各種邊界情況，我喺Pay4SaaS入面都處理好咗，你直接用就得，有興趣嘅可以上pay4saas.cn瞭解。
01
做訂閲之前，我以為就 2 件事，用戶付錢，用戶取消。
真開始做才發現，狀態多得讓我頭皮發麻。
當時心裏第一反應是，訂閲不就是訂閲一下然後能取消，不就行了嗎，怎麼這麼麻煩？
結果越深入越發現，這個「麻煩」不是多餘的，是真實存在的業務需求。
02
先說國內的場景，自動續費、試用期、到期前取消、立即取消，大致也就這 4 種。
但我閲讀了支付平台的開發文檔以及學習訂閲以後，發現海外的 SaaS，還有這些，升級套餐、降級套餐、升降級立即生效還是下個週期生效、升級時按比例補差價、降級時在下個週期、年付轉月付、月付轉年付、支付失敗，以及多個 Webhook 的接收處理……
第一次看到這些詞的時候，我心裏直接打了個問號，這也太多了吧？
光是「取消」這一個動作，就分 2 種，立即取消和到期取消，處理的邏輯是不一樣的，處理不好就是用戶抱怨、甚至投訴。
03
你可能會說，我簡單點不就行了，只支持續費和取消，省事兒。
可以，但用戶體驗有很大差距。
比如，如果我們不做升降級，用戶想換高級套餐，步驟是，他得先取消當前套餐，然後再付費，需要 2 步。
但如果做了升降級，用戶有多省事？點一下確認，立即升級，差價自動補，錢到你賬上，用戶體驗也好，何樂不為呢？是吧。
而用戶體驗上差的那一點，也許就會變成流失。
有些設計，應當極簡，比如，昨天的支付按鈕數量分析，但這個，是真的不能省。
04
那為什麼，海外訂閲，會有這麼多場景呢？
因為，國外的 SaaS 環境跟國內完全不一樣。
國內用戶買軟件，習慣一次性付費，或者包年，續不續看心情。但國外 SaaS 的主流模式是按月訂閲，用戶跟你的產品是長期關係，關係越長，狀態越複雜。
其次呢，國外用戶對訂閲的權利意識很強。他們會認真看條款，知道自己有權隨時取消，有權在升級時只補差價。這不是挑剔，這是他們默認的消費預期。我們不做，他們就覺得我們的產品不專業。
更為重要的是，國外主流支付平台，Stripe 也好，Creem 也好，本身就把這套狀態機建進去了。
Creem。Stripe。
proration、grace period、trial、immediate cancel、cancel at period end……這些不是我們可以選擇做不做的東西，這是支付標準。如果繞開它，就是不跟隨行業標準，心裏總會擔心出問題的。
所以狀態多，不是過度開發，過度設計，是基本的用戶尊重，也是融入國際市場的入場券。
05
當時我硬着頭皮把每個場景的邏輯都捋了一遍，捋完以後反而釋然了。真正麻煩的不是邏輯，是邊界情況。因為這些狀態雖然多，但背後的邏輯是自洽的，做完一個，下一個就順了。
現在我走完整個訂閲的生命週期，就特別自如了。畢竟訂閲的 60 多個測試用例反覆測了幾遍了，都快被我翻爛了，哈哈。
比如用戶在試用期最後一天升級，比如年付用戶在第 11 個月降級，比如用戶支付失敗了，每一個沒處理好，沒想到的場景，都是一個潛在的漏洞。
光是把這些邊界情況一個個列出來，測試，驗證，就花了我大量的時間。
畢竟，出了問題，不是我們損失，就是用戶損失，沒有第三種結果。
06
這些場景，不管是升降級、試用期、年付轉月付，月付轉年付等等各種邊界情況，我在 Pay4SaaS 裏都處理好了，你直接用就行，感興趣的可以訪問 pay4saas.cn 瞭解。