服务 03 / Stripe 支付
能收钱只是开始，
对得上账才算完
收款链路最容易出问题的不是接 Checkout，
是 webhook 重复触发导致重复发货、网络抖动导致丢单、
月底对账发现金额和订单对不上。
适合谁
- ·站已经上线,但收款链路没验证过极端情况
- ·Stripe 后台显示已付款,数据库里订单还是待支付
- ·客户投诉收到了两份交付物,或者付了钱没收到东西
- ·要接订阅计费,不知道 proration、试用期、取消怎么处理
你可能是这么想的
「有人付了钱但没收到东西」
「同一个订单发了两封交付邮件」
「订阅用户取消后还在扣费」
「月底对账,Stripe 流水和系统订单对不上,查不出差在哪」
交付什么
不做什么
写清楚边界，比写清楚能力更省双方时间。
不做支付牌照相关业务
只做技术集成。资金清算、分账、跨境合规这些需要持牌机构,我的角色是把接口接对。
不接管你的 Stripe 账户
密钥由你自己保管,我给你操作步骤或者用测试模式演示。需要我直接操作时你开临时权限,做完就撤。
不承诺零故障
Stripe 侧也可能出问题。能做的是让本地逻辑在收到重复、延迟、乱序的事件时不产生错误数据。
不接非 Stripe 的支付渠道
微信支付、支付宝的接入逻辑不同,不在这个服务范围内。
周期与价格
固定报价，不按小时计费。¥15,000 以下 50% 预付 + 50% 验收后；以上分三期。第三方费用（服务器、API、域名）不包含在内。
凭什么信
幂等的三种写法与四个坑
手记里写了为什么用事件 ID 去重、为什么状态机比 if 判断可靠、以及我在真实项目里踩过的四个具体错误。
本站商城是真实在跑的
两件数字商品用 Stripe 收款,付款后自动交付下载链接。不是演示环境,是生产环境。
交付链路可验证
付款页、成功页、交付邮件、退款路径都能现场走一遍。你看得见真实流程,不是流程图。
常见问题
webhook 幂等到底是什么意思?
同一个事件 Stripe 可能发多次(重试、网络抖动),处理逻辑必须保证「处理一次」和「处理五次」结果相同。常见做法是用事件 ID 做唯一键落库,已存在就跳过。
支付成功但 webhook 没收到怎么办?
要有兜底:用户回到成功页时主动查一次 Stripe 会话状态并回写,不能只依赖 webhook。两条路都走,单点失效不会导致订单卡住。
订阅计费的 proration 怎么处理?
Stripe 会按剩余天数自动计算差价,但你的系统要能接收并展示这些事件。我会把 proration 事件接入提示逻辑,不让用户看到金额莫名其妙变化。
可以在测试环境先跑一遍吗?
必须。Stripe 有完整的测试卡号和测试时钟,我会在 test mode 下把所有失败场景跑一遍(卡被拒、3D Secure、退款、订阅取消),再切生产。
其他服务
价格公开，边界写明，做不了会说做不了。这比任何承诺都省时间。