Run any Skill in Manus with one click

sales-paddle

Stars58

Forks7

UpdatedJune 27, 2026 at 17:01

Paddle (paddle.com) platform help — Merchant of Record (MoR) billing for SaaS, apps, and digital products: localized checkout, subscriptions, global sales-tax/VAT compliance + remittance (300+ markets), invoicing, fraud, Retain dunning, and ProfitWell Metrics. Paddle Billing REST API (api.paddle.com, Bearer key, sandbox) with HMAC-SHA256 signed webhooks and a Docs MCP. Use when building a Paddle Billing API or webhook integration, migrating off the legacy Paddle Classic API to Billing, verifying webhook HMAC signatures or handling out-of-order/duplicate events, subscriptions or transactions not provisioning access, amounts wrong because money is cents-as-a-string, syncing MRR/subscriptions to a warehouse, or understanding the 5% + $0.50 MoR fee and payout timing. Do NOT use for choosing a Merchant of Record across providers (use /sales-merchant-of-record), checkout-conversion optimization across tools (use /sales-checkout), or Lemon Squeezy-specific help (use /sales-lemonsqueezy).

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

sales-skills

sales-skills/sales

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

File Explorer

4 files

SKILL.md

readonly

More from this repository

same repository

sales-do

sales-skills/sales

Routes any sales, marketing, ad, or GTM objective to the right specialized skill and outputs the install command for that skill plus a ready-to-paste prompt packed with the user's context. Asks clarifying questions when the objective is ambiguous, then hands back a copy-paste-runnable next step. Covers prospecting, outbound cadences, deals, proposals, forecasting, deliverability, enrichment, intent, content, coaching, CRO, SEO, launch directories, newsletters, email/SMS/push marketing, chatbots, influencer marketing, social media, employee advocacy, media relations, reviews, data hygiene, B2B advertising, retargeting, affiliate, loyalty, digital products, memberships, webinars, checkout, and platform-specific help. Use when the user has a sales or marketing question and isn't sure which skill to use, or wants a multi-skill sequence with a batch install command. Do NOT use to solve problems directly — this skill only routes.

2026-06-2858

sales-phantombuster

sales-skills/sales

PhantomBuster (phantombuster.com) platform help — code-free web/LinkedIn automation + scraping + lead-gen: 'Phantoms' (LinkedIn search export, scrapers, auto-connect, email finder), Flows that chain them, AI Agents + a cloud LinkedIn Leads database. Developer surface: a REST API (base phantombuster.com/api/v2, X-Phantombuster-Key-1 header) to launch agents (POST /agent/{id}/launch → container id) and fetch run results (/containers/fetch-result-object), plus the Leads storage and per-agent webhooks (secret param, 11s timeout) on run completion. Billed by execution time + slots; API on all paid plans. Use when launching a Phantom or fetching its scraped output via the API, wiring a run-finished webhook, handling the async agent→container model, managing slots/execution-time, or LinkedIn cookie/safety issues. Do NOT use for prospect-list / lead-sourcing strategy across tools (use /sales-prospect-list), enrichment strategy across vendors (use /sales-enrich), or outbound cadence strategy (use /sales-cadence).

2026-06-2858

sales-prospect-list

sales-skills/sales

Builds targeted B2B prospect lists for outbound campaigns from database providers (Apollo, ZoomInfo, Clay, Cognism). Use when you don't know who to target, your outbound list is too broad and response rates are low, you can't find the right decision-makers at target accounts, your ICP is vague, or your prospect list is full of bad-fit contacts. Do NOT use for enriching existing contacts with emails/phones (use /sales-enrich), interpreting buying signals (use /sales-intent), general Apollo platform help (use /sales-apollo), or hyperlocal / door-to-door / territory / route-based outbound to local SMBs that aren't on databases — restaurants, gas stations, salons, contractors, HVAC — (use /sales-field-sales).

2026-06-2858

sales-intent

