PayKickstart Webhook MCP Server

PayKickstart Webhook

PayKickstart Instant Payment Notification (IPN) POSTs arrive as application/x-www-form-urlencoded form fields — one stored notification per POST, normalized to flat key/value JSON. Tools read what already landed; there is no pull API and no way to refund, cancel subscriptions, or acknowledge IPNs from here.

First moves

1. Latest notification — default for “what was the last sale”, “who bought”, or “did the rebill land”.
2. Inspect export.json.event — classifies the notification before quoting amount or buyer details.
3. Recent notifications — list when comparing rebills, spotting duplicates, or tracing a subscription lifecycle.
4. One notification by id — after listing, when the user names a specific delivery or timestamp.

Response shape

• source — capture time, filename, format, connection purpose.
• export.json — parsed IPN fields (flat keys from the upstream POST).
• export.text — raw body when JSON parsing is unavailable.

Use export.json for buyer email, amount, product, affiliate, and subscription fields.

Key payload fields

Read these from export.json — empty strings are common on optional billing or shipping fields.

event values (common)

• Sales & payments: sales (any successful charge, including rebills), refund, transaction-pending
• Subscriptions: subscription-payment, subscription-created, subscription-cancelled, subscription-completed, subscription-changed, subscription-updated, subscription-payment-failed, subscription-pending-cancelation, subscription-pending-cancellation-revoked, subscription-pause, subscription-unpaused, subscription-trial-start, subscription-trial-end, subscription-reminder, trial-expiring
• Leads: lead-added, lead-subscribed, lead-confirmed, lead-buyer
• Fulfillment: in_progress, fulfilling, shipped, delivered, returned, refunded, on_hold
• Other: cart-abandoned

One checkout can produce multiple IPNs (especially subscriptions). Events may arrive out of order — use event, transaction_id, and invoice_id together rather than assuming the latest POST is the definitive state.

Operational order

1. Start with the latest notification — do not guess a delivery id.
2. Read event and mode before reporting revenue or buyer PII.
3. For subscription questions, group by invoice_id and distinguish rebills via transaction_id and is_rebill.
4. List recent notifications only for lifecycle traces, duplicate suspicion, or explicit history asks.
5. Read ## This connection in the skill supplement for account-specific custom variable names.

Gotchas

• Read-only — cannot trigger IPNs, issue refunds, or change PayKickstart state from here.
• Purchase vs charge — invoice_id is the subscription/purchase key; transaction_id is the individual charge. Rebills share invoice_id but get a new transaction_id.
• Multiple events per purchase — a rebill may fire both sales and subscription-payment; compare event and source.captured_at when deduping.
• Test vs live — check mode before quoting revenue figures.
• Custom tracking — attribution often lives in custom_var* fields; names depend on what was appended to the checkout URL upstream.
• Empty — no stored notifications means nothing has arrived yet; say no IPN is available.