Paddle

Setup

On first use, read setup.md for integration guidelines.

When to Use

User needs to integrate Paddle for SaaS payments. Agent handles API calls, webhook verification, checkout setup, subscription management, and tax compliance configuration.

Architecture

Memory lives in ~/paddle/. See memory-template.md for structure.

~/paddle/
├── memory.md     # API keys, environment, product IDs
└── webhooks.md   # Webhook endpoints and event handling

Quick Reference

Core Rules

1. Always Use Sandbox First

• Test ALL integrations in sandbox before production
• Sandbox API: https://sandbox-api.paddle.com
• Production API: https://api.paddle.com
• Never skip sandbox testing for payment flows

2. Verify Webhook Signatures

• Every webhook MUST be verified before processing
• Use the webhook secret from Paddle dashboard
• Reject requests with invalid signatures immediately
• Log failed verifications for debugging

3. Handle Subscription States Correctly

4. Store Paddle IDs Correctly

• customer_id (ctm_xxx) — unique per customer
• subscription_id (sub_xxx) — unique per subscription
• transaction_id (txn_xxx) — unique per payment
• price_id (pri_xxx) — your pricing configuration
• Map these to your internal user/subscription records

5. Use Paddle Retain for Dunning

• Enable Paddle Retain in dashboard for failed payments
• It handles retry logic and customer communication
• Track subscription.past_due events but let Paddle retry first
• Only take action after subscription.canceled from failed payments

Common Traps

• Hardcoding price IDs → Use environment variables, prices change between sandbox/production
• Processing webhooks without verification → Security vulnerability, anyone can fake events
• Ignoring past_due state → User loses access during retry window, bad UX
• Not handling proration → Confusing charges when users upgrade/downgrade mid-cycle
• Testing with production keys → Real charges, angry customers, refund headaches

External Endpoints

No other data is sent externally.

Security & Privacy