【免费下载链接】hyperswitch-prismOne library | Many payment processors | Scale to multiple processors with few lines of code.项目地址https://gitcode.com/gh_mirrors/hy/hyperswitch-prism点击查看免费下载支付不是一次请求—返回那么简单卡片先被冻结Authorize资金在发货后才真正划走Capture/Settlement退款可能一周后才发生3DS 验证还会把交易挂起在等待用户确认的中间态。本文带你用 5 个关键环节看懂 hyperswitch-prism 的支付生命周期——它把 Stripe、Adyen、PayPal 等 50 支付处理器的差异收敛成一台清晰的状态机让授权、捕获、结算、退款、回调每一步都有明确的边界。先搞清楚Authorize 和 Settlement 到底差在哪很多新手把支付当成一个动作但在真实的资金世界里一笔支付是一条时间线Authorize授权只是冻结这笔钱用户卡上会多出一笔 pending 交易Capture捕获真正把冻结的钱划走这一步之后才算收到了钱Settlement结算银行/卡组织之间的清算落账通常由处理器侧异步完成通过 Webhook 通知你最终结果。⚠️ 常见坑在 Authorize 成功的瞬间就发货万一冻结后来被拒绝或过期你就白发了货。hyperswitch-prism 把这条时间线拆成 5 个关键环节每个环节对应独立的 API 方法而不是一个可随意改写的status字段。关键环节干什么Prism 中的方法/客户端① 认证与风控3DS / SCA 验证持卡人身份MerchantAuthenticationClient、authType② Authorize 授权冻结资金不真正扣款PaymentClient.authorize()③ Capture 捕获与 Settlement划走资金、等待结算落账capture()、get()、Webhook④ Refund 与 Void退钱或释放未捕获的冻结refund()、void()、reverse()⑤ 异步 Webhook结算/退款等事件的统一入口EventClient.handleEvent()官方对状态机和服务划分的完整描述见 docs/blogs/authorization-to-settlement.md 与 docs/architecture/concepts/services-and-methods.md。环节一认证与风控——AUTHENTICATION_PENDING 状态第一环发生在扣钱之前验证这个持卡人本人是否真的在付款。常见形式有 3D Secure3DS和欧洲的 SCA 强客户认证。在 Prism 的生命周期状态机里支付一开始是STARTED如果需要风控挑战会进入AUTHENTICATION_PENDING——整个交易被挂起等待用户在一个你的服务器看不见的浏览器窗口里完成验证。STARTED → AUTHENTICATION_PENDING → AUTHORIZED → CHARGED → (refund 子流程) │ │ │ (3DS / SCA) (钱被冻结) (钱被划走)Prism 的 API 直接映射这台状态机生命周期被拆成一个个动词方法分布在不同的客户端里你能调用的方法就是这笔支付实际允许的状态迁移而不是update({ status: ... })这种可以写错的方式。图钱包支付中用户在设备端授权 → 令牌交给处理器 → Authorize的完整链路认证环节对商户服务器完全透明。环节二Authorize 授权——冻结资金的核心一步authorize()是生命周期的主入口。无论底层是 Stripe 还是 Adyen你都用同一个请求结构发起授权核心字段只有几个字段含义merchantTransactionId你自己系统里的交易号幂等键amount{ minorAmount, currency }金额 币种captureMethodAUTOMATIC授权即扣款或MANUAL稍后捕获authType是否触发 3DS 风控paymentMethod卡片、钱包 token 等支付方式两个容易忽略的细节金额是按币种缩放的整数minorAmount: 1000在 USD 里是 $10.00在 JPY 里是 ¥1000。Prism 统一用最小货币单位minor unit自动转换成各处理器的原生格式从根上消灭100 倍偏差和浮点误差。详见 docs/architecture/frameworks/money-struct.md。captureMethod决定业务语义SaaS/数字商品用AUTOMATIC立即扣款电商常用MANUAL等仓库确认发货再捕获。授权成功拿到connectorTransactionId——它是后续所有环节捕获、退款、撤销的唯一钥匙。环节三Capture 捕获——从 AUTHORIZED 到 CHARGED捕获是真正收到钱的时刻对应状态从AUTHORIZED迁移到CHARGED。Prism 里capture是独立方法而不是改一个状态字段——你没法对一个从未授权的支付手滑触发捕获。这一环有几个实用玩法完整示例见 docs/getting-started/extend-to-more-flows.md部分捕获Partial Capture授权 $100第一批发货捕获 $40第二批再捕获 $60增量授权Incremental Authorization酒店入住先冻 $100客人加了客房服务后把冻结提到 $150退房时按实际金额捕获Settlement 落账捕获后资金在银行侧完成清算最终结果往往通过 WebhookPAYMENT_INTENT_CAPTURE_SUCCESS之类的事件异步确认。所以查状态时如果还没有结果Prism 会返回PENDING而不是报错——未知意味着过一会儿再查而不是这单失败了。✅ 最佳实践发货/交付只认 Capture不认 Authorize。这是大多数支付事故的根源。各方法的完整参数与返回见 API 参考authorize、capture。环节四Refund 与 Void——两种把钱还回去资金已经动了和没动处理方式完全不同Prism 为此设计了不同方法操作场景方法Void 撤销发货前取消订单释放冻结资金void()Refund 退款已捕获后退货支持部分退款refund()Reverse 冲正没有原始订单号凭交易 ID 直接冲正reverse()退款是一条独立的子状态机它有自己的一套状态如REFUND_SUCCESS、pending、失败而不是复用支付状态。把三种事件授权成功、捕获成功、退款成功硬塞进同一个status字段正是很多支付代码看起来对、行为错的根源。退款与争议处理的 API 见 refund、void。环节五Webhook——异步真相的统一入口Settlement、退款、争议……这些事件不会等你去轮询而是乱序、可能重复地通过 Webhook 涌进来。EventClient.handleEvent()是所有异步事件的统一入口它做两件关键的事验签检查 webhook 来源HMAC 等验不过的事件直接当作伪造拒绝——没有开发模式跳过验证的后门归一化把各处理器的原始事件映射成统一的WebhookEventType枚举如PAYMENT_INTENT_SUCCESS、PAYMENT_INTENT_CAPTURE_SUCCESS你的业务代码只写一次判断逻辑。同一客户端家族里DisputeClient负责争议chargeback的accept/defend/submitEvidencedocs/getting-started/extend-to-more-flows.md 中有完整用法。收尾把支付当生命周期你会少踩这些坑习惯原因不要只按一个status分支授权成功 ≠ 捕获成功 ≠ 退款成功是不同的流发货只认 Capture授权只是冻结随时可能失败或过期同步查询视为暂定答案未知默认 PENDING让已验证的 Webhook 事件来定案金额用带币种的整数minorAmount currency永远不要传浮点数换处理器只换一行配置请求结构不变路由逻辑留在你自己的业务层想完整跑一遍授权→捕获→退款可以直接看 docs/getting-started/first-payment.md 或 demo/e-commerce/ 里 Stripe Adyen 的示例工程想按语言接入参考 sdk/python/README.md 与 sdk/javascript/README.md。赞分享【免费下载链接】hyperswitch-prismOne library | Many payment processors | Scale to multiple processors with few lines of code.项目地址https://gitcode.com/gh_mirrors/hy/hyperswitch-prism点击查看免费下载相关推荐CANN/runtime如何通过plog日志定位Device侧异常如何通过plog日志定位Device侧异常 问题现象描述 现象1算子执行失败但无法定位错误原因和位置 Runtime应用在Device侧执行任务时发生异常HCANNAscend人工智能性能剖析系统编程Livewire生命周期钩子掌握组件生命周期的关键Livewire生命周期钩子掌握组件生命周期的关键 Livewire生命周期钩子是Laravel Livewire框架中至关重要的功能它允许开发者在组件生命后端前端BullMQ任务生命周期详解从等待到完成的7个关键状态BullMQ任务生命周期详解从等待到完成的7个关键状态 BullMQ作为基于Redis的Node.js和Python消息队列系统其任务处理的生命周期是理解和后端消息队列任务调度创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考