Giải thích thuê bao vs thanh toán theo sử dụng từ góc nhìn mô hình dữ liệu: meters, giới hạn, hoá đơn, proration, và các bản ghi cần lưu từ ngày đầu.
Giá không chỉ là một trang trên website. Nó quyết định bạn phải ghi lại gì, báo cáo ra sao, và liệu bạn có thể giải thích một khoản phí sau vài tháng hay không. Khi chọn thuê bao hay thanh toán theo sử dụng, bạn cũng đang chọn hình dạng dữ liệu thanh toán của mình.
Một thuê bao đơn giản thường có thể tính từ vài thông tin: gói, kỳ thanh toán, ngày bắt đầu và chiết khấu. Giá theo sử dụng cần nhiều hơn: đã dùng gì, khi nào xảy ra, thuộc khách hàng nào, và cách sử dụng đó chuyển thành tiền. Không có những bản ghi đó, bạn vẫn có thể gửi hoá đơn, nhưng bạn không thể biện hộ cho chúng.
Thêm phần theo sử dụng sau này mà không có kế hoạch thường vỡ ở ba chỗ:
usage khác nhau.Mục tiêu nghe nhàm nhưng thiết yếu: tính cùng một hoá đơn theo cùng một cách mỗi lần. Điều đó có nghĩa là bạn có thể phát lại phép tính từ các dữ kiện đã lưu (điều khoản gói, quy tắc meter, sự kiện sử dụng, và phiên bản giá chính xác đã áp dụng).
Một "góc nhìn mô hình" chỉ có nghĩa là mô tả thanh toán như các khối xây dựng ghép lại với nhau, ngay cả khi bạn không phải kỹ sư. Hãy tưởng tượng một sản phẩm chat nhóm:
Để hỗ trợ điều đó sau này, dữ liệu của bạn phải trả lời: workspace nào, tháng nào, bao nhiêu tin nhắn, bao nhiêu được bao gồm, và quy tắc giá nào đang áp dụng.
Thuê bao tính phí quyền truy cập. Thanh toán theo sử dụng tính phí tiêu thụ. Chúng cư xử rất khác khi có nâng cấp, hạ cấp, proration và các trường hợp biên thực tế.
Với thuê bao, câu hỏi chính là: Khách hàng có quyền sử dụng sản phẩm trong thời gian này không? Bạn chủ yếu theo dõi gói, số ghế, kỳ thanh toán và liệu hoá đơn đã được trả hay chưa. Sử dụng vẫn quan trọng, nhưng thường xuất hiện như các giới hạn (mềm hoặc cứng) thay vì dòng mục trên hoá đơn.
Với thanh toán theo sử dụng, câu hỏi trở thành: Chính xác đã xảy ra gì, và khi nào? Bạn cần metering đáng tin cậy, quy tắc rõ ràng khi nào tính usage, và cách giải thích mọi khoản phí sau này. Ngay cả khi UI hiển thị một số duy nhất (ví dụ 1,243 API calls), phía sau là một tập sự kiện phải nhất quán và có thể kiểm toán.
Nhiều đội B2B SaaS chọn mô hình hybrid: phí cơ bản bao phủ một gói, cộng phí vượt mức.
Hầu hết mô hình hybrid rơi vào vài dạng quen thuộc:
Tính dự đoán giúp khi khách hàng cần phê duyệt ngân sách và chi tiêu hàng tháng ổn định. Pay-as-you-go phù hợp hơn khi giá trị tỉ lệ với hoạt động (ví dụ, mỗi hoá đơn xử lý), hoặc khi khách hàng thử nghiệm và muốn rủi ro thấp.
Thay đổi gói là điều chắc chắn. Giá, gói và cách đóng gói sẽ thay đổi. Thiết kế hệ thống thanh toán để bạn có thể thêm meter mới, giới thiệu tầng mới, hoặc thay đổi ý nghĩa của "bao gồm" mà không phải viết lại lịch sử. Quy tắc thực tế: lưu gói khách hàng và điều khoản giá như chúng vốn có tại thời điểm bị tính, không chỉ trạng thái hiện tại.
Meter là thứ chính xác bạn tính phí, được ghi rõ sao cho hai người đếm sẽ ra cùng số. Nó gồm ba phần: event (điều gì xảy ra), đơn vị (đếm gì), và thời điểm (khi nào được tính).
Hầu hết tranh chấp bắt nguồn từ đây. Một bên nghĩ họ trả cho kết quả, bên kia tính cho hoạt động có thể đo lường.
Chọn các meter ánh xạ tới hành động sản phẩm thực và có thể ghi lại tự động. Ví dụ phổ biến:
Rồi định nghĩa gì được tính và gì không. Nếu bạn tính theo API call, quyết định retry có tính không, response 4xx và 5xx có tính không, và cuộc gọi nội bộ do tích hợp của bạn có tính không.
Thời điểm quan trọng như đơn vị. Ghế thường phù hợp làm snapshot điểm thời gian mỗi kỳ thanh toán. API calls thường cộng trong một khoảng. Storage khó hơn: khách hàng mong trả cho "bao nhiêu bạn lưu trữ", thường nghĩa là trung bình theo thời gian, không phải đỉnh.
Cũng quyết định phạm vi: theo account, hay theo workspace/project. Quy tắc đơn giản: nếu các team có thể bị tính riêng, meter nên là per workspace.
Entitlements là các quy tắc cho những gì khách hàng được phép làm vì những gì họ đã mua. Chúng trả lời các câu như: họ có thể thêm bao nhiêu người dùng? Tính năng nào được bật? Mức khối lượng nào được cho phép mỗi tháng? Entitlements nằm giữa truy cập và thanh toán: chúng định hình những gì sản phẩm cho phép, trong khi metering ghi lại điều gì thực sự đã xảy ra.
Giữ entitlements tách biệt khỏi logic metering. Entitlements nên có thể đọc được và ổn định (gói, add-on, điều khoản hợp đồng). Metering sẽ tiến hoá khi sản phẩm phát triển (sự kiện mới, meter mới), và bạn không muốn mỗi thay đổi meter làm rủi ro phá vỡ truy cập.
Hard limit, soft limit và overage billing có thể trông giống nhau trên UI, nhưng hành vi khác:
Quyết định trước chuyện gì xảy ra khi vượt hạn mức. Ví dụ: team trên tầng "Starter" bao gồm 5 ghế và 10.000 API calls mỗi tháng. Nếu họ mời người thứ 6, bạn chặn, bắt đầu tính phí ghế thêm, hay cho phép 7 ngày as grace? Mỗi lựa chọn cần quy tắc bạn có thể hiện trên hoá đơn và trong log support.
Lưu entitlements như các bản ghi có giới hạn thời gian: khách hàng, gói hoặc add-on, timestamps bắt đầu và kết thúc, giá trị giới hạn, và chế độ thực thi (hard, soft, overage). Điều này giữ quyết định truy cập và thanh toán nhất quán.
Hoá đơn không chỉ là một PDF. Nó là một dấu vết kiểm toán trả lời: ai bị tính, vì gì, cho những ngày nào, theo quy tắc nào. Nếu bạn thay đổi giá, bạn vẫn phải có thể xây dựng lại hoá đơn cũ chính xác như trước.
Bắt đầu với vài bản ghi cốt lõi: Customer, Subscription (hoặc Contract), Billing Period, và Invoice với Line Items. Mỗi dòng mục nên trỏ lại nguồn của nó: phí gói, tổng sử dụng, hoặc phí một lần. Liên kết đó là thứ làm hoá đơn có thể giải thích khi ai đó tranh chấp một khoản phí.
Kỳ thanh toán cần một anchor và múi giờ. Monthly thì không đủ. Lưu cycle anchor date (ví dụ, ngày 15 lúc 00:00) và múi giờ dùng để cắt kỳ. Giữ điều này nhất quán nếu không bạn sẽ gặp lỗi lệch một ngày quanh DST.
Hoá đơn có thể kiểm toán thường cần:
period_start và period_end trên mỗi hoá đơn và mỗi dòng mụcGhi nhận doanh thu liên quan nhưng không giống hoàn toàn việc tính phí. Phí thuê bao trả trước thường được ghi nhận dần theo kỳ dịch vụ, trong khi sử dụng thường được ghi nhận khi cung cấp. Ngay cả khi bạn giữ ở mức cao, hãy lưu đủ ngày để hỗ trợ sau này.
Xử lý credit note, refund và điều chỉnh như bản ghi hạng nhất, không bao giờ sửa hoá đơn cũ. Nếu khách hàng nâng cấp giữa kỳ, tạo dòng điều chỉnh hoặc credit note tham chiếu hoá đơn gốc và nêu rõ quy tắc proration đã dùng.
Khóa idempotency quan trọng cho việc tạo hoá đơn và thử thanh toán. Nếu một job chạy hai lần, bạn muốn một hoá đơn, một khoản ghi nợ, và một log rõ ràng.
Thay đổi giữa kỳ là nơi tranh luận về thanh toán bắt đầu. Nếu ai đó nâng cấp vào ngày 20, tạm dừng một tuần, rồi huỷ, bạn cần quy tắc biến những hành động đó thành con số có ý nghĩa trên hoá đơn.
Quyết định thay đổi nào bạn cho phép và khi nào nó có hiệu lực. Nhiều đội áp dụng nâng cấp ngay để khách hàng nhận giá trị ngay, nhưng áp dụng hạ cấp khi tái tục để tránh refund phức tạp.
Proration có thể theo ngày, theo giờ, hoặc không có. Càng chính xác càng cần nhiều timestamp, quy tắc làm tròn và các trường hợp biên phải lưu và kiểm thử.
Khóa các lựa chọn chính sách sớm:
Tránh các phép tính ẩn. Thể hiện proration như điều chỉnh rõ ràng trên hoá đơn, ví dụ một ghi nợ cho thời gian còn lại của gói mới và một tín dụng cho thời gian chưa dùng của gói cũ. Mỗi dòng mục nên liên kết tới sự kiện thay đổi gây ra nó (change_id) và bao gồm cửa sổ proration (start_at, end_at), cơ sở số lượng/thời gian, và loại thuế.
Meters về sử dụng thêm một quyết định nữa: khi gói thay đổi, meter có reset, tiếp tục tích luỹ, hay tách thành các đoạn? Cách đơn giản và có thể kiểm toán là phân đoạn sử dụng theo phiên bản gói. Ví dụ: khách hàng nâng cấp từ 10 ghế lên 25 ghế giữa tháng. Bạn giữ các sự kiện sử dụng như trước, nhưng khi rating bạn gom chúng theo khoảng entitlement đang hoạt động tại thời điểm đó.
Quyết định cái gì có thể đảo ngược. Hữu ích khi coi sự kiện sử dụng là cuối cùng khi đã chấp nhận, trong khi thay đổi subscription có thể đảo ngược chỉ cho tới khi hoá đơn được final. Lưu sự kiện thay đổi và điều chỉnh hoá đơn để bạn có thể tạo lại hoá đơn sạch khi quy tắc tiến hoá.
Nếu bạn chờ thiết kế dữ liệu thanh toán tới khi khách hàng phàn nàn, bạn sẽ phải đoán. Dù bạn chọn thuê bao, theo sử dụng, hay hybrid, điểm khởi đầu an toàn là một tập bản ghi nhỏ mà bạn luôn có thể kiểm toán sau này.
Bắt đầu với một cấu trúc khách hàng rõ ràng. Trong B2B SaaS, người trả tiền thường là một tài khoản công ty, nhưng sử dụng thường xảy ra trong workspace hoặc project, và hành động tới từ người dùng cá nhân. Lưu cả ba cấp (account, workspace, user) và ghi ai làm gì. Tranh chấp thanh toán thường biến thành "nhóm nào đã làm việc này?"
Một thiết kế DB thanh toán tối thiểu hỗ trợ hoá đơn thật và điều tra sạch sẽ:
Đừng chỉ dựa vào bộ đếm tổng. Giữ counters để nhanh, nhưng coi nhật ký sự kiện là nguồn sự thật. Quy tắc đơn giản: sự kiện là bất biến, sửa lỗi là sự kiện mới (ví dụ số lượng âm), và mỗi sự kiện liên kết tới một định nghĩa meter cụ thể.
Ví dụ: một khách hàng nói "API calls của chúng tôi tăng gấp đôi tháng trước." Nếu bạn có thể kéo các sự kiện thô theo workspace và ngày, bạn có thể chỉ ra nơi phát sinh spike hoặc phát hiện vòng lặp tích hợp.
Phần khó không phải là toán học. Làm sao để kết quả có thể giải thích được vài tháng sau, ngay cả khi gói, giá và khách hàng đổi thay.
Thiết lập sản phẩm, gói, meter và giá với ngày hiệu lực. Không bao giờ ghi đè giá cũ. Nếu khách hàng bị tính vào tháng 3, bạn phải có thể chạy lại tháng 3 dùng catalog của tháng 3.
Ví dụ: API Calls giá $0.002 mỗi cái bắt đầu 1/4. Hoá đơn tháng 3 vẫn phải dùng giá cũ.
Vào đầu mỗi kỳ thanh toán (hoặc khi có thay đổi), lưu một snapshot entitlement: gói, đơn vị bao gồm, giới hạn, quy tắc tiers, chiết khấu, và cài đặt thuế. Hãy coi nó như "cái chúng tôi hứa" cho kỳ đó.
Sử dụng nên đến dưới dạng sự kiện bất biến: timestamp, khách hàng, meter, số lượng, và id duy nhất để loại trùng. Validate cơ bản ngay từ cửa (meter thiếu, số âm, timestamp vô lý) và lưu sự kiện thô ngay cả khi bạn cũng lưu phiên bản đã làm sạch.
Rồi làm tính toán theo hai bước:
Tạo các dòng hoá đơn tham chiếu chính xác các đầu vào đã dùng (phiên bản catalog, id snapshot, id tổng hợp).
Cuối cùng, khoá hoá đơn. Lưu các đầu vào tính toán và kết quả, đánh dấu là final, và ngăn nó thay đổi khi có sự kiện đến muộn. Sự kiện đến muộn nên vào hoá đơn tiếp theo (hoặc một điều chỉnh riêng) kèm ghi chú kiểm toán rõ ràng.
Khách hàng không quan tâm bạn chọn thuê bao hay thanh toán theo sử dụng. Họ quan tâm số của bạn khớp với của họ, và họ có thể dự đoán khoản tiếp theo trước khi nó xảy ra.
Báo cáo hướng khách hàng hoạt động tốt nhất như một trang billing đơn giản trả lời vài câu hỏi mà không cần ticket support:
Nội bộ, support và finance cần giải thích một con số, không chỉ hiển thị nó. Điều đó nghĩa là phát hiện spike, truy vết thay đổi, và tách toán preview với billing đã final.
Giữ preview hoá đơn tách khỏi hoá đơn. Preview có thể tính lại khi có sự kiện muộn hoặc khi bạn tinh chỉnh định nghĩa meter. Hoá đơn đã final thì không.
Báo cáo nội bộ nên dễ dàng đánh dấu bất thường (nhảy vọt sử dụng, sử dụng âm, sự kiện trùng), tái tạo một dòng hoá đơn từ dữ liệu thô và quy tắc, và xem thay đổi gói cùng quy tắc proration trong kỳ.
Audit trail quan trọng hơn nhiều đội tưởng. Nếu khách hàng nói, Chúng tôi nâng cấp vào ngày 12, bạn cần timestamps, actor (user, admin, automation), và giá trị trước/sau chính xác cho gói, ghế, giới hạn và tỷ lệ meter.
Về lưu trữ, giữ sự kiện sử dụng thô và artifact hoá đơn đã final lâu dài. Quy tắc thực tế: nếu nó có thể thay đổi số tiền bị tính hoặc giúp biện hộ trong tranh chấp, lưu nó bất biến.
Hầu hết tranh chấp không phải về giá. Chúng xảy ra khi bạn không thể giải thích một con số trên hoá đơn, hoặc khi cùng đầu vào lại tạo ra tổng khác sau này.
Một sai lầm phổ biến là chỉ giữ tổng theo tháng. Không có sự kiện thô, bạn không thể trả lời câu hỏi đơn giản như Ngày nào khiến chúng tôi vượt giới hạn? Giữ sự kiện, rồi tổng hợp nó.
Vấn đề thường gặp khác là thay đổi ý nghĩa meter mà không version nó. Active user có thể ban đầu là đã đăng nhập ít nhất một lần và sau này thành tạo một record. Nếu bạn không version định nghĩa meter, khách hàng sẽ so sánh hoá đơn cũ với mới và bạn không chứng minh được quy tắc áp dụng.
Các tranh chấp thường đến từ vài mẫu:
Ví dụ: khách hàng ở Tokyo nâng cấp giữa kỳ vào ngày 31 giờ địa phương. Nếu bạn chỉ lưu timestamp UTC và không có billing anchor, nâng cấp có thể hiện là ngày 30 trong hệ thống của bạn, làm dịch proration và sử dụng sang kỳ sai.
Cách nhanh nhất để mất lòng tin là không thể tái tạo phép tính hoá đơn cũ. Lưu các đầu vào (sự kiện, phiên bản, anchor và giá đã áp dụng) để bạn có thể chạy lại cùng logic sau này và ra kết quả giống cũ, ngay cả khi sản phẩm đã thay đổi.
Trước khi launch, làm một bài tập: chọn ngẫu nhiên một khách hàng và tái tạo hoá đơn gần nhất chỉ từ dữ liệu đã lưu. Nếu bạn cần "cái gì code đã làm lúc đó", bạn không có audit trail.
Đảm bảo mỗi meter không mơ hồ. Một meter cần một đơn vị rõ ràng (requests, seats, GB, minutes), nguồn tin cậy (dịch vụ nào phát sự kiện), và cửa sổ thời gian (theo ngày, theo kỳ thanh toán, theo tháng lịch). Nếu bạn không thể giải thích meter trong một câu, khách hàng sẽ không tin nó.
Kiểm tra nhanh bắt được hầu hết lỗi thanh toán:
Ví dụ: khách hàng nâng từ 10 lên 25 ghế vào ngày 18 và vượt ngưỡng sử dụng vào ngày 23. Hệ thống của bạn nên hiển thị (1) phiên bản gói nào hoạt động vào mỗi ngày, (2) sự kiện đổi ghế với timestamp, (3) công thức proration đã dùng, và (4) các sự kiện sử dụng đã tổng hợp vào tổng cuối cùng.
Bắt đầu nhỏ, nhưng đừng bắt đầu mơ hồ. Con đường an toàn nhất là mô hình dữ liệu nhỏ nhất vẫn cho bạn trả lời một câu sau vài tháng: Tại sao chúng tôi tính số tiền này?
Prototype schema thanh toán và màn admin sớm, trước khi có thay đổi giá đầu tiên. Nếu bạn chờ tới khi sales yêu cầu tầng mới hoặc nâng cấp giữa kỳ, bạn sẽ vá logic ở quá nhiều nơi.
Một phân chia thực tế: để Stripe xử lý việc charge, biên lai và thử lại thanh toán, nhưng giữ việc rating (cách sử dụng thành dòng hoá đơn) trong hệ thống của bạn. Điều đó nghĩa là bạn lưu sự kiện sử dụng thô, phiên bản giá, và kết quả tính toán bạn dùng để tạo preview hoá đơn.
Kế hoạch ra mắt đơn giản mà vẫn linh hoạt:
Nếu bạn muốn tiến nhanh mà không viết nhiều mã hậu trường, bạn có thể mô hình các thực thể này trong AppMaster và xây màn admin và portal bằng công cụ trực quan của nó, trong khi giữ PostgreSQL làm hệ thống lưu trữ cho sự kiện và hoá đơn.
Ví dụ cụ thể: bạn ra mắt với một meter ghế. Ba tháng sau bạn thêm storage GB. Nếu meters, entitlements và quy tắc giá được version, bạn có thể giới thiệu meter mới mà không phá hoại hoá đơn cũ, và support có thể giải thích bất kỳ dòng mục nào trong vài phút.
Tại sao mô hình giá ảnh hưởng đến dữ liệu tôi cần lưu?Bắt đầu bằng việc xác định những gì bạn cần chứng minh sau này: tại sao khách hàng bị tính số tiền đó. Thuê bao cần lịch sử gói, kỳ thanh toán và entitlements; mô hình theo sử dụng cần một bản ghi bất biến về những gì đã xảy ra, khi nào và theo quy tắc giá nào.
Làm sao để làm cho việc thanh toán trở nên “có thể kiểm toán”?Nếu bạn không thể phát lại hoá đơn từ các dữ liệu đã lưu, bạn không thể trả lời tranh chấp hoặc kiểm toán một cách tin cậy. Cấu hình an toàn nhất là lưu các điều khoản gói có giới hạn thời gian, giá có version, sự kiện sử dụng thô và kết quả tính toán chính xác đã dùng khi hoá đơn được final.
Làm thế nào để định nghĩa một meter để nó không gây tranh chấp?Một meter tốt là thứ hai người đếm sẽ ra cùng một kết quả. Định nghĩa event, đơn vị và cửa sổ thời gian, và viết rõ cái gì được tính và cái gì không (ví dụ retries, request lỗi, hoặc các cuộc gọi nội bộ) để tránh thay đổi nghĩa giữa chừng.
Sự khác biệt thực tế giữa hard limits, soft limits và overage billing là gì?Hard limit chặn hành động, soft limit cảnh báo nhưng cho phép, và overage billing cho phép hành động và tính phí thêm. Chọn một hành vi cho mỗi entitlement và lưu nó như một quy tắc có timestamps bắt đầu/kết thúc để support, product và billing đều ra quyết định giống nhau.
Tại sao nên tách entitlements khỏi logic metering?Chúng giải quyết các vấn đề khác nhau: entitlements kiểm soát những gì khách hàng được phép làm, còn metering ghi lại những gì thực sự đã xảy ra. Tách chúng ra giúp tránh việc thay đổi meter làm hỏng quyền truy cập, và giúp hoá đơn dễ giải thích hơn.
Tôi nên lưu sự kiện sử dụng thô hay chỉ tổng theo tháng?Lưu một nhật ký sự kiện sử dụng append-only làm nguồn sự thật, và tuỳ chọn giữ các tổng hợp để tăng tốc. Sự kiện nên bao gồm timestamp, phạm vi khách hàng (như workspace), tên meter, số lượng và khoá idempotency để tránh trùng lặp gây tính phí đôi.
Làm sao xử lý thay đổi giá mà không làm hỏng hoá đơn cũ?Không bao giờ ghi đè giá cũ hay quy tắc gói; thay vào đó thêm phiên bản mới với ngày có hiệu lực. Sau đó lưu version giá áp dụng cho mỗi hoá đơn (và thường cho mỗi kỳ entitlement) để hoá đơn cũ có thể được xây dựng lại chính xác ngay cả khi cách đóng gói thay đổi.
Làm sao tránh lỗi do múi giờ và kỳ thanh toán?Billing theo tháng cần một cycle anchor và timezone, không chỉ là monthly. Lưu period_start và period_end một cách nhất quán và rõ ràng timestamp nào dùng cho event time so với ingestion time để tránh lỗi lệch ngày quanh múi giờ và DST.
Chính sách proration hợp lý cho nâng cấp và hạ cấp là gì?Dùng chính sách mà bạn có thể giải thích bằng một câu, và mô hình toán học dưới dạng các dòng hoá đơn rõ ràng (tín dụng và ghi nợ) liên kết với sự kiện thay đổi và cửa sổ proration. Proration theo ngày là mặc định hợp lý vì đơn giản hơn và đủ công bằng so với theo giờ.
Phải làm gì khi sự kiện sử dụng đến muộn sau khi hoá đơn đã được final?Xác định hoá đơn finalized là snapshot bất biến và coi các sự kiện muộn là điều chỉnh mới hoặc thuộc kỳ kế tiếp, kèm ghi chú rõ ràng. Bản preview có thể tính lại tự do, nhưng hoá đơn đã final không nên thay đổi khi có sự kiện đến muộn.
21 thg 1, 2026
8 phút
20 thg 1, 20268 phút
20 thg 1, 20268 phútThử nghiệm với AppMaster với gói miễn phí.
Khi bạn sẵn sàng, bạn có thể chọn đăng ký phù hợp.
