Check and complete Paddle account onboarding

When to use this skill

Use this skill when the user wants to know where their Paddle account stands — "is my Paddle account ready to go live?", "what's left to set up?", "why can't I take live payments yet?" — or before switching an integration from sandbox to live. It audits account state through the Paddle API, reports each item as done, missing, or can't tell against the go-live checklist, and offers to fix the gaps the API can fix.

It checks account state, not code. Pair it with:

• catalog-setup when products or prices are missing.
• checkout-web and webhooks for the code that uses the client-side token, default payment link, and notification destination.
• sandbox-testing once sandbox setup is complete.

The code-side go-live steps — live IDs and api.paddle.com, removing the sandbox environment from Paddle.js, passing pwCustomer, allowlisting Paddle IPs — aren't visible to the API. If the user's codebase is open, check them against the checklist too; otherwise list them as can't tell.

Before you start

• Pick the environment. Sandbox and live are separate, with separate settings, credentials, catalogs, and notification destinations — auditing one tells you nothing about the other. Use paddle-sandbox while the user is building and paddle-live when they're going live. If it's unclear, ask. When going live with both servers connected, read sandbox too: it's the reference for what live should mirror.
• Read before you write. Run the whole audit with reads only, report, then propose fixes one at a time. Never change anything during the audit.
• Expect read-only live access. paddle-live connected with OAuth starts with read access, so a live audit works straight away but live fixes need write permission. See Permissions and forbidden.