BDSGPHẠM VĂN THƯNHÀ SÁNG LẬP BDSG
ENTài khoản
Kết nối
Menu
Mô hình kinh doanh · Nội dung có hỗ trợ AI

Mô hình kinh doanh API: định giá, đóng gói, đo lường và chọn cách thu tiền (Phần 2/2)

Đăng ngày 23/10/2026

Mục lục bài nghiên cứu
Ảnh đại diện bài Mô hình kinh doanh dựa trên API, phần 2

Tóm tắt và điều cần nhớ

Đây là phần hai, phần cuối của chuỗi về mô hình kinh doanh dựa trên API, tức cổng để phần mềm này gọi chức năng hay dữ liệu của phần mềm khác. Phần một bàn về các loại API và cách thu tiền trực tiếp. Phần này đi tiếp: mặt trái của thuê bao, ba nguồn thu gián tiếp, định giá, đóng gói, hỗ trợ, đo lường và cách chọn mô hình.

  • Phí thuê bao cố định dễ lệch khỏi cách khách dùng thật; cần hạn mức vượt, quyền đổi bậc và cách xử lý mùa thấp điểm.
  • Quảng cáo, đối tác và giới thiệu hưởng hoa hồng là ba nguồn thu gián tiếp, mỗi nguồn kèm một rủi ro riêng.
  • Giá chỉ thuyết phục khi neo vào giá trị khách nhận được; các bậc gói khác nhau ở hạn mức, hỗ trợ và cam kết dịch vụ.
  • Đo lường mức dùng là nền móng của việc tính tiền, chống lạm dụng và học từ khách.
  • Tám câu hỏi giúp chọn mô hình có lý do; ở Việt Nam, Open API ngân hàng, Zalo và Goong là ba cách đóng gói khác nhau.

Vấn đề: có API rồi, tính tiền thế nào cho khớp cách khách dùng

Một API tốn chi phí cố định để vận hành, trong khi nhu cầu của khách hiếm khi đều: nhiều tháng thưa, vài tuần dồn dập. Cách tính tiền vì thế quyết định ai dám thử, ai ở lại, ai bỏ đi. Giả định một nhóm làm ứng dụng bán hàng dùng API nhắn tin ở mức nhỏ mười tháng, rồi gấp bốn lần hai tháng cuối năm: thuê bao mức cao khiến họ trả dư cả năm, mức thấp khiến họ chạm trần đúng mùa bán chạy. Nhà cung cấp cần dòng tiền dự báo được mà không đẩy khách vào thế kẹt ấy.

Khái niệm cốt lõi và thuật ngữ

Thu tiền trực tiếp là bên gọi API trả phí; thu tiền gián tiếp là một bên khác trả (nhà quảng cáo, đối tác, nền tảng thưởng hoa hồng) hoặc API chỉ là cửa vào một hoạt động kinh doanh lớn hơn. Sản phẩm thật thường pha trộn cả hai. Các thuật ngữ sau dùng xuyên suốt phần này.

  • Metering (đo lường mức dùng): ghi lại mỗi khoá API đã dùng gì, bao nhiêu, để lập hoá đơn.
  • Rate limiting (giới hạn tốc độ): số yêu cầu tối đa trong một khoảng thời gian; throttling là làm chậm hoặc từ chối khi vượt ngưỡng.
  • SLA (cam kết mức dịch vụ): cam kết bằng số về thời gian hoạt động, phản hồi và xử lý sự cố.
  • Sandbox là môi trường thử với dữ liệu giả; SDK là bộ thư viện và mã mẫu giúp tích hợp nhanh.
  • Cổng nhà phát triển (developer portal): nơi gom tài liệu, khoá API, thống kê mức dùng và kênh hỗ trợ.

Thuê bao API: những chỗ phí cố định gây ma sát

Thuê bao hấp dẫn nhà cung cấp vì dòng tiền lặp lại, giúp lập kế hoạch hạ tầng và đội hỗ trợ; nhà phát triển được ngân sách cố định và quyền lên bậc khi cần. Chính tính cố định lại gây ma sát. Cam kết theo kỳ không khớp với người dùng thất thường hoặc theo mùa, nên họ trả cho phần không dùng. Bảng bậc gói hiếm khi vừa khít, khiến khách mua tính năng thừa hoặc thiếu đúng thứ cần. Đã trả tiền, khách còn ngại đổi sang API tốt hơn.

