agents24 payment-integration 子代理深解Stripe、PayPal、Webhook 与 PCI 合规的支付集成实践【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents在 agents24 这个多 Harness 代理插件市场中payment-integration 是payment-processing插件提供的支付集成专家子代理用于在实现支付、计费或订阅功能时主动接管任务。本文围绕该子代理的定义文件展开结合同插件下 stripe-integration、paypal-integration、billing-automation 与 pci-compliance 四个技能包完整讲解它的职责边界、五步工作法、Webhook 安全与幂等要求、PCI 合规要点以及配套的可运行代码模式。读完后你将掌握一套先验证、再幂等、后异步的支付集成方法论并能把其中大部分约束直接落到自己的代码里。子代理定位Frontmatter 决定了它如何被调用payment-integration以 Markdown YAML frontmatter 的形式定义位于 agents 目录。其元数据如下字段取值作用namepayment-integration代理标识名descriptionIntegrate Stripe, PayPal, and payment processors. Handles checkout flows, subscriptions, webhooks, and PCI compliance. Use PROACTIVELY when implementing payments, billing, or subscription features.描述触发条件Use PROACTIVELY意味着只要任务涉及支付/计费/订阅宿主代理应主动委派给它modelsonnet指定该子代理运行使用的模型档位从 description 的措辞可以看出它的职责面Stripe/PayPal 等支付网关 API 集成、结账流程与支付表单、订阅与循环扣款、支付事件的 Webhook 处理、PCI 合规与安全最佳实践、支付错误处理与重试逻辑——这些内容在文件的 Focus Areas 一节中逐条列出是理解该子代理能力边界的基准。五步工作方法论Approach 一节拆解定义文件将工作方式固化为五条有序原则这也是它区别于普通写支付代码的代理的关键Security first —— 绝不记录敏感卡数据任何日志、异常信息中不得出现原始 PAN/CVV为所有支付操作实现幂等性idempotency无论是创建 PaymentIntent 还是捕获订单重复提交不得产生重复扣款处理所有边界情况支付失败、争议dispute、退款都要有明确的处理路径先测试模式再生产使用sk_test_/ sandbox 凭据开发并保证有清晰的迁移路径用全面的 Webhook 处理应对异步事件支付结果大多最终由 Webhook 决定而非同步响应。关键要求一Webhook 安全与幂等Critical Requirements定义文件的 Webhook Security Idempotency 小节给出了五条硬性约束每一条都对应一类真实生产事故签名验证Signature Verification必须使用官方 SDK 校验 Webhook 签名Stripe、PayPal 都带 HMAC 签名机制绝不处理未验证的 Webhook原始请求体保留Raw Body Preservation验证前不得修改请求体——任何会把 body 解析成 JSON 对象的中间件都会破坏签名校验这是 Webhook 集成中最常见的坑幂等处理器Idempotent Handlers将事件 ID 存入数据库并在处理前检查。Webhook 在失败时会重试支付方不保证单次投递快速响应Quick Response在 200ms 内、在任何昂贵操作数据库写入、外部 API 调用之前返回2xx。超时会触发重试进而导致重复处理服务端复核Server Validation不要只信任 Webhook 载荷或客户端响应要通过 Provider API 重新拉取支付状态。这套约束在同插件的 Stripe 技能文档中有对应的参考实现。stripe-integration 的参考文档 给出了一段标准的 Flask Webhook 端点签名验证与事件分发逻辑如下from flask import Flask, request import stripe app Flask(__name__) endpoint_secret whsec_... app.route(/webhook, methods[POST]) def webhook(): payload request.data # 原始 body不做 JSON 解析 sig_header request.headers.get(Stripe-Signature) try: event stripe.Webhook.construct_event( payload, sig_header, endpoint_secret ) except ValueError: return Invalid payload, 400 except stripe.error.SignatureVerificationError: return Invalid signature, 400 if event[type] payment_intent.succeeded: handle_successful_payment(event[data][object]) elif event[type] payment_intent.payment_failed: handle_failed_payment(event[data][object]) elif event[type] customer.subscription.deleted: handle_subscription_canceled(event[data][object]) return Success, 200注意payload request.data这一行它直接取原始字节体正是Raw Body Preservation原则的代码体现。同文件还补充了一个幂等处理骨架与定义文件中存储事件 ID、处理前检查的要求一一对应def handle_webhook_idempotently(event_id, handler): Ensure webhook is processed exactly once. if is_event_processed(event_id): return try: handler() mark_event_processed(event_id) except Exception as e: log_error(e) # Stripe will retry failed webhooks raise对于 Stripe 集成还需要知道哪些事件必须监听。stripe-integration 技能 列出的关键事件包括payment_intent.succeeded支付完成、payment_intent.payment_failed支付失败、customer.subscription.updated/customer.subscription.deleted订阅变更/取消、charge.refunded退款、invoice.payment_succeeded订阅扣款成功。PayPal 侧对应的异步机制是 IPNInstant Payment Notification。paypal-integration 的参考文档 展示了回传 PayPal 服务器换取VERIFIED应答的验证方式并在处理前用is_transaction_processed(txn_id)去重——同样满足子代理定义中签名验证 幂等两条要求def verify_ipn(ipn_data): Verify IPN message authenticity. verify_data ipn_data.copy() verify_data[cmd] _notify-validate paypal_url https://ipnpb.sandbox.paypal.com/cgi-bin/webscr # or production URL response requests.post(paypal_url, dataverify_data) return response.text VERIFIED关键要求二PCI 合规三原则定义文件 PCI Compliance Essentials 小节给出三条底线绝不触碰原始卡号Never Handle Raw Cards使用 Stripe Elements、PayPal SDK 等 tokenization API让卡数据始终留在 Provider 的 iframe 中完成采集绝不存储、处理或传输原始卡号服务端验证Server-Side Validation所有支付核验必须通过服务端直接调用支付 Provider API 完成不能只信前端回传环境隔离Environment Separation测试凭据必须在生产环境失效——配置错误的网关常常会在生产站点上接受测试卡这本身就构成 PCI 违规。配套的 pci-compliance 技能 把这些原则扩展成了完整的 PCI DSS 12 条核心要求防火墙配置、保护持卡人数据、漏洞管理、访问控制、监控与测试、信息安全策略与四级合规级别Level 1 年交易 600 万笔需年度 ROCLevel 4 为最低级别。在数据最小化层面该技能用一个显式的数据分级表划清了存储红线# NEVER STORE THESE PROHIBITED_DATA { full_track_data: Magnetic stripe data, cvv: Card verification code/value, pin: PIN or PIN block } # CAN STORE (if encrypted) ALLOWED_DATA { pan: Primary Account Number (card number), cardholder_name: Name on card, expiration_date: Card expiration, service_code: Service code }并给出一个PaymentData类负责在日志中脱敏PAN 只保留前 6 位与后 4 位、剔除 CVV/PIN 字段以及在持久化前拦截违禁字段。pci-compliance 参考文档 进一步补充了require_pci_access访问控制装饰器按角色限制持卡人数据接口 审计日志、PCIAuditLogger审计日志类以及 SAQ A / A-EP / D 三种自评问卷的适用范围使用托管支付页的电商落在要求最少的 SAQ A嵌入支付表单的电商落在 SAQ A-EP而自行存储/处理/传输卡数据的系统则面对最重的 SAQ D——这解释了为什么子代理坚持tokenization 优先它是缩小合规范围最直接的架构手段。常见失败案例从定义文件的事故清单看定义文件 Common Failures 一节列举了来自 Stripe、PayPal 与 OWASP 资料的生产事故模式支付处理方在流量高峰时崩溃 → Webhook 队列积压、收入损失对应快速响应 队列化异步处理乱序 Webhook 击穿无幂等保护的 Lambda 函数 → 生产故障对应事件 ID 去重未加密的支付按钮遭恶意篡改价格 → 欺诈交易对应服务端验证不信客户端载荷配置错误导致测试卡被生产站点接受 → PCI 违规对应环境隔离跳过 Webhook 签名验证 → 系统被伪造请求灌入对应ALWAYS verify signatures。这份清单与前面两条 Critical Requirements 是逐条映射的可以把它当作上线前的自查表使用。配套技能深潜从 Checkout 到 Dunning 的可复制模式子代理定义文件声明它的交付物包含支付集成代码、Webhook 端点、支付记录数据库 Schema、安全清单、测试场景与环境变量配置而具体模式则由同插件的四个技能承接。下面选取与子代理先测试模式、幂等、覆盖边界原则直接相关的几个核心模式。1. Stripe Checkout Session推荐的主路径stripe-integration 技能 指出 Checkout Session 是大多数集成的首选支持托管结账页、嵌入式表单以及ui_modecustom的自定义 UI比 PaymentIntent 的集成与维护负担更低。创建订阅型 Checkout Session 的最小示例import stripe stripe.api_key sk_test_... session stripe.checkout.Session.create( line_items[{ price_data: { currency: usd, product_data: {name: Premium Subscription}, unit_amount: 2000, # $20.00 recurring: {interval: month}, }, quantity: 1, }], modesubscription, success_urlhttps://yourdomain.com/success?session_id{CHECKOUT_SESSION_ID}, cancel_urlhttps://yourdomain.com/cancel ) # 将用户重定向到 session.url其参考文档还补充了四个高频模式一次性支付托管 Checkout、Elements Checkout Session返回client_secret给前端、Elements PaymentIntentautomatic_payment_methods自动选择支付方式、订阅创建payment_behaviordefault_incomplete 展开latest_invoice.payment_intent拿 client_secret、以及客户门户stripe.billing_portal.Session.create用于让用户自助管理订阅。退款与争议处理则通过stripe.Refund.create支持amount部分退款与reason标注和stripe.Dispute.modify提交customer_name、shipping_documentation等举证材料完成——这些正是子代理 Focus Areas 中Payment error handling and retry logic要求的落点。测试阶段该技能给出一组 Stripe 官方测试卡覆盖不同分支TEST_CARDS { success: 4242424242424242, declined: 4000000000000002, 3d_secure: 4000002500003155, insufficient_funds: 4000000000009995 }配合sk_test_密钥即可端到端验证成功/拒付/3DS/余额不足四条路径对应定义文件Test mode first的要求。2. PayPalExpress Checkout 服务端捕获paypal-integration 技能 区分了两条集成路线客户端 JavaScript SDKSmart Payment Buttons后端代码最少与服务端 REST API完全控制流程。其参考文档中的PayPalClient封装了 OAuth 取 tokengrant_typeclient_credentials、create_orderPOST /v2/checkout/ordersintent: CAPTURE、capture_orderPOST /v2/checkout/orders/{id}/capture三个核心调用并以 sandbox/live 双 base URL 实现环境切换——这正是环境隔离原则在 PayPal 侧的具体体现self.base_url (https://api-m.sandbox.paypal.com if mode sandbox else https://api-m.paypal.com)前端在onApprove回调中只把orderID发回自己的后端由服务端完成 capture 与核验——同样体现了Server-Side Validation。该技能还覆盖了订阅计划/v1/billing/plans含auto_bill_outstanding、payment_failure_threshold等扣款偏好与退款工作流POST /v2/payments/captures/{id}/refund支持部分退款金额与买家备注。3. Billing Automation订阅生命周期与 Dunningbilling-automation 技能 把订阅状态固化为状态机trial → active → past_due → canceled → paused → resumed其参考文档 实现了完整的生命周期Subscription类的start_trial/activate/mark_past_due/cancel转移BillingEngine.process_billing_cycle在账期到期时生成发票、扣款成功则推进账期并寄送发票失败则转入 dunningDunningManager使用三段重试日程第 3 天payment_failed_first、第 7 天payment_failed_reminder、第 14 天payment_failed_final重试成功恢复订阅重试耗尽则取消并通知此外还有ProrationCalculator按天折算新旧计划差额与席位增减和TaxCalculator按辖区计算 Sales Tax/VAT/GST如US_CA: 7.25%、GB: 20%。这套代码是子代理Handle all edge cases (failed payments, disputes, refunds)要求在循环扣款场景下的完整展开。4. 测试与沙箱PayPal 端到端验证脚本paypal-integration 技能 给出了沙箱端到端测试骨架用 sandbox 凭据构造客户端 →create_order并断言返回id→ 从links中取出rel approve的授权 URL用测试买家账号手工授权→ capture 并断言status COMPLETED。注意注释明确说明授权是测试账号的手工步骤——这提醒读者自动化的边界在哪里。交付物契约与使用建议定义文件末尾的 Output 一节是该子代理的交付物契约带错误处理的支付集成代码Webhook 端点实现支付记录数据库 Schema安全清单PCI 合规检查点测试支付场景与边界用例环境变量配置。并附一条总约束Always use official SDKs. Include both server-side and client-side code where needed.——即优先官方 SDK且凡涉及卡数据采集的场景必须同时给出前后端代码。在 agents24 仓库中这套能力以插件形式组织payment-processing插件包含一个 agent本文主角与四个 skillsstripe-integration、paypal-integration、billing-automation、pci-compliance每个技能均为导航层 SKILL.md references/details.md 详细模式库的两层结构前者给出概念与 Quick Start后者存放可直接参考的模式代码。如果你的任务涉及实现支付、订阅或 Webhook 处理这个 agent skills 组合提供了一条从签名验签到 dunning 重试的完整参考链路若需要落地到自己的项目建议按子代理的五步方法自检签名验证是否用官方 SDK、请求体是否保持原始字节、事件处理是否幂等、响应是否在 200ms 内返回、以及支付状态是否在服务端通过 Provider API 复核。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 agents24 payment-integration 子代理深解：Stripe、PayPal、Webhook 与 PCI 合规的支付集成实践
agents24 payment-integration 子代理深解Stripe、PayPal、Webhook 与 PCI 合规的支付集成实践【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents在 agents24 这个多 Harness 代理插件市场中payment-integration 是payment-processing插件提供的支付集成专家子代理用于在实现支付、计费或订阅功能时主动接管任务。本文围绕该子代理的定义文件展开结合同插件下 stripe-integration、paypal-integration、billing-automation 与 pci-compliance 四个技能包完整讲解它的职责边界、五步工作法、Webhook 安全与幂等要求、PCI 合规要点以及配套的可运行代码模式。读完后你将掌握一套先验证、再幂等、后异步的支付集成方法论并能把其中大部分约束直接落到自己的代码里。子代理定位Frontmatter 决定了它如何被调用payment-integration以 Markdown YAML frontmatter 的形式定义位于 agents 目录。其元数据如下字段取值作用namepayment-integration代理标识名descriptionIntegrate Stripe, PayPal, and payment processors. Handles checkout flows, subscriptions, webhooks, and PCI compliance. Use PROACTIVELY when implementing payments, billing, or subscription features.描述触发条件Use PROACTIVELY意味着只要任务涉及支付/计费/订阅宿主代理应主动委派给它modelsonnet指定该子代理运行使用的模型档位从 description 的措辞可以看出它的职责面Stripe/PayPal 等支付网关 API 集成、结账流程与支付表单、订阅与循环扣款、支付事件的 Webhook 处理、PCI 合规与安全最佳实践、支付错误处理与重试逻辑——这些内容在文件的 Focus Areas 一节中逐条列出是理解该子代理能力边界的基准。五步工作方法论Approach 一节拆解定义文件将工作方式固化为五条有序原则这也是它区别于普通写支付代码的代理的关键Security first —— 绝不记录敏感卡数据任何日志、异常信息中不得出现原始 PAN/CVV为所有支付操作实现幂等性idempotency无论是创建 PaymentIntent 还是捕获订单重复提交不得产生重复扣款处理所有边界情况支付失败、争议dispute、退款都要有明确的处理路径先测试模式再生产使用sk_test_/ sandbox 凭据开发并保证有清晰的迁移路径用全面的 Webhook 处理应对异步事件支付结果大多最终由 Webhook 决定而非同步响应。关键要求一Webhook 安全与幂等Critical Requirements定义文件的 Webhook Security Idempotency 小节给出了五条硬性约束每一条都对应一类真实生产事故签名验证Signature Verification必须使用官方 SDK 校验 Webhook 签名Stripe、PayPal 都带 HMAC 签名机制绝不处理未验证的 Webhook原始请求体保留Raw Body Preservation验证前不得修改请求体——任何会把 body 解析成 JSON 对象的中间件都会破坏签名校验这是 Webhook 集成中最常见的坑幂等处理器Idempotent Handlers将事件 ID 存入数据库并在处理前检查。Webhook 在失败时会重试支付方不保证单次投递快速响应Quick Response在 200ms 内、在任何昂贵操作数据库写入、外部 API 调用之前返回2xx。超时会触发重试进而导致重复处理服务端复核Server Validation不要只信任 Webhook 载荷或客户端响应要通过 Provider API 重新拉取支付状态。这套约束在同插件的 Stripe 技能文档中有对应的参考实现。stripe-integration 的参考文档 给出了一段标准的 Flask Webhook 端点签名验证与事件分发逻辑如下from flask import Flask, request import stripe app Flask(__name__) endpoint_secret whsec_... app.route(/webhook, methods[POST]) def webhook(): payload request.data # 原始 body不做 JSON 解析 sig_header request.headers.get(Stripe-Signature) try: event stripe.Webhook.construct_event( payload, sig_header, endpoint_secret ) except ValueError: return Invalid payload, 400 except stripe.error.SignatureVerificationError: return Invalid signature, 400 if event[type] payment_intent.succeeded: handle_successful_payment(event[data][object]) elif event[type] payment_intent.payment_failed: handle_failed_payment(event[data][object]) elif event[type] customer.subscription.deleted: handle_subscription_canceled(event[data][object]) return Success, 200注意payload request.data这一行它直接取原始字节体正是Raw Body Preservation原则的代码体现。同文件还补充了一个幂等处理骨架与定义文件中存储事件 ID、处理前检查的要求一一对应def handle_webhook_idempotently(event_id, handler): Ensure webhook is processed exactly once. if is_event_processed(event_id): return try: handler() mark_event_processed(event_id) except Exception as e: log_error(e) # Stripe will retry failed webhooks raise对于 Stripe 集成还需要知道哪些事件必须监听。stripe-integration 技能 列出的关键事件包括payment_intent.succeeded支付完成、payment_intent.payment_failed支付失败、customer.subscription.updated/customer.subscription.deleted订阅变更/取消、charge.refunded退款、invoice.payment_succeeded订阅扣款成功。PayPal 侧对应的异步机制是 IPNInstant Payment Notification。paypal-integration 的参考文档 展示了回传 PayPal 服务器换取VERIFIED应答的验证方式并在处理前用is_transaction_processed(txn_id)去重——同样满足子代理定义中签名验证 幂等两条要求def verify_ipn(ipn_data): Verify IPN message authenticity. verify_data ipn_data.copy() verify_data[cmd] _notify-validate paypal_url https://ipnpb.sandbox.paypal.com/cgi-bin/webscr # or production URL response requests.post(paypal_url, dataverify_data) return response.text VERIFIED关键要求二PCI 合规三原则定义文件 PCI Compliance Essentials 小节给出三条底线绝不触碰原始卡号Never Handle Raw Cards使用 Stripe Elements、PayPal SDK 等 tokenization API让卡数据始终留在 Provider 的 iframe 中完成采集绝不存储、处理或传输原始卡号服务端验证Server-Side Validation所有支付核验必须通过服务端直接调用支付 Provider API 完成不能只信前端回传环境隔离Environment Separation测试凭据必须在生产环境失效——配置错误的网关常常会在生产站点上接受测试卡这本身就构成 PCI 违规。配套的 pci-compliance 技能 把这些原则扩展成了完整的 PCI DSS 12 条核心要求防火墙配置、保护持卡人数据、漏洞管理、访问控制、监控与测试、信息安全策略与四级合规级别Level 1 年交易 600 万笔需年度 ROCLevel 4 为最低级别。在数据最小化层面该技能用一个显式的数据分级表划清了存储红线# NEVER STORE THESE PROHIBITED_DATA { full_track_data: Magnetic stripe data, cvv: Card verification code/value, pin: PIN or PIN block } # CAN STORE (if encrypted) ALLOWED_DATA { pan: Primary Account Number (card number), cardholder_name: Name on card, expiration_date: Card expiration, service_code: Service code }并给出一个PaymentData类负责在日志中脱敏PAN 只保留前 6 位与后 4 位、剔除 CVV/PIN 字段以及在持久化前拦截违禁字段。pci-compliance 参考文档 进一步补充了require_pci_access访问控制装饰器按角色限制持卡人数据接口 审计日志、PCIAuditLogger审计日志类以及 SAQ A / A-EP / D 三种自评问卷的适用范围使用托管支付页的电商落在要求最少的 SAQ A嵌入支付表单的电商落在 SAQ A-EP而自行存储/处理/传输卡数据的系统则面对最重的 SAQ D——这解释了为什么子代理坚持tokenization 优先它是缩小合规范围最直接的架构手段。常见失败案例从定义文件的事故清单看定义文件 Common Failures 一节列举了来自 Stripe、PayPal 与 OWASP 资料的生产事故模式支付处理方在流量高峰时崩溃 → Webhook 队列积压、收入损失对应快速响应 队列化异步处理乱序 Webhook 击穿无幂等保护的 Lambda 函数 → 生产故障对应事件 ID 去重未加密的支付按钮遭恶意篡改价格 → 欺诈交易对应服务端验证不信客户端载荷配置错误导致测试卡被生产站点接受 → PCI 违规对应环境隔离跳过 Webhook 签名验证 → 系统被伪造请求灌入对应ALWAYS verify signatures。这份清单与前面两条 Critical Requirements 是逐条映射的可以把它当作上线前的自查表使用。配套技能深潜从 Checkout 到 Dunning 的可复制模式子代理定义文件声明它的交付物包含支付集成代码、Webhook 端点、支付记录数据库 Schema、安全清单、测试场景与环境变量配置而具体模式则由同插件的四个技能承接。下面选取与子代理先测试模式、幂等、覆盖边界原则直接相关的几个核心模式。1. Stripe Checkout Session推荐的主路径stripe-integration 技能 指出 Checkout Session 是大多数集成的首选支持托管结账页、嵌入式表单以及ui_modecustom的自定义 UI比 PaymentIntent 的集成与维护负担更低。创建订阅型 Checkout Session 的最小示例import stripe stripe.api_key sk_test_... session stripe.checkout.Session.create( line_items[{ price_data: { currency: usd, product_data: {name: Premium Subscription}, unit_amount: 2000, # $20.00 recurring: {interval: month}, }, quantity: 1, }], modesubscription, success_urlhttps://yourdomain.com/success?session_id{CHECKOUT_SESSION_ID}, cancel_urlhttps://yourdomain.com/cancel ) # 将用户重定向到 session.url其参考文档还补充了四个高频模式一次性支付托管 Checkout、Elements Checkout Session返回client_secret给前端、Elements PaymentIntentautomatic_payment_methods自动选择支付方式、订阅创建payment_behaviordefault_incomplete 展开latest_invoice.payment_intent拿 client_secret、以及客户门户stripe.billing_portal.Session.create用于让用户自助管理订阅。退款与争议处理则通过stripe.Refund.create支持amount部分退款与reason标注和stripe.Dispute.modify提交customer_name、shipping_documentation等举证材料完成——这些正是子代理 Focus Areas 中Payment error handling and retry logic要求的落点。测试阶段该技能给出一组 Stripe 官方测试卡覆盖不同分支TEST_CARDS { success: 4242424242424242, declined: 4000000000000002, 3d_secure: 4000002500003155, insufficient_funds: 4000000000009995 }配合sk_test_密钥即可端到端验证成功/拒付/3DS/余额不足四条路径对应定义文件Test mode first的要求。2. PayPalExpress Checkout 服务端捕获paypal-integration 技能 区分了两条集成路线客户端 JavaScript SDKSmart Payment Buttons后端代码最少与服务端 REST API完全控制流程。其参考文档中的PayPalClient封装了 OAuth 取 tokengrant_typeclient_credentials、create_orderPOST /v2/checkout/ordersintent: CAPTURE、capture_orderPOST /v2/checkout/orders/{id}/capture三个核心调用并以 sandbox/live 双 base URL 实现环境切换——这正是环境隔离原则在 PayPal 侧的具体体现self.base_url (https://api-m.sandbox.paypal.com if mode sandbox else https://api-m.paypal.com)前端在onApprove回调中只把orderID发回自己的后端由服务端完成 capture 与核验——同样体现了Server-Side Validation。该技能还覆盖了订阅计划/v1/billing/plans含auto_bill_outstanding、payment_failure_threshold等扣款偏好与退款工作流POST /v2/payments/captures/{id}/refund支持部分退款金额与买家备注。3. Billing Automation订阅生命周期与 Dunningbilling-automation 技能 把订阅状态固化为状态机trial → active → past_due → canceled → paused → resumed其参考文档 实现了完整的生命周期Subscription类的start_trial/activate/mark_past_due/cancel转移BillingEngine.process_billing_cycle在账期到期时生成发票、扣款成功则推进账期并寄送发票失败则转入 dunningDunningManager使用三段重试日程第 3 天payment_failed_first、第 7 天payment_failed_reminder、第 14 天payment_failed_final重试成功恢复订阅重试耗尽则取消并通知此外还有ProrationCalculator按天折算新旧计划差额与席位增减和TaxCalculator按辖区计算 Sales Tax/VAT/GST如US_CA: 7.25%、GB: 20%。这套代码是子代理Handle all edge cases (failed payments, disputes, refunds)要求在循环扣款场景下的完整展开。4. 测试与沙箱PayPal 端到端验证脚本paypal-integration 技能 给出了沙箱端到端测试骨架用 sandbox 凭据构造客户端 →create_order并断言返回id→ 从links中取出rel approve的授权 URL用测试买家账号手工授权→ capture 并断言status COMPLETED。注意注释明确说明授权是测试账号的手工步骤——这提醒读者自动化的边界在哪里。交付物契约与使用建议定义文件末尾的 Output 一节是该子代理的交付物契约带错误处理的支付集成代码Webhook 端点实现支付记录数据库 Schema安全清单PCI 合规检查点测试支付场景与边界用例环境变量配置。并附一条总约束Always use official SDKs. Include both server-side and client-side code where needed.——即优先官方 SDK且凡涉及卡数据采集的场景必须同时给出前后端代码。在 agents24 仓库中这套能力以插件形式组织payment-processing插件包含一个 agent本文主角与四个 skillsstripe-integration、paypal-integration、billing-automation、pci-compliance每个技能均为导航层 SKILL.md references/details.md 详细模式库的两层结构前者给出概念与 Quick Start后者存放可直接参考的模式代码。如果你的任务涉及实现支付、订阅或 Webhook 处理这个 agent skills 组合提供了一条从签名验签到 dunning 重试的完整参考链路若需要落地到自己的项目建议按子代理的五步方法自检签名验证是否用官方 SDK、请求体是否保持原始字节、事件处理是否幂等、响应是否在 200ms 内返回、以及支付状态是否在服务端通过 Provider API 复核。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考