sales-skills/sales

Interprets buying signals and prioritize accounts for outreach. Use when drowning in intent data and not sure what matters, can't tell which accounts to prioritize, buying signals aren't translating to pipeline, job change alerts are noisy, intent topics feel too broad, lead scores don't match actual deal quality, or not sure how to act on signals in outreach. Do NOT use for building prospect lists (use /sales-prospect-list), enriching contacts (use /sales-enrich), ZoomInfo-specific intent config (use /sales-zoominfo), or general Apollo platform help (use /sales-apollo).

2026-06-2858

sales-syncgtm

sales-skills/sales

SyncGTM (syncgtm.com) platform help — AI-native GTM data engine that unifies buying signals (job changes, funding, hiring, LinkedIn posts, web-traffic, custom AI signals), waterfall enrichment (verified emails/mobiles, 40+ providers), AI lead scoring (0–100 vs ICP), AI research agents, and a no-code Workflow Builder. Developer surface: an MCP server (api.syncgtm.com/mcp, OAuth browser sign-in, free-plan — works with Claude Code/Cursor to enrich, find emails/phones, read signals), a REST API (api.syncgtm.com, API key), webhooks, and 40+ integrations (HubSpot/Salesforce/Slack/Attio). Use when connecting the MCP server to an AI agent, enriching contacts via the API, acting on buyer signals, scoring leads vs an ICP, building a signal→enrich→outreach workflow, or choosing SyncGTM vs Clay/Trigify. Do NOT use for intent-data strategy across tools (use /sales-intent), prospect-list building (use /sales-prospect-list), or enrichment strategy across vendors (use /sales-enrich).

2026-06-2858

sales-cadence

sales-skills/sales

Designs multi-channel outbound cadences with timing, A/B testing, and content. Use when outbound sequences getting low reply rates, unsure how many touchpoints or what spacing to use, cadence emails sound generic, prospects ignoring calls, A/B tests not moving the needle, sequence performance plateauing, or not sure which channels to include in outreach. Do NOT use for marketing cold email (use /cold-email), automated email flows (use /email-sequence), or general Salesloft platform help (use /sales-salesloft).

2026-06-2858

name	sales-paddle
description	Paddle (paddle.com) platform help — Merchant of Record (MoR) billing for SaaS, apps, and digital products: localized checkout, subscriptions, global sales-tax/VAT compliance + remittance (300+ markets), invoicing, fraud, Retain dunning, and ProfitWell Metrics. Paddle Billing REST API (api.paddle.com, Bearer key, sandbox) with HMAC-SHA256 signed webhooks and a Docs MCP. Use when building a Paddle Billing API or webhook integration, migrating off the legacy Paddle Classic API to Billing, verifying webhook HMAC signatures or handling out-of-order/duplicate events, subscriptions or transactions not provisioning access, amounts wrong because money is cents-as-a-string, syncing MRR/subscriptions to a warehouse, or understanding the 5% + $0.50 MoR fee and payout timing. Do NOT use for choosing a Merchant of Record across providers (use /sales-merchant-of-record), checkout-conversion optimization across tools (use /sales-checkout), or Lemon Squeezy-specific help (use /sales-lemonsqueezy).
argument-hint	[describe what you need help with in Paddle]
license	MIT
version	1.0.0
tags	["sales","payments","checkout","platform"]
github	https://github.com/PaddleHQ

Paddle Platform Help

Step 1 — Gather context

If references/learnings.md exists, read it first for accumulated platform knowledge.

What are you trying to do?
- A) Build an API integration — create products/prices, manage subscriptions/transactions, pull reports
- B) Set up + verify webhooks (HMAC-SHA256) to provision access / run dunning
- C) Migrate from the legacy Paddle Classic API to Paddle Billing
- D) Understand the MoR model — fees (5% + $0.50), tax handled for you, payout timing
- E) Fix a problem — wrong amounts (cents-as-string), out-of-order/duplicate webhooks, signature failures
- F) Decide if Paddle vs another provider — that's a selection question (route in Step 2)
Billing or Classic? Build everything new on Paddle Billing (api.paddle.com). Only touch Classic to migrate an existing integration off it.
Sandbox first? Use sandbox-api.paddle.com with separate keys before production.