Phía nhà cung cấp cũng có rủi ro. Doanh thu phụ thuộc tỷ lệ gia hạn nên một đợt khách rời đi hàng loạt làm kế hoạch lệch ngay; hỗ trợ cho bậc thấp thường bị xếp sau, làm khách nhỏ chán trước khi kịp lớn; kéo người dùng miễn phí lên gói trả phí luôn khó hơn dự tính.

Giảm ma sát không phải bỏ thuê bao mà thiết kế lại quanh nó: cho vượt hạn mức với đơn giá theo mức dùng thay vì chặn cứng; cho đổi bậc giữa kỳ và hạ bậc không phạt; có gói tháng bên cạnh gói năm giảm giá; cảnh báo khi gần hết hạn mức; cho khách nạp trước một lần để nâng hạn mức, như các gói nạp trước của Goong tại Việt Nam [5].

Ba cách kiếm tiền gián tiếp: quảng cáo, đối tác, giới thiệu

Mô hình quảng cáo cho nhà phát triển dùng API miễn phí, còn nhà cung cấp thu tiền từ quảng cáo gắn vào phản hồi API, tài liệu hoặc dịch vụ liên quan. Nó hợp với API có lượng người dùng lớn và ngữ cảnh rõ, vì quảng cáo đúng ngữ cảnh mới bán được giá. Mặt trái là quảng cáo xen vào dữ liệu trả về dễ làm hỏng trải nghiệm của nhà phát triển lẫn người dùng cuối.

Ngoài dạng thuần túy, còn có dạng API làm cửa vào hoạt động quảng cáo. Marketing API của Meta là tập điểm kết nối để tạo và quản lý chiến dịch quảng cáo, và tài liệu không nêu phí dùng API [10]; quyền truy cập dữ liệu chia hai cấp, cấp nâng cao đòi xác minh doanh nghiệp và xét duyệt từng quyền [9].

Mô hình đối tác mở API có chọn lọc cho công ty có sản phẩm bổ trợ, để họ nhúng chức năng hay dữ liệu vào sản phẩm của mình. Nhà cung cấp tiếp cận tệp khách và kênh phân phối của đối tác; tiền đến từ chia sẻ doanh thu, phí cấp phép hoặc giá theo mức dùng. Cái giá là độ phức tạp: tích hợp tốn công, trải nghiệm cuối nằm trong tay đối tác, cần hợp đồng, hỗ trợ và bảo vệ dữ liệu nhất quán, các đối tác có thể tranh nhau cùng một thị trường, và mất một đối tác lớn có thể làm doanh thu sụt mạnh.

Mô hình giới thiệu trả hoa hồng cho bên đưa được người dùng hay giao dịch mới, nhận diện bằng mã theo dõi hoặc đường dẫn riêng. Nhà cung cấp chỉ chi khi có kết quả, nhưng cần điều khoản rõ, công cụ theo dõi đáng tin và cơ chế chống gian lận. Trang đối tác của Skyscanner ghép hai nhánh: chương trình affiliate nhận hoa hồng trên lưu lượng đưa tới, và Travel API để đối tác tự dựng chức năng tìm chuyến [11]. Hình 1 xếp cạnh nhau cả ba mô hình.

So sánh ba mô hình kiếm tiền gián tiếp từ API
Hình 1. Quảng cáo, đối tác và giới thiệu hoa hồng khác nhau ở bên trả tiền, điều kiện và rủi ro (minh hoạ khái niệm).

Định giá và đóng gói: từ giá trị khách nhận được đến bảng gói

Định giá nên bắt đầu từ giá trị chứ không từ chi phí: API giúp khách tiết kiệm bao nhiêu công, giảm bao nhiêu rủi ro, tạo thêm bao nhiêu doanh thu. Đối chiếu với giá của đối thủ và lời khách nói trong phỏng vấn về mức họ chịu trả. Sau đó chọn đơn vị tính (lượt gọi, tin nhắn gửi thành công, lượt tải bản đồ) và hình dạng giá (cố định, theo bậc, theo mức dùng, kết hợp).

