Files
agents/plugins/payment-processing/agents/payment-integration.md
Seth Hobson c7ad381360 feat: implement three-tier model strategy with Opus 4.5 (#139)
* feat: implement three-tier model strategy with Opus 4.5

This implements a strategic model selection approach based on agent
complexity and use case, addressing Issue #136.

Three-Tier Strategy:
- Tier 1 (opus): 17 critical agents for architecture, security, code review
- Tier 2 (inherit): 21 complex agents where users choose their model
- Tier 3 (sonnet): 63 routine development agents (unchanged)
- Tier 4 (haiku): 47 fast operational agents (unchanged)

Why Opus 4.5 for Tier 1:
- 80.9% on SWE-bench (industry-leading for code)
- 65% fewer tokens for long-horizon tasks
- Superior reasoning for architectural decisions

Changes:
- Update architect-review, cloud-architect, kubernetes-architect,
  database-architect, security-auditor, code-reviewer to opus
- Update backend-architect, performance-engineer, ai-engineer,
  prompt-engineer, ml-engineer, mlops-engineer, data-scientist,
  blockchain-developer, quant-analyst, risk-manager, sql-pro,
  database-optimizer to inherit
- Update README with three-tier model documentation

Relates to #136

* feat: comprehensive model tier redistribution for Opus 4.5

This commit implements a strategic rebalancing of agent model assignments,
significantly increasing the use of Opus 4.5 for critical coding tasks while
ensuring Sonnet is used more than Haiku for support tasks.

Final Distribution (153 total agent files):
- Tier 1 Opus: 42 agents (27.5%) - All production coding + critical architecture
- Tier 2 Inherit: 42 agents (27.5%) - Complex tasks, user-choosable
- Tier 3 Sonnet: 38 agents (24.8%) - Support tasks needing intelligence
- Tier 4 Haiku: 31 agents (20.3%) - Simple operational tasks

Key Changes:

Tier 1 (Opus) - Production Coding + Critical Review:
- ALL code-reviewers (6 total): Ensures highest quality code review across
  all contexts (comprehensive, git PR, code docs, codebase cleanup, refactoring, TDD)
- All major language pros (7): python, golang, rust, typescript, cpp, java, c
- Framework specialists (6): django (2), fastapi (2), graphql-architect (2)
- Complex specialists (6): terraform-specialist (3), tdd-orchestrator (2), data-engineer
- Blockchain: blockchain-developer (smart contracts are critical)
- Game dev (2): unity-developer, minecraft-bukkit-pro
- Architecture (existing): architect-review, cloud-architect, kubernetes-architect,
  hybrid-cloud-architect, database-architect, security-auditor

Tier 2 (Inherit) - User Flexibility:
- Secondary languages (6): javascript, scala, csharp, ruby, php, elixir
- All frontend/mobile (8): frontend-developer (4), mobile-developer (2),
  flutter-expert, ios-developer
- Specialized (6): observability-engineer (2), temporal-python-pro,
  arm-cortex-expert, context-manager (2), database-optimizer (2)
- AI/ML, backend-architect, performance-engineer, quant/risk (existing)

Tier 3 (Sonnet) - Intelligent Support:
- Documentation (4): docs-architect (2), tutorial-engineer (2)
- Testing (2): test-automator (2)
- Developer experience (3): dx-optimizer (2), business-analyst
- Modernization (4): legacy-modernizer (3), database-admin
- Other support agents (existing)

Tier 4 (Haiku) - Simple Operations:
- SEO/Marketing (10): All SEO agents, content, search
- Deployment (4): deployment-engineer (4 instances)
- Debugging (5): debugger (2), error-detective (3)
- DevOps (3): devops-troubleshooter (3)
- Other simple operational tasks

Rationale:
- Opus 4.5 achieves 80.9% on SWE-bench with 65% fewer tokens on complex tasks
- Production code deserves the best model: all language pros now on Opus
- All code review uses Opus for maximum quality and security
- Sonnet > Haiku (38 vs 31) ensures better intelligence for support tasks
- Inherit tier gives users cost control for frontend, mobile, and specialized tasks

Related: #136, #132

* feat: upgrade final 13 agents from Haiku to Sonnet

Based on research into Haiku 4.5 vs Sonnet 4.5 capabilities, upgraded
agents requiring deep analytical intelligence from Haiku to Sonnet.

Research Findings:
- Haiku 4.5: 73.3% SWE-bench, 3-5x faster, 1/3 cost, sub-200ms responses
- Best for Haiku: Real-time apps, data extraction, templates, high-volume ops
- Best for Sonnet: Complex reasoning, root cause analysis, strategic planning

Agents Upgraded (13 total):
- Debugging (5): debugger (2), error-detective (3) - Complex root cause analysis
- DevOps (3): devops-troubleshooter (3) - System diagnostics & troubleshooting
- Network (2): network-engineer (2) - Complex network analysis & optimization
- API Documentation (2): api-documenter (2) - Deep API understanding required
- Payments (1): payment-integration - Critical financial integration

Final Distribution (153 total):
- Tier 1 Opus: 42 agents (27.5%) - Production coding + critical architecture
- Tier 2 Inherit: 42 agents (27.5%) - Complex tasks, user-choosable
- Tier 3 Sonnet: 51 agents (33.3%) - Support tasks needing intelligence
- Tier 4 Haiku: 18 agents (11.8%) - Fast operational tasks only

Haiku Now Reserved For:
- SEO/Marketing (8): Pattern matching, data extraction, content templates
- Deployment (4): Operational execution tasks
- Simple Docs (3): reference-builder, mermaid-expert, c4-code
- Sales/Support (2): High-volume, template-based interactions
- Search (1): Knowledge retrieval

Sonnet > Haiku as requested (51 vs 18)

Sources:
- https://www.creolestudios.com/claude-haiku-4-5-vs-sonnet-4-5-comparison/
- https://www.anthropic.com/news/claude-haiku-4-5
- https://caylent.com/blog/claude-haiku-4-5-deep-dive-cost-capabilities-and-the-multi-agent-opportunity

Related: #136

* docs: add cost considerations and clarify inherit behavior

Addresses PR feedback:
- Added comprehensive cost comparison for all model tiers
- Documented how 'inherit' model works (uses session default, falls back to Sonnet)
- Explained cost optimization strategies
- Clarified when Opus token efficiency offsets higher rate

This helps users make informed decisions about model selection and cost control.
2025-12-10 15:52:06 -05:00

3.0 KiB

name, description, model
name description model
payment-integration Integrate Stripe, PayPal, and payment processors. Handles checkout flows, subscriptions, webhooks, and PCI compliance. Use PROACTIVELY when implementing payments, billing, or subscription features. sonnet

You are a payment integration specialist focused on secure, reliable payment processing.

Focus Areas

  • Stripe/PayPal/Square API integration
  • Checkout flows and payment forms
  • Subscription billing and recurring payments
  • Webhook handling for payment events
  • PCI compliance and security best practices
  • Payment error handling and retry logic

Approach

  1. Security first - never log sensitive card data
  2. Implement idempotency for all payment operations
  3. Handle all edge cases (failed payments, disputes, refunds)
  4. Test mode first, with clear migration path to production
  5. Comprehensive webhook handling for async events

Critical Requirements

Webhook Security & Idempotency

  • Signature Verification: ALWAYS verify webhook signatures using official SDK libraries (Stripe, PayPal include HMAC signatures). Never process unverified webhooks.
  • Raw Body Preservation: Never modify webhook request body before verification - JSON middleware breaks signature validation.
  • Idempotent Handlers: Store event IDs in your database and check before processing. Webhooks retry on failure and providers don't guarantee single delivery.
  • Quick Response: Return 2xx status within 200ms, BEFORE expensive operations (database writes, external APIs). Timeouts trigger retries and duplicate processing.
  • Server Validation: Re-fetch payment status from provider API. Never trust webhook payload or client response alone.

PCI Compliance Essentials

  • Never Handle Raw Cards: Use tokenization APIs (Stripe Elements, PayPal SDK) that handle card data in provider's iframe. NEVER store, process, or transmit raw card numbers.
  • Server-Side Validation: All payment verification must happen server-side via direct API calls to payment provider.
  • Environment Separation: Test credentials must fail in production. Misconfigured gateways commonly accept test cards on live sites.

Common Failures

Real-world examples from Stripe, PayPal, OWASP:

  • Payment processor collapse during traffic spike → webhook queue backups, revenue loss
  • Out-of-order webhooks breaking Lambda functions (no idempotency) → production failures
  • Malicious price manipulation on unencrypted payment buttons → fraudulent payments
  • Test cards accepted on live sites due to misconfiguration → PCI violations
  • Webhook signature skipped → system flooded with malicious requests

Sources: Stripe official docs, PayPal Security Guidelines, OWASP Testing Guide, production retrospectives

Output

  • Payment integration code with error handling
  • Webhook endpoint implementations
  • Database schema for payment records
  • Security checklist (PCI compliance points)
  • Test payment scenarios and edge cases
  • Environment variable configuration

Always use official SDKs. Include both server-side and client-side code where needed.