01 — The books
Xero and QuickBooks
Connect either one and every paid sale and renewal files itself as an approved invoice, with sequential invoice numbers so your accountant sees the same run you do. You do not need both — pick whichever they already use.
Both live under Integrations → Accounting, and both are part of the Worldwide Tax & Affiliates Pack. Without the pack the panel offers you the pack instead of a connect button.
02 — Your list
Email & CRM
15 email autoresponders connect directly: ActiveCampaign, Beehiiv, Brevo, Drip, EmailOctopus, Flodesk, GetResponse, HubSpot, Kit, Klaviyo, Loops, Mailchimp, MailerLite, SendFox and Sendy.
You connect one, then write follow-up rules: when this happens, tag that buyer over there. The triggers are the real events of a sale — a purchase, a refund, an upsell taken, a renewal, an abandoned checkout, a failed payment, and a payment recovered.
03 — When it fires
What actually puts a buyer on your list
Nothing is scheduled, polled or synced on a timer. A follow-up rule runs when its event happens, on a background queue, and it runs once for that event. Rules belong to an offer, so a rule written on one offer does nothing for another. A paused rule keeps its settings and fires nothing.
There are seven triggers, and these are the moments behind them:
| Trigger | The moment it runs |
|---|---|
purchase | A sale is fulfilled. Also the moment a trial starts — a trial grants access, so it counts as the purchase. |
upsell_taken | A buyer accepts a one-click upsell after paying. |
renewal | A subscription rebills successfully. The first payment is a purchase, not a renewal. |
refund | You refund, in whole or in part. |
payment_failed | A payment attempt fails — either a card declining at the checkout, or a rebill failing and dunning starting. |
dunning_recovered | A dunning retry succeeds and the subscription is healthy again. |
abandoned | The sweep finds a checkout that was started and never completed. |
How this lines up with the six webhook events
The two lists are not the same list, and the names do not match one-for-one. Every webhook event has a follow-up trigger behind it, but two triggers have no webhook at all:
| Webhook event | Follow-up trigger |
|---|---|
order.paid | purchase on a first payment, renewal on a rebill — one event, two different triggers. |
order.trial_started | purchase. |
order.refunded | refund. |
order.failed | payment_failed. |
subscription.payment_failed | payment_failed — the same trigger as a checkout decline. |
order.upsell_taken | upsell_taken. |
| nothing | dunning_recovered and abandoned fire follow-up rules but send no webhook. |
Refunds, failed rebills, cancellations
A refund fires the refund trigger, so you can tag someone as refunded and let your platform take them out of the onboarding sequence.
A failed rebill fires payment_failed once when dunning starts — once per episode, not once per retry, so a card failing every day for a week does not restart the buyer's journey seven times. If a retry later succeeds, dunning_recovered fires.
A cancelled subscription fires nothing. There is no cancellation trigger, the same gap the webhook list has. If your sequence needs to know, read the subscription rather than waiting for a tag that will not arrive.
Marketing consent decides whether any of this happens
This is the usual reason a buyer never appears in a merchant's list, so it is worth reading closely. The checkout can show a marketing-consent checkbox, and what the buyer did with it gates every rule above.
| What the buyer did | What follow-up rules do |
|---|---|
| Ticked the box | Everything runs. |
| Unticked the box | Nothing runs. An explicit "no" blocks every rule on every trigger — including purchase. That buyer will not reach your list at all. |
| Was never asked | Rules that follow a sale still run. abandoned, and a payment_failed where money never moved, run only for a buyer in a known, non-gated country — the EU, UK, EEA and Switzerland fail closed, and so does an unknown country. |
The checkbox only renders when the offer has an enabled abandoned rule. If you have never written one, no buyer on that offer was ever asked, and everything lands in the "never asked" row above. A renewal inherits the consent recorded on the original order.
Connect directly, or bridge with webhooks
A direct connection is the supported path, and it is the one to reach for first. Connect the platform, write the rule, done — the consent gate above is applied for you, the connection carries its own health state and the last error your platform returned, and a rule records when it last fired so you can tell working from silent.
Webhooks are for the case a connector cannot cover: your own code, your own database, a platform not on the list. They are the raw events, and everything after that is yours to build. Two things to know before you choose them: they carry six events rather than seven triggers, and they are not consent-gated — a webhook fires whether or not the buyer ticked the box, and honouring that choice becomes your responsibility.
04 — The part people get wrong
Who sends what
This trips up nearly everyone once, so it is worth being blunt about. Three different systems send three different things:
| What | Who sends it |
|---|---|
| The receipt, and the thank-you page with access on it | GoCushy. Automatic, every sale. |
| A tag on the buyer in your email platform | GoCushy — but it is only a tag. No email leaves us. |
| Your onboarding sequence, your newsletter, your promo | Your own platform, triggered by that tag. |
05 — Knowing it happened
Sales notifications
Sales can land in Slack, Telegram or Discord — a message in the channel you already have open, rather than another dashboard to remember to check. Set up is a webhook or a bot token, and there is a test button so you find out it works before a real sale depends on it.
The step-by-step for each is on Sales notifications.
06 — Your own code
Webhooks
If you would rather write code than connect a platform, GoCushy will POST signed events to your endpoint. The events are declared in one place and there are six:
| Event | Fires when |
|---|---|
order.paid | A payment succeeds. |
order.refunded | You refund, in whole or in part. |
order.failed | A payment attempt fails. |
order.upsell_taken | A buyer accepts a one-click upsell. |
order.trial_started | A trial begins — which grants access, so treat it as a delivery event. |
subscription.payment_failed | A renewal fails and dunning starts. |
Full payload shapes and signature verification are in the developer reference.
07 — Diagnosis
If something looks wrong
The Accounting panel offers me a pack instead of a connect button. Accounting is part of the Worldwide Tax & Affiliates Pack.
My buyers are tagged but no email went out. Working as intended — see Who sends what. The sequence lives in your platform.
A follow-up rule shows an error. The connection carries its own health state and the last error your platform returned. Read that message: it is usually an expired key or a list that no longer exists.
My endpoint never hears about a cancellation. There is no such event — see above.
08 — Next
Where to go next
The merchant guide, what happens when a renewal fails, or the REST and MCP reference.