Bảng giá tin nhắn Twilio ở Mỹ cho thấy đơn vị tính thường là tổ hợp: 0,0083 USD cho mỗi đoạn tin 160 ký tự, cộng phụ phí nhà mạng, thêm khoản nhỏ cho tin thất bại, phí thuê số theo tháng, và giá giảm khi khối lượng tăng [7]. Càng nhiều thành phần thì khách càng khó ước tính hoá đơn, nên cần máy tính chi phí ngay trên trang.

Đóng gói biến bảng giá thành vài lựa chọn dễ hiểu. Chia khách theo kiểu dùng và ngân sách; đưa tính năng lõi vào mọi bậc; để bậc cao khác biệt ở hạn mức, tính năng nâng cao, hỗ trợ và cam kết SLA. Gói miễn phí hay dùng thử là kênh tiếp thị; gói doanh nghiệp dành cho nhu cầu riêng như đăng nhập một lần (SSO). Bảng giá cần công khai, mỗi bậc có lối nâng cấp rõ (Hình 2).

Hạn mức miễn phí cũng là quyết định có thể đổi. Từ ngày 1/3/2025, Google Maps Platform thay khoản tín dụng 200 USD hằng tháng bằng ngưỡng miễn phí cho từng SKU (mã dịch vụ tính phí) của nhóm dịch vụ lõi và chuyển ba dịch vụ cũ sang trạng thái Legacy, tức không còn phát triển thêm tính năng [6]. Mô hình chi phí của bạn cần chịu được thay đổi như vậy.

Bốn bậc gói API từ miễn phí đến doanh nghiệp
Hình 2. Các bậc gói khác nhau ở hạn mức, mức hỗ trợ và cam kết dịch vụ (minh hoạ khái niệm).

Hỗ trợ và quảng bá: mặt tiền dành cho nhà phát triển

Khách của API là lập trình viên, nên tài liệu và công cụ chính là trang bán hàng: tài liệu đầy đủ và cập nhật, hướng dẫn kèm mã mẫu, SDK, sandbox và cổng nhà phát triển để tự quản lý khoá, xem mức dùng. Phía con người cần cộng đồng, kênh hỗ trợ kỹ thuật theo mức khẩn, SLA cho khách cần độ sẵn sàng cao và gói hỗ trợ có đầu mối riêng.

Quảng bá bắt đầu từ chính mặt tiền ấy rồi lan ra ngoài: hackathon và buổi gặp cộng đồng, bài kỹ thuật, tích hợp sẵn với công cụ phổ biến, câu chuyện thành công của khách và những người làm quan hệ nhà phát triển (developer evangelist). Chỉ số đáng theo dõi là thời gian từ đăng ký đến lần gọi API thành công đầu tiên, vì cản trở ở đây chặn doanh thu phía sau.

Đo lường mức dùng: từ yêu cầu đến hoá đơn

Đo lường nối ba việc: tính tiền, bảo vệ hệ thống và hiểu khách. Mỗi nhà phát triển có khoá API riêng; cổng API ghi số yêu cầu, lượng dữ liệu, tỷ lệ lỗi và độ trễ theo khoá, rồi đổ về bảng điều khiển cho khách và về hệ thống thanh toán để lập hoá đơn (Hình 3). Thống kê theo thời gian còn lộ ra mùa cao điểm và khách sắp chạm trần, tức cơ hội bán gói cao hơn.

Meta gắn giới hạn với quy mô khách: số cuộc gọi của một ứng dụng trong một giờ tính bằng 200 nhân với số người dùng ứng dụng; vượt ngưỡng thì bị throttle và yêu cầu thất bại [8]. Cách này công bằng với ứng dụng nhỏ và bảo vệ hạ tầng, nếu tài liệu giải thích rõ. Dữ liệu dùng còn phục vụ tuân thủ: ở Việt Nam, ngân hàng phải ghi nhật ký toàn bộ việc bên thứ ba dùng Open API tối thiểu ba tháng [3].

Luồng từ yêu cầu API đến hoá đơn và phân tích
Hình 3. Đường đi của một yêu cầu API qua khoá, cổng kiểm soát, ghi lượt dùng và lập hoá đơn (minh hoạ khái niệm).