Skip-ahead rule: if the user's prompt already provides enough context, skip to Step 2.

Step 2 — Route or answer directly

If the question is about...	Route to...
Choosing a Merchant of Record / payments provider across tools (Paddle vs Lemon Squeezy vs Polar vs Stripe)	`/sales-merchant-of-record {question}`
Checkout-conversion optimization across tools (order bumps, upsells, cart recovery)	`/sales-checkout {question}`
Lemon Squeezy-specific setup/API	`/sales-lemonsqueezy {question}`
Subscription churn / dunning strategy across tools	`/sales-membership {question}`
Connecting Paddle to a CRM/other tools generically (iPaaS)	`/sales-integration {question}`

When routing, give the exact command, e.g. "This is a provider-selection question — run: /sales-merchant-of-record Paddle vs Lemon Squeezy for my B2B SaaS".

Step 3 — Paddle platform reference

Read references/platform-guide.md for the full reference — the module map (what's API vs MoR-handled vs UI-only), the MoR fee/payout model (5% + $0.50, global tax included, scheduled payouts), the data model with JSON shapes, and quick-start recipes (provision access on a subscription webhook; create a product+price; sync MRR to a warehouse).

Read references/paddle-api-reference.md for the integration surface — Paddle Billing base URLs (api.paddle.com + sandbox), Bearer auth, the entity list (products/prices/customers/transactions/subscriptions/adjustments/reports), pagination + include, the HMAC-SHA256 webhook verification pattern + event list, and the Classic-vs-Billing split. Plus the Docs MCP.

Answer using only the relevant section. Don't dump the full reference.

Step 4 — Actionable guidance

Focus on the user's specific situation:

Build on Billing; Classic is dead weight. New work uses api.paddle.com + a Bearer key (Paddle → Developer Tools → Authentication). Classic is a separate, incompatible legacy product — only touch it to migrate off.
Money is cents-as-a-string. unit_price.amount = "2000" is $20.00. Sending dollars (or a number) is the #1 first-bug. Set the correct tax_category so Paddle taxes right.
Webhooks are the source of truth — and tricky. Verify the HMAC-SHA256 Paddle-Signature, then order processing by occurred_at (delivery order isn't guaranteed) and dedupe on event_id (Paddle redelivers). Reconcile periodically via the API in case a webhook is missed.
You don't build tax. As MoR, Paddle calculates + remits sales tax/VAT — that's the whole point; don't reinvent it. The MoR-vs-DIY-tax decision lives in /sales-merchant-of-record.
Model payouts + the 5% + $0.50 fee. Paddle pays you out on a schedule after collecting; it's not instant Stripe-style settlement.
Sandbox first. Separate sandbox account + keys; never develop against production billing.

If you discover a gotcha, workaround, or tip not covered in references/learnings.md, append it there.

Gotchas

Best-effort from research (2026-06) — review these, especially fees and the API/webhook specifics, which change.

Paddle Classic ≠ Paddle Billing. Separate products with incompatible endpoints, auth, schemas, and webhooks. Build on Billing; a Classic tutorial won't work on Billing (and vice-versa).
Amounts are strings in the smallest unit (cents). "2000" = $20.00 — sending dollars or a number breaks pricing.
Webhook delivery order isn't guaranteed. A subscription.updated can arrive before subscription.created; order by occurred_at.
Webhooks can be redelivered. Make handlers idempotent on event_id so you don't double-provision.
Always verify the HMAC-SHA256 signature. Unverified webhooks are a spoofing risk; sign ts:rawbody with the per-destination secret and compare to Paddle-Signature.
As MoR, Paddle owns payouts + risk review. You're paid on a schedule (not instantly), and high-risk/disallowed categories can be declined at onboarding.
Sandbox and production are fully separate. Different accounts and keys — don't mix them.
Tax is Paddle's job. Don't build sales-tax/VAT logic; set tax_category and let the MoR handle calc + remittance.

Related skills

/sales-merchant-of-record — Choosing a Merchant of Record / payments provider across tools (Paddle vs Lemon Squeezy vs Polar vs Creem vs Stripe; MoR vs self-managed tax)
/sales-checkout — Checkout-conversion optimization across tools (order bumps, upsells, cart recovery)
/sales-lemonsqueezy — Lemon Squeezy platform help (the closest MoR competitor)
/sales-membership — Subscription retention / churn / dunning strategy (Paddle's Retain feeds this)
/sales-do — Not sure which skill to use? The router matches any sales objective to the right skill. Install: npx skills add sales-skills/sales --skill sales-do -a claude-code

Examples

Example 1: Provision access when a customer subscribes (developer/automation)

User says: "How do I grant my app's Pro access when someone subscribes through Paddle?" Skill does: Walks Recipe 1 — register a webhook, verify the HMAC-SHA256 Paddle-Signature, then on subscription.activated / transaction.completed grant access by customer_id, and on subscription.canceled / past_due revoke or start dunning. Stresses ordering by occurred_at (delivery isn't ordered), idempotency on event_id (redelivery), reconciling via the API for missed events, and building on Billing in sandbox first. Result: Reliable, signature-verified entitlement provisioning.

Example 2: My prices are coming out 100x wrong

User says: "I set a $20 plan but Paddle shows $0.20 (or $2000)." Skill does: Identifies the cents-as-a-string model — unit_price.amount is the smallest currency unit as a string, so $20.00 = "2000". Shows the correct create-price body and notes the right tax_category so Paddle applies tax correctly. Flags this as the most common first-integration bug. Result: Correct pricing via the API.

Example 3: Should I use Paddle or Lemon Squeezy?

User says: "I'm launching a B2B SaaS — Paddle or Lemon Squeezy as my merchant of record?" Skill does: Recognizes a cross-provider selection question and routes: "run: /sales-merchant-of-record Paddle vs Lemon Squeezy for B2B SaaS with enterprise invoicing." Briefly notes Paddle's edge (most mature tax coverage, B2B invoicing) but defers the full comparison + MoR-vs-DIY decision to the strategy skill. Result: User is handed to the right strategy skill with a ready prompt.

Troubleshooting

My webhook signature verification keeps failing

Symptom: HMAC comparison never matches, so you reject valid Paddle webhooks. Cause: Hashing a re-serialized body instead of the raw request bytes, mis-parsing the Paddle-Signature header (ts=...;h1=...), or using the wrong per-destination secret. Solution: Sign the literal string "{ts}:{raw_body}" with HMAC-SHA256 using the destination's secret and compare to h1. Use the raw, unparsed request body (not your framework's parsed JSON), grab ts/h1 from the header, and confirm you're using the secret for that notification destination.

My old Paddle integration broke / docs don't match

Symptom: Endpoints, fields, or events from a tutorial don't exist in your account. Cause: Mixing Paddle Classic (legacy) and Paddle Billing (current) — they're different products. Solution: Confirm which product you're on. Build new integrations on Paddle Billing (api.paddle.com, Bearer key, the entities in the API reference). Migrate Classic integrations to Billing; don't expect Classic vendor-id/auth-code calls to work against Billing.

Subscriptions look out of sync / duplicated in my DB

Symptom: A subscription shows updated before it shows created, or you provisioned twice. Cause: Webhook delivery order isn't guaranteed and events can be redelivered. Solution: Order processing by occurred_at, make handlers idempotent on event_id, and run a periodic reconciliation that pulls current state from GET /subscriptions to repair any drift from missed/late webhooks.