# 如何为 API 访问收费：开发者指南

> 分步指南：通过按次调用、订阅套餐或预付费额度计费，让你的 API 实现商业化。涵盖计量、结账集成和用量追踪。
- **Author**: Ayush Agarwal
- **Published**: 2026-03-25
- **Category**: Payments, API, How-To
- **URL**: https://dodopayments.com/blogs/zh/charge-for-api-access

---

为 API 访问收费有三种实用方式：按次调用的用量计费、带速率限制的订阅套餐，以及预付费额度。按次调用适合成本随用量变化的高价 API，订阅套餐适合成本可预测的低价 API，而预付额度适合不同端点成本差异巨大的 AI 产品。无论选择哪种方式，你都需要按客户计量、结账流程，以及处理全球销售税的方法。

你构建了一个 API。它解决了一个真实问题，速度很快，开发者也开始询问如何接入。但一旦你走过"免费测试版"阶段，就会遇到瓶颈。可靠的 API 计费建立在两个基础之上：支付 API 中的[幂等键](https://dodopayments.com/blogs/idempotency-keys-payment-api)，确保重试不会重复扣款；以及[权益管理](https://dodopayments.com/blogs/entitlement-management-saas)，用于控制每个访问层级。

速率限制不是计费。生成 API 密钥也不是支付策略。许多创始人尝试自行构建计费逻辑，最后才意识到，处理按比例分摊的用量、全球税务合规和失败支付，本身就是一项全职工作。如果你花在计费代码上的时间比 API 逻辑还多，那就说明方向错了。

API 商业化需要转变思路。你不再只是销售一项服务，而是在销售一种会随客户规模扩展的资源访问权。在本指南中，我们将拆解三种最有效的 API 计费模式，并准确展示如何实现它们，同时避免让自己陷入困境。

## API 的 3 种计费模式

选择合适的模式取决于 API 的价值主张和基础设施成本。如果每次调用都会产生成本（例如 LLM 封装服务），你需要一种能够保护利润率的模式。如果成本固定，则可以选择一种鼓励高用量的模式。

> 大多数 SaaS 创始人都会低估税务合规的成本。它不只是申报税款，还包括在每个拥有客户的司法管辖区进行注册、在结账时计算税款、缴税，以及做好审计准备。
>
> \- Ayush Agarwal，Dodo Payments 联合创始人兼 CPTO

### 1. 按次调用（基于用量）

这是对开发者来说最透明的模式。他们只为实际使用的部分付费。调用 100 次，就支付 100 次的费用；一次都没调用，就无需支付费用。这通常被称为 SaaS 的[基于用量计费](https://dodopayments.com/blogs/usage-based-billing-saas)。

**适用场景：**

- 高成本 API（AI、数据 enriquecimiento、SMS）
- 用量不可预测的服务
- 希望降低新开发者使用门槛时

**优点：**

- 成本与价值完全匹配
- 不存在用户为未使用容量付费的"定价悬崖"
- 可随客户增长无限扩展

**缺点：**

- 月度收入可能难以预测
- 需要可靠的实时用量追踪
- 企业部门可能更难进行预算

### 2. 带速率限制的订阅套餐

这是经典的 SaaS 模式。你提供多个套餐（例如 Starter、Pro、Enterprise），每个套餐收取固定的月费。每个套餐包含特定数量的请求，并设有硬性速率限制。

**适用场景：**

- 基础设施开销可预测的低成本 API
- 开发者重视预算可预测性的工具
- 希望通过更高性能促使用户升级套餐时

**优点：**

- 可预测的经常性收入
- 客户更容易获得内部预算审批
- 易于理解和沟通

**缺点：**

- 用户经常会为未使用的容量付费
- 高频用户可能会觉得硬性限制是一种"惩罚"
- 无法充分捕获高级用户创造的价值

### 3. 预付费额度计费

在这种模式下，客户预先购买一定的预付余额。每次 API 调用会"消耗"一定数量的预付额度。这是一种混合模式，将订阅的可预测性与基于用量计费的灵活性结合起来。你可以在我们关于[计费额度](https://dodopayments.com/blogs/billing-credits-pricing-cashflow)的文章中了解更多信息。

**适用场景：**

- 不同端点成本差异巨大的 AI 平台
- 希望提供"预付费"折扣的服务
- 希望将计费周期与使用周期解耦时

**优点：**

- 提前获得现金流（预付费模式）
- 足够灵活，可以处理复杂定价（例如标准调用 1 美元，高级调用 5 美元）
- 降低未支付用量账单的风险

**缺点：**

- 如果预付额度与美元的换算比例不清晰，可能会令人困惑
- 需要"余额不足"通知系统
- 未使用的预付额度可能造成会计处理复杂性（额度损耗）

### 第四种选择：面向代理调用方的按请求支付

上述三种模式都假设调用方在首次请求前已经完成注册。但当调用方是一个在运行时发现你端点的自主代理时，这一假设就不成立了。

[x402 协议](https://dodopayments.com/blogs/x402-protocol)通过使用 HTTP 402 状态码返回价格报价，让调用方完成支付，然后提供响应，从而处理了这种情况。对于一次性的机器消费者，它完全移除了注册步骤。配套的[代理支付授权 AP2 规范](https://dodopayments.com/blogs/ap2-protocol-agent-payments)定义了代理如何证明自己获得了消费授权；如果之后有人对扣款提出异议，这正是你所需要的证明。

这不是对上述三种模式的替代。你可以把它视为额外的流量入口，用于承接原本会被注册墙挡住的流量。

## 为什么选择 Dodo Payments 进行 API 计费

从零开始构建 API 计费系统是一个陷阱。你必须处理货币兑换、在 190 多个国家收取 VAT/GST，以及不可避免的"我的信用卡过期了"邮件。

Dodo Payments 作为 SaaS 的[MoR（名义商户）](https://dodopayments.com/blogs/merchant-of-record-for-saas)开展业务。这意味着我们会处理整个支付技术栈，包括税务合规和风控。对于 API 创始人，我们原生支持上述三种模式。

- **基于用量计费：**直接从你的 API 网关接收事件。我们汇总这些事件，并在月末向客户收费。
- **预付费额度计费：**销售预付额度包，或将预付额度包含在订阅中。我们追踪余额并自动处理超额用量。
- **全球税务：**我们在全球范围内计算并缴纳销售税，因此你无需在每个用户所在国家注册 VAT。

## 分步实现：基于用量的 API 计费

下面我们通过一个真实场景，逐步了解如何实现按次调用模式。这是现代 API[实现基于用量计费](https://dodopayments.com/blogs/implement-usage-based-billing)最常见的方式。

### 1. 创建计量产品

首先，你需要定义收费项目。在 Dodo Payments 控制台中，你可以创建一个"计量器"。对于 API 来说，通常是用于追踪成功请求数量的"计数"计量器。

你可以设置单位价格（例如每次调用 0.01 美元），甚至可以设置免费阈值（例如前 1,000 次调用免费）。这是实现[免费增值策略](https://dodopayments.com/blogs/why-free-users-dont-upgrade-saas-tactics)的好方法。

### 2. 设置 API 密钥管理

你的应用需要知道请求来自谁。当用户注册并完成结账后，你应该生成唯一的 API 密钥，并将其与用户在 Dodo Payments 中的 `customer_id` 关联起来。

当请求到达你的 API 时，第一步是验证密钥，并获取关联的客户 ID。

### 3. 接收用量事件

这是集成的核心。每当用户成功调用你的 API 时，你就向 Dodo Payments 发送一个"用量事件"。你无需担心计算，只要告诉我们："客户 A 刚刚完成了一次调用。"

```javascript
import DodoPayments from "dodopayments";

const client = new DodoPayments({
  bearerToken: process.env["DODO_PAYMENTS_API_KEY"],
});

// In your API handler
async function handleApiRequest(req, res) {
  const customerId = await getCustomerIdFromApiKey(req.headers["x-api-key"]);

  // Process the actual API logic
  const result = await processRequest(req.body);

  // Ingest the usage event asynchronously
  client.usageEvents
    .ingest({
      events: [
        {
          event_id: `req_${Date.now()}_${Math.random().toString(36).substr(2, 9)}`,
          customer_id: customerId,
          event_name: "api_request",
          timestamp: new Date().toISOString(),
          metadata: {
            endpoint: req.path,
            status: 200,
          },
        },
      ],
    })
    .catch((err) => console.error("Failed to track usage", err));

  res.json(result);
}
```

### 4. 自动计费

在计费周期结束时，Dodo Payments 会查看该客户接收到的事件总数。我们应用你的定价规则、生成账单，并从客户已保存的支付方式中扣款。

如果你使用[订阅定价模式](https://dodopayments.com/blogs/subscription-pricing-models)，用量费用会作为明细项添加到客户的周期性账单中。

### 5. 处理 Webhook

计费并不总是一帆风顺。卡片会过期，支付也会失败。你应该监听来自 Dodo Payments 的 Webhook，以处理这些情况。如果支付失败，你可以暂时停用用户的 API 密钥，直到他们更新账单信息。

## API 计费架构

下图展示了典型的基于用量的 API 计费流程。目标是尽可能将计费逻辑移出关键路径。

```mermaid
flowchart LR
    A[Developer] -->|"API Call with Key"| B[API Gateway]
    B -->|"1. Validate Key"| C[Auth Service]
    C -->|"2. Return Customer ID"| B
    B -->|"3. Process Request"| D[Your API Logic]
    D -->|"4. Success Response"| B
    B -->|"5. Ingest Event"| E[Dodo Payments]
    B -->|"6. Return Data"| A
    E -->|"7. End of Cycle"| F[Charge Customer]
```

通过异步接收步骤（步骤 5），你可以确保 API 延迟不会受到计费系统影响。如果接收因某种原因失败，你可以稍后重试，而不会阻塞用户请求。

## 对比：哪种模式适合你？

| 功能             | 按次调用 | 订阅套餐 | 预付费额度 |
| :--------------- | :------- | :------- | :--------- |
| **收入可预测性** | 低       | 高       | 中         |
| **客户预算管理** | 难       | 容易     | 中         |
| **实现难度**     | 复杂     | 简单     | 中等       |
| **价值匹配度**   | 完美     | 良好     | 极佳       |
| **现金流**       | 后付费   | 预付费   | 预付费     |

如果你刚刚起步，[AI 定价模式](https://dodopayments.com/blogs/ai-pricing-models)通常会倾向于预付额度或按次调用，因为底层成本变化很大。对于更传统的数据 API，订阅套餐通常是实现稳定增长的最稳妥选择。

如果你需要的只是计量层，而不是完整的支付技术栈，[Orb 计费替代方案](https://dodopayments.com/blogs/orb-billing-alternatives)汇总了专用计量供应商在事件接收和聚合方面的差异。

## API 商业化的进阶技巧

掌握基础知识后，你就可以开始优化策略，提高收入并改善开发者体验。

### 设置速率限制

即使你按次收费，仍然需要设置速率限制。它们可以保护你的基础设施免受"吵闹邻居"和开发者代码中意外循环的影响。当达到限制时，你应该返回 `429 Too Many Requests` 状态码。

确保你的[计费 UX 和用量上限](https://dodopayments.com/blogs/billing-ux-usage-caps-alerts)清晰易懂。开发者应该能够在控制台中查看当前用量，以及距离限制还有多远。

### 处理超额用量

如果使用订阅模式，你需要决定如何处理超过套餐限制的用量。有两种选择：

1. **硬上限：**停止 API 服务，直到下一个周期开始或用户升级套餐。
2. **带超额费用的软上限：**允许继续使用，但对额外调用按单位收费。

Dodo Payments 可以轻松地为任何订阅套餐添加超额定价。这样，你就不会错失最成功客户带来的收入。

### 免费套餐策略

免费套餐是 API 最好的营销方式。它允许开发者在无需提供信用卡的情况下验证你的工具是否适合自己的概念。不过要注意，不要让免费套餐过于慷慨。

一种常见策略是每月提供 1,000 次免费调用，超出后要求用户提供[支付方式](https://dodopayments.com/blogs/how-to-accept-online-payments)。这样可以筛选出兴趣用户，并识别真正从你的服务中获得价值的用户。

### 文档也是产品的一部分

开发者不会为自己无法理解的 API 付费。你的文档应该清楚说明价格、限制以及错误处理方式。直接链接到你的[API 参考文档](https://docs.dodopayments.com/api-reference/introduction)，并提供 [SDK](https://docs.dodopayments.com/developer-resources/dodo-payments-sdks)，让集成尽可能简单。

## 常见问题

### 如何防止用户共享 API 密钥？

你应该将 API 密钥绑定到特定账户，并监控可疑的使用模式，例如同一个密钥同时从几十个不同 IP 地址使用。你还可以将 IP 白名单作为面向企业客户的可选安全功能。

### 我应该为失败的 API 请求收费吗？

通常不应该。为 `500 Internal Server Error` 收费，是快速失去用户信任的方法。大多数创始人只会为成功的 `2xx` 响应接收用量事件。不过，如果 `4xx` 错误是由用户输入无效导致的，你仍然可以收费，因为这些请求依然消耗了计算资源。

### 如何处理 API 的全球税务？

当你在全球范围内销售时，从技术上讲，你需要在开发者所在国家承担销售税（VAT/GST）义务。手动管理这件事极其复杂。使用像 Dodo Payments 这样的[MoR（名义商户）](https://dodopayments.com/blogs/merchant-of-record-for-saas)可以解决这一问题，因为我们会成为"销售方"，代表你处理所有税款的收取和缴纳。

### 我可以针对不同端点提供不同价格吗？

可以。当你向 Dodo Payments 接收事件时，可以附带所使用端点的元数据。然后，你可以为"标准"端点和"高级"端点设置不同的计量器或预付额度扣减比例。这在[API 商业化](https://dodopayments.com/blogs/api-monetization)策略中很常见。

### 如果客户的用量意外激增，会发生什么？

意外的用量激增可能导致"账单冲击"。建议设置自动提醒，在用量达到特定里程碑时通知你和客户（例如达到其典型用量的 50%、80% 和 100%）。你还可以设置硬性支出上限，防止成本失控。

## 总结

为 API 访问收费，不只是简单地设置一道付费墙，而是要构建一个能随用户增长的可扩展系统。无论选择按次调用、订阅还是预付额度，目标都是让计费流程对开发者尽可能无感。

将全球支付、税务合规和用量聚合等繁重工作交给 Dodo Payments 后，你就可以专注于真正重要的事情：构建人们确实想使用的 API。

准备好开始让你的 API 实现商业化了吗？查看我们的[定价](https://dodopayments.com/pricing)，或深入阅读[基于用量计费指南](https://docs.dodopayments.com/developer-resources/usage-based-billing-guide)，今天就开始吧。
---
- [More Payments articles](https://dodopayments.com/blogs/category/payments)
- [All articles](https://dodopayments.com/blogs)