Chọn mô hình: tám câu hỏi trước khi chốt

Không có mô hình tốt nhất cho mọi API, chỉ có mô hình hợp nhất với mục tiêu, khách hàng và ràng buộc của từng sản phẩm. Tám yếu tố sau nên thành câu hỏi, trả lời bằng dữ liệu của chính bạn.

  • Mục tiêu: cần doanh thu sớm thì nghiêng về trả theo mức dùng hoặc thuê bao; cần phủ rộng thì nghiêng về miễn phí, freemium, giới thiệu.
  • Khách chính: lập trình viên cần tuỳ biến sâu hợp API mở hoặc đối tác; người muốn cắm là chạy hợp tự phục vụ.
  • Giá trị đề xuất: giá phải đi cùng thứ khách cảm nhận được, như tiết kiệm công, giảm rủi ro, dữ liệu độc quyền.
  • Đối thủ: so giá, điều khoản, dịch vụ kèm để tìm chỗ khác biệt thay vì chạy đua giảm giá.
  • Độ phức tạp kỹ thuật: API khó tích hợp, tốn hỗ trợ cần mô hình thu hồi chi phí; API đơn giản có thể nới hạn mức miễn phí.
  • Pháp lý: quyền riêng tư, an ninh, sở hữu trí tuệ và quy định ngành có thể quyết định ai được dùng và có được tính phí không.
  • Khả năng mở rộng: mô hình còn đứng vững khi lượng dùng tăng nhiều lần hoặc chính sách miễn phí phải đổi.
  • Phản hồi và lặp lại: coi mô hình đầu tiên là giả thuyết, điều chỉnh theo khách và đối tác đầu tiên.

Hình 4 gộp tám yếu tố trên thành hai trục để phác nhanh: mục tiêu chính (phủ sóng hay doanh thu trực tiếp) và chi phí hỗ trợ mỗi khách. Mỗi góc gợi ý một nhóm mô hình; đây là phân loại tham khảo của bài, không phải quy tắc cứng.

Ma trận chọn mô hình theo mục tiêu và chi phí hỗ trợ
Hình 4. Gợi ý nghiêng mô hình theo mục tiêu chính và chi phí hỗ trợ mỗi khách (phân loại tham khảo của bài).

Ba ca quốc tế và nền kinh tế API: lợi ích và rủi ro

Ba ca đã gặp ở trên, Google Maps, Meta và Twilio, đi bằng ba đường khác nhau: ngưỡng miễn phí theo từng dịch vụ [6], cấp quyền và giới hạn tốc độ chặt chẽ [8][9], giá theo từng đoạn tin gửi đi [7]. Điểm chung là tài liệu và công cụ cho nhà phát triển, cùng quy tắc truy cập, giới hạn và giá được công bố rõ ràng.

Rộng hơn, nền kinh tế API là hệ sinh thái xoay quanh việc phát triển, phân phối và dùng API. Bốn động lực thường được nêu: số hoá buộc hệ thống trao đổi dữ liệu, nền tảng lớn chứng minh giá trị của hệ sinh thái, di động và đám mây đòi dịch vụ ghép được với nhau, và doanh nghiệp số dùng API để vào các ngành mới. Với doanh nghiệp, lợi ích thường được kể là thử ý tưởng nhanh hơn, vươn tới khách qua kênh của đối tác, trải nghiệm liền mạch (đăng nhập qua mạng xã hội, cổng thanh toán, bản đồ), vận hành gọn nhờ nối hệ thống, dữ liệu hợp nhất để phân tích và thêm nguồn thu; giá trị nền tảng tăng theo số bên tham gia (hiệu ứng mạng).

Rủi ro đi cùng: mở API là mở thêm bề mặt tấn công nên cần xác thực, phân quyền, mã hoá; API thành hợp đồng giữa các bên nên cần quản trị vòng đời gồm phiên bản, thông báo ngừng hỗ trợ và tương thích ngược; hệ sinh thái còn cần đầu tư dài hạn cho quan hệ với nhà phát triển (Hình 5).

