Huly 如何叠加 billing 与 payment 服务并配置 Stripe 沙箱【免费下载链接】platformHuly — All-in-One Project Management Platform (alternative to Linear, Jira, Slack, Notion, Motion)项目地址: https://gitcode.com/GitHub_Trending/platform80/platformHuly 的 docker compose 开发栈默认并不运行真实的 billing 与 payment 服务基础 compose 文件只是向前端宣告了PAYMENT_URLhttp://huly.local:3040见 dev/docker-compose.yaml。要让客户端能够访问计费功能并启用套餐限制plan-limit restrictions需要叠加 dev/docker-compose.ext.yaml 这个 overlay把payment和billing两个服务实际拉起来并配置 Stripe 提供商。本文基于一个已可运行的 Huly docker compose 开发环境完成 overlay 叠加、Stripe 沙箱凭据配置与结果验证。两个服务各自的职责payment镜像hardcoreeng/payment端口 3040provider 无关的支付服务负责通过提供商 API 创建订阅 checkout 并接收 webhook。完整流程见 services/payment/pod-payment/README.md客户端POST /api/v1/subscriptions/:workspace/subscribe→ payment 服务经提供商创建 checkout → 用户完成支付 → 提供商向POST /api/v1/webhooks/stripe发送事件 → payment 服务把订阅写回 accounts 服务。billing镜像hardcoreeng/billing端口 4042依赖cockroach、minio要求service_healthy、account三个服务overlay 中设置USAGE_UPDATE_INTERVAL600注释说明开发环境每 10 分钟复核一次 workspace 用量默认值为 1 小时。基础 compose 已经设置PAYMENT_URL所以 ext overlay 只需给 front 补充BILLING_URLhttp://huly.local:4042环境变量是加性合并的。前端只有在BILLING_URL非空时才会注册 billing 插件这一点可在 dev/prod/src/platform.ts 中确认。准备 Stripe 沙箱凭据按 services/payment/pod-payment/README.md 的 Stripe Provider 一节需要三个环境变量变量说明文档示例值STRIPE_API_KEYStripe API secret keysk_live_...或sk_test_...STRIPE_WEBHOOK_SECRETWebhook 签名密钥whsec_...STRIPE_SUBSCRIPTION_PLANS套餐到 Price ID 的映射commontier:price_1a;raretier:price_2;epictier:price_3;legendarytier:price_4映射格式为{plan}{type}:{priceId};...其中priceId是 Stripe Price ID形如price_1abc123文档说明可以在 Stripe Dashboard 的 Products 下找到。沙箱场景对应 README 示例中的sk_test_...形式密钥webhook 端点注册在/api/v1/webhooks/stripe。一个必须注意的限制同一时间只能有一个 provider 生效。README 明确写道如果配置了 PolarPOLAR_ACCESS_TOKEN等Stripe 不会被初始化使用 Stripe 时就不要设置POLAR_*变量。在宿主环境设置变量overlay 文件头注释说明提供商凭据从宿主环境读取示例为dev/.env或 shell 变量包括PAYMENT_USE_SANDBOX默认trueSTRIPE_API_KEY、STRIPE_WEBHOOK_SECRET、STRIPE_SUBSCRIPTION_PLANSPolar 对应的POLAR_ACCESS_TOKEN、POLAR_WEBHOOK_SECRET、POLAR_ORGANIZATION_ID、POLAR_SUBSCRIPTION_PLANS本场景不使用。overlay 中传给 payment 容器的写法是STRIPE_API_KEY${STRIPE_API_KEY:-}这类空回退形式即宿主环境未设置时容器内拿到空值服务仍会启动。billing 容器还有DB_URL${DB_CR_URL}和STORAGE_CONFIG${STORAGE_CONFIG}两个引用宿主环境的变量需要确保宿主环境同样提供它们。这里存在两处文档口径不一致如实说明dev/docker-compose.ext.yaml 注释写 All are optional — without them the service starts in sandbox mode无凭据时以沙箱模式启动、不对外发起调用而 common/config/rush/command-line.json 中docker:up:ext命令的 description 把STRIPE_API_KEY、STRIPE_WEBHOOK_SECRET、STRIPE_SUBSCRIPTION_PLANS或POLAR_*等价项列为 Required env。按 overlay 注释无凭据也能启动但不发起外呼要真正完成 Stripe 沙箱订阅流程应按 rush 命令的说明把这三个变量配置齐全。用 overlay 启动服务栈最短主路径对应 overlay 文件头注释的用法docker compose -f docker-compose.yaml -f docker-compose.ext.yaml up或等价的 rush 命令common/config/rush/command-line.json 中docker:up:ext的 shellCommand 为cd ./dev docker compose -f docker-compose.yaml -f docker-compose.ext.yaml up -d --force-recreaterush docker:up:ext可选分支如果希望保持小占用、只在 min 配置上叠加 billing/paymentoverlay 注释给出的组合是docker compose -f docker-compose.yaml -f docker-compose.min.yaml -f docker-compose.ext.yaml up这能工作是因为 dev/docker-compose.min.yaml 会把payment、billing收进profiles: [full]而 ext overlay 用profiles: !override []清掉该门禁。overlay 中影响本次任务的关键配置摘录原文见 dev/docker-compose.ext.yamlpaymentports: 3040:3040depends_on: account环境变量含ACCOUNTS_URLhttp://huly.local:3000、FRONT_URLhttp://huly.local:8087、USE_SANDBOX${PAYMENT_USE_SANDBOX:-true}及三个STRIPE_*透传billingports: 4042:4042depends_on为 cockroachservice_started、minioservice_healthy、accountservice_startedfront新增BILLING_URLhttp://huly.local:4042。结果验证端口与依赖overlay 声明payment监听 3040、billing监听 4042billing 对 minio 要求service_healthyminio 未就绪时 billing 不会进入运行状态。客户端识别前端仅当BILLING_URL非空时才注册 billing 应用dev/prod/src/platform.ts 中的条件判断叠加 overlay 后客户端应能看到 billing 入口这是 overlay 注释中 so the client picks them up 所指的生效标志。订阅流程payment README 记载的请求路径与成功回跳客户端POST /api/v1/subscriptions/:workspace/subscribeBearer tokenbody 含typetier或support与plan成功响应返回checkoutId与checkoutUrl文档示例中为checkout_abc123/ Polar 的 checkout 链接仅作文档示例用户完成支付后被重定向到FRONT_URL/workbench/setting/setting/billing?paymentsuccesscheckout_id{CHECKOUT_ID}paymentsuccess查询参数即文档给出的成功标志。webhook 与管理端点Stripe 事件发送到/api/v1/webhooks/stripe管理侧可用GET /api/v1/subscriptions/:subscriptionIdadmin only查看订阅、POST /api/v1/subscriptions/:subscriptionId/cancel取消订阅。限制只有一个 provider 可以生效配置了POLAR_*时 Stripe 不会初始化两者不能同时使用。不设提供商凭据时服务以沙箱模式运行、不发起外呼此时订阅 checkout 无法真正创建两处文档对凭据是否必需的表述不一致如前所述完成 Stripe 沙箱订阅应配齐STRIPE_API_KEY、STRIPE_WEBHOOK_SECRET、STRIPE_SUBSCRIPTION_PLANS。STRIPE_SUBSCRIPTION_PLANS中的 Price ID 必须与你在 Stripe 账户中实际创建的 Price 一致README 未提供可用的公共测试值。【免费下载链接】platformHuly — All-in-One Project Management Platform (alternative to Linear, Jira, Slack, Notion, Motion)项目地址: https://gitcode.com/GitHub_Trending/platform80/platform创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Huly 如何叠加 billing 与 payment 服务并配置 Stripe 沙箱【免费下载链接】platformHuly — All-in-One Project Management Platform (alternative to Linear, Jira, Slack, Notion, Motion)项目地址: https://gitcode.com/GitHub_Trending/platform80/platformHuly 的 docker compose 开发栈默认并不运行真实的 billing 与 payment 服务基础 compose 文件只是向前端宣告了PAYMENT_URLhttp://huly.local:3040见 dev/docker-compose.yaml。要让客户端能够访问计费功能并启用套餐限制plan-limit restrictions需要叠加 dev/docker-compose.ext.yaml 这个 overlay把payment和billing两个服务实际拉起来并配置 Stripe 提供商。本文基于一个已可运行的 Huly docker compose 开发环境完成 overlay 叠加、Stripe 沙箱凭据配置与结果验证。两个服务各自的职责payment镜像hardcoreeng/payment端口 3040provider 无关的支付服务负责通过提供商 API 创建订阅 checkout 并接收 webhook。完整流程见 services/payment/pod-payment/README.md客户端POST /api/v1/subscriptions/:workspace/subscribe→ payment 服务经提供商创建 checkout → 用户完成支付 → 提供商向POST /api/v1/webhooks/stripe发送事件 → payment 服务把订阅写回 accounts 服务。billing镜像hardcoreeng/billing端口 4042依赖cockroach、minio要求service_healthy、account三个服务overlay 中设置USAGE_UPDATE_INTERVAL600注释说明开发环境每 10 分钟复核一次 workspace 用量默认值为 1 小时。基础 compose 已经设置PAYMENT_URL所以 ext overlay 只需给 front 补充BILLING_URLhttp://huly.local:4042环境变量是加性合并的。前端只有在BILLING_URL非空时才会注册 billing 插件这一点可在 dev/prod/src/platform.ts 中确认。准备 Stripe 沙箱凭据按 services/payment/pod-payment/README.md 的 Stripe Provider 一节需要三个环境变量变量说明文档示例值STRIPE_API_KEYStripe API secret keysk_live_...或sk_test_...STRIPE_WEBHOOK_SECRETWebhook 签名密钥whsec_...STRIPE_SUBSCRIPTION_PLANS套餐到 Price ID 的映射commontier:price_1a;raretier:price_2;epictier:price_3;legendarytier:price_4映射格式为{plan}{type}:{priceId};...其中priceId是 Stripe Price ID形如price_1abc123文档说明可以在 Stripe Dashboard 的 Products 下找到。沙箱场景对应 README 示例中的sk_test_...形式密钥webhook 端点注册在/api/v1/webhooks/stripe。一个必须注意的限制同一时间只能有一个 provider 生效。README 明确写道如果配置了 PolarPOLAR_ACCESS_TOKEN等Stripe 不会被初始化使用 Stripe 时就不要设置POLAR_*变量。在宿主环境设置变量overlay 文件头注释说明提供商凭据从宿主环境读取示例为dev/.env或 shell 变量包括PAYMENT_USE_SANDBOX默认trueSTRIPE_API_KEY、STRIPE_WEBHOOK_SECRET、STRIPE_SUBSCRIPTION_PLANSPolar 对应的POLAR_ACCESS_TOKEN、POLAR_WEBHOOK_SECRET、POLAR_ORGANIZATION_ID、POLAR_SUBSCRIPTION_PLANS本场景不使用。overlay 中传给 payment 容器的写法是STRIPE_API_KEY${STRIPE_API_KEY:-}这类空回退形式即宿主环境未设置时容器内拿到空值服务仍会启动。billing 容器还有DB_URL${DB_CR_URL}和STORAGE_CONFIG${STORAGE_CONFIG}两个引用宿主环境的变量需要确保宿主环境同样提供它们。这里存在两处文档口径不一致如实说明dev/docker-compose.ext.yaml 注释写 All are optional — without them the service starts in sandbox mode无凭据时以沙箱模式启动、不对外发起调用而 common/config/rush/command-line.json 中docker:up:ext命令的 description 把STRIPE_API_KEY、STRIPE_WEBHOOK_SECRET、STRIPE_SUBSCRIPTION_PLANS或POLAR_*等价项列为 Required env。按 overlay 注释无凭据也能启动但不发起外呼要真正完成 Stripe 沙箱订阅流程应按 rush 命令的说明把这三个变量配置齐全。用 overlay 启动服务栈最短主路径对应 overlay 文件头注释的用法docker compose -f docker-compose.yaml -f docker-compose.ext.yaml up或等价的 rush 命令common/config/rush/command-line.json 中docker:up:ext的 shellCommand 为cd ./dev docker compose -f docker-compose.yaml -f docker-compose.ext.yaml up -d --force-recreaterush docker:up:ext可选分支如果希望保持小占用、只在 min 配置上叠加 billing/paymentoverlay 注释给出的组合是docker compose -f docker-compose.yaml -f docker-compose.min.yaml -f docker-compose.ext.yaml up这能工作是因为 dev/docker-compose.min.yaml 会把payment、billing收进profiles: [full]而 ext overlay 用profiles: !override []清掉该门禁。overlay 中影响本次任务的关键配置摘录原文见 dev/docker-compose.ext.yamlpaymentports: 3040:3040depends_on: account环境变量含ACCOUNTS_URLhttp://huly.local:3000、FRONT_URLhttp://huly.local:8087、USE_SANDBOX${PAYMENT_USE_SANDBOX:-true}及三个STRIPE_*透传billingports: 4042:4042depends_on为 cockroachservice_started、minioservice_healthy、accountservice_startedfront新增BILLING_URLhttp://huly.local:4042。结果验证端口与依赖overlay 声明payment监听 3040、billing监听 4042billing 对 minio 要求service_healthyminio 未就绪时 billing 不会进入运行状态。客户端识别前端仅当BILLING_URL非空时才注册 billing 应用dev/prod/src/platform.ts 中的条件判断叠加 overlay 后客户端应能看到 billing 入口这是 overlay 注释中 so the client picks them up 所指的生效标志。订阅流程payment README 记载的请求路径与成功回跳客户端POST /api/v1/subscriptions/:workspace/subscribeBearer tokenbody 含typetier或support与plan成功响应返回checkoutId与checkoutUrl文档示例中为checkout_abc123/ Polar 的 checkout 链接仅作文档示例用户完成支付后被重定向到FRONT_URL/workbench/setting/setting/billing?paymentsuccesscheckout_id{CHECKOUT_ID}paymentsuccess查询参数即文档给出的成功标志。webhook 与管理端点Stripe 事件发送到/api/v1/webhooks/stripe管理侧可用GET /api/v1/subscriptions/:subscriptionIdadmin only查看订阅、POST /api/v1/subscriptions/:subscriptionId/cancel取消订阅。限制只有一个 provider 可以生效配置了POLAR_*时 Stripe 不会初始化两者不能同时使用。不设提供商凭据时服务以沙箱模式运行、不发起外呼此时订阅 checkout 无法真正创建两处文档对凭据是否必需的表述不一致如前所述完成 Stripe 沙箱订阅应配齐STRIPE_API_KEY、STRIPE_WEBHOOK_SECRET、STRIPE_SUBSCRIPTION_PLANS。STRIPE_SUBSCRIPTION_PLANS中的 Price ID 必须与你在 Stripe 账户中实际创建的 Price 一致README 未提供可用的公共测试值。【免费下载链接】platformHuly — All-in-One Project Management Platform (alternative to Linear, Jira, Slack, Notion, Motion)项目地址: https://gitcode.com/GitHub_Trending/platform80/platform创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