Các bên quanh một API và dòng giá trị
Hình 5. Hệ sinh thái quanh một API: nhà phát triển, đối tác, người giới thiệu, nhà quảng cáo, người dùng cuối và cơ quan quản lý (minh hoạ khái niệm).

Làm từng bước: từ ý tưởng đến bảng giá đầu tiên

Bảy bước sau gom các phần trên thành một quy trình làm được trong một quý. Bước nào cũng có thể quay lại khi có dữ liệu mới, nhất là sau những khách trả tiền đầu tiên và khi đối thủ đổi giá.

  • Bước 1: Xác định đơn vị giá trị (tin nhắn thành công, lượt tra cứu, giao dịch hoàn tất) và ai hưởng lợi.
  • Bước 2: Chia khách thành hai đến ba nhóm, đo kiểu dùng: đều, theo mùa hay đột biến.
  • Bước 3: Chọn một mô hình chính, một mô hình phụ, ví dụ trả theo mức dùng kèm gói nạp trước.
  • Bước 4: Dựng ba đến bốn bậc gói; công bố bảng giá và máy tính chi phí.
  • Bước 5: Lắp đo lường trước khi thu tiền: khoá API, giới hạn tốc độ, bảng thống kê, đường nối sang hoá đơn.
  • Bước 6: Dựng mặt tiền: tài liệu, sandbox, mã mẫu, kênh hỗ trợ có người trả lời.
  • Bước 7: Chạy thử với nhóm nhỏ, xem lại giá và hạn mức mỗi quý.

Tình huống áp dụng tại Việt Nam

Open API ngân hàng là ca rõ nhất về mô hình đối tác có quản trị. Thông tư 64/2024/TT-NHNN về Open API có hiệu lực từ ngày 1/3/2025 [1]. Open API là tập hợp API ngân hàng cung cấp để bên thứ ba có hợp đồng với ngân hàng trực tiếp kết nối và xử lý dữ liệu, chia thành Open API cơ bản và Open API khác [2]. Theo bản tóm tắt, nhóm khởi tạo thanh toán, nạp và rút tiền ví điện tử chỉ được mở cho ngân hàng hoặc tổ chức trung gian thanh toán [2].

Phần quản trị khiến mô hình này khác chương trình đối tác thông thường. Theo Tạp chí Ngân hàng, thời hạn truy vấn sau khi khách đồng ý không quá 180 ngày, trừ khi khách và ngân hàng thoả thuận khác; ngân hàng chịu trách nhiệm lựa chọn, thẩm định, giám sát bên thứ ba, ghi nhật ký tối thiểu ba tháng và bảo đảm hệ thống đạt tối thiểu cấp độ 3 về an toàn thông tin [3]. Các trang tóm tắt được dẫn không nêu quy định về phí [1][2], nên cần đọc toàn văn và hợp đồng trước khi tính doanh thu.

Zalo công bố bảng giá tin nhắn theo loại mẫu mà doanh nghiệp gửi tới người dùng, một ví dụ trả theo mức dùng có phân loại. Mẫu xác thực, yêu cầu chuyển khoản và voucher giá 300 đồng mỗi tin, các loại còn lại 200 đồng; nút bấm đầu tiên miễn phí, từ nút thứ hai tính 100 đồng. Giá chưa gồm thuế giá trị gia tăng và áp dụng cho tin ở trạng thái xử lý thành công [4].

Về bản đồ, Goong công bố cấu trúc giá nhiều lớp: tặng 100 USD không giới hạn thời gian khi đăng ký, đơn giá theo mức dùng giảm dần khi vượt 100.000 và 200.000 truy vấn mỗi tháng, bốn gói nạp trước nâng hạn mức từ 30.000 đến 400.000 lượt mỗi tháng, và một mục riêng cho doanh nghiệp trên 500.000 truy vấn mỗi tháng nhưng không nêu giá [5]. Đặt cạnh việc Google đổi cách tính miễn phí [6], doanh nghiệp Việt Nam nên so nhà cung cấp theo kịch bản dùng thật. Trang Goong ghi hai giới hạn tốc độ không khớp cho gói tặng, 180 truy vấn mỗi phút và 5 truy vấn mỗi giây [5], nên cần hỏi lại trước khi ký.

Sai lầm thường gặp, giới hạn và khi nào không nên dùng

Lỗi phổ biến nhất là định giá theo chi phí hạ tầng mà quên giá trị khách nhận được, hoặc đặt giá theo đối thủ mà không biết chi phí phục vụ của mình. Thu tiền trước khi đo được mức dùng dẫn đến hoá đơn bị tranh cãi; hạn mức miễn phí đổi đột ngột làm mất lòng tin.

  • Quảng cáo xen vào phản hồi API làm hỏng sản phẩm của nhà phát triển.
  • Phụ thuộc một đối tác lớn: họ đổi hướng thì doanh thu mất theo.
  • Hoa hồng giới thiệu thiếu công cụ theo dõi và chống gian lận sẽ bị lạm dụng.
  • Chưa nên thu phí hoặc mở cho bên thứ ba khi API chỉ dùng nội bộ, giá trị mỗi khách thấp hơn chi phí hỗ trợ, hoặc chưa có căn cứ pháp lý để chia sẻ dữ liệu.

Kế hoạch thử nghiệm bốn tuần và câu hỏi tự kiểm

Bốn tuần đủ để dựng bảng giá nháp và thử với vài khách thật, miễn là đo được mức dùng ngay từ đầu. Mỗi tuần kết thúc bằng một quyết định rõ ràng: giữ, sửa hay bỏ một giả định về giá, và ghi lại lý do.

  • Tuần 1: kiểm kê đơn vị dùng và chi phí phục vụ; xác định ba nhóm khách đầu tiên.
  • Tuần 2: dựng bảng giá nháp ba bậc; hỏi năm đến tám khách về mức họ chịu trả.
  • Tuần 3: bật khoá API, giới hạn tốc độ, bảng thống kê; chạy thử miễn phí với nhóm nhỏ.
  • Tuần 4: đọc số liệu (thời gian đến lần gọi đầu, số khách chạm hạn mức, số phiếu hỗ trợ) rồi chỉnh bảng giá.

Câu hỏi tự kiểm: khách của bạn dùng đều hay theo mùa, và mô hình hiện tại thưởng hay phạt kiểu dùng đó? Doanh thu có phụ thuộc vào một đối tác hay một khách lớn không? Bạn đã đo đủ để chứng minh một hoá đơn là đúng chưa?

Kết luận

Mô hình kinh doanh dựa trên API không dừng ở việc chọn một kiểu thu phí. Phần giá trị nằm ở bảng giá neo vào lợi ích của khách, bậc gói rõ, mặt tiền tốt cho nhà phát triển, đo lường chính xác và nguồn thu gián tiếp được kiểm soát. Chuỗi hai bài khép lại ở đây; bạn có thể xem lại phần một về các mô hình thu phí trực tiếp rồi áp dụng khung chọn mô hình ở trên.

Nguồn và phương pháp

Bài là tổng hợp và phân tích có hỗ trợ AI, diễn đạt lại bằng lời riêng, không phải bản dịch. Nội dung dựa trên phần sau (từ trang 65 đến hết) của tài liệu "API Business Models" (Super Guide của Daniel Pereira, The Business Model Analyst, 2022); dàn ý, ví dụ, phân tích và các hình đều do bài tự xây dựng. Người đọc nên tìm tài liệu gốc để đọc đầy đủ.

Các nguồn web được truy cập ngày 20/10/2026. Thông tin về Open API ngân hàng lấy từ trang của Ngân hàng Nhà nước Việt Nam, một trang hỏi đáp pháp luật và Tạp chí Ngân hàng; bảng giá của Zalo, Goong, Twilio, Google, tài liệu của Meta và trang đối tác của Skyscanner là thông tin do chính các hãng công bố và có thể thay đổi bất cứ lúc nào.

Điều chưa kiểm chứng: chưa đối chiếu toàn văn Thông tư 64/2024/TT-NHNN và chưa xác nhận hiệu lực hiện nay của từng điều khoản; việc nhóm API thanh toán thuộc điểm c khoản 1 Điều 6 suy ra từ thứ tự liệt kê trong trang tóm tắt; trang Goong có chỗ chưa nhất quán; trang giá của Zalo không ghi ngày áp dụng; cách xếp bốn góc phần tư ở Hình 4 là phân loại tham khảo của bài.