Connect your own Stripe account, sell membership tiers, courses, and coaching in USD or GBP, and keep 100% of revenue minus Stripe's own fees.
Loading the guide...
Help us make the guides more useful.
0 helpful · 0 not helpful
Seedly Communities bills members through your own Stripe account. You connect Stripe with your keys, and every membership payment, course sale, and coaching charge settles directly into your Stripe balance. The platform adds 0% in transaction fees because it never sits between you and your members' money. That is the whole point of owning the source instead of renting a seat.
This page connects Stripe, sets up what you sell, wires the payment webhook, and walks a test payment. You only need this if you charge for access. A free community can skip it entirely.
There is no Seedly account in the middle, no revenue share, and no per-member cut. Unlimited members pay you directly.
Stripe gives every account two parallel worlds, and you use both.
Keep them strictly apart. Test keys go on development, live keys go on production, and you never put a live key in your local file. Mixing them is the most common payment setup mistake.
Create a Stripe account, then from the Stripe dashboard read your API keys.
sk_test_ in Test mode and sk_live_ in Live mode. This one stays secret. It is the only API key the platform needs - checkout runs on Stripe's hosted pages, so there is no publishable key to configure anywhere.Payments run on the backend, so the secret key and webhook secret live on your Convex deployments, set with the environment command. Use the test key on development.
Use the live key on production, and never anywhere else.
The setting names are covered on the Environment and Configuration page. You add the matching STRIPE_WEBHOOK_SECRET in Step 4.
You do not build products in the Stripe dashboard by hand. You create what you sell inside the community admin, and the platform drives Stripe for you.
Price everything in your currency. Seedly Communities supports USD and GBP. Set the currency that matches your Stripe account and your audience.
Stripe needs to tell your backend when something happens, like a payment succeeding or a subscription being cancelled. It does this by calling a webhook endpoint on your backend.
/webhooks/stripe on the end. Use the development backend URL for the Test-mode webhook and the production backend URL for the Live-mode webhook.The last three do these jobs.
checkout.session.async_payment_succeeded gives members access when they pay with a method that settles later, such as a bank debit. Without it, they pay and never get in.charge.refunded tells your community when you fully refund a payment.charge.dispute.closed tells your community when you lose a chargeback.Don't skip the two refund events. For a one-time purchase (a course, challenge, event ticket, webinar seat, coaching program or one-time membership), a full refund or lost chargeback removes what that payment bought. For a subscription payment, it shows up on the Failed Enrollments admin page (/admin/failed-enrollments) so you can decide whether to cancel the subscription. Without these two events, none of that happens and a refunded member keeps their access. A refund that leaves part of the payment in place never removes access.
If you set up Stripe from an earlier copy of the setup guide, your webhook may not send these three. Open the endpoint in the Stripe dashboard, add any that are missing to its events, and save. The signing secret stays the same. Do it for both your Test-mode and Live-mode endpoints.
whsec_) and set it on the matching backend. The platform uses it to confirm each event genuinely came from Stripe.Each mode has its own signing secret, so match test to development and live to production.
With Test mode wired up, run a real end-to-end purchase without spending anything.
Any future expiry date and any CVC work. To see a failure, use the declined test card 4000 0000 0000 0002.
When the test flow works end to end, repeat the webhook and key setup in Live mode on production, and you are ready to take real payments.
| Problem | Likely cause |
|---|---|
| Checkout errors immediately | The secret key is missing or is the wrong mode for that backend |
| A payment succeeds but access is not granted | The webhook is not connected, points at the wrong backend, or is missing an event. For a payment that settles later, such as a bank debit, check for checkout.session.async_payment_succeeded |
| A fully refunded member still has access | The webhook is missing charge.refunded or charge.dispute.closed. Adding them only covers refunds from then on, so remove access for an earlier refund yourself. If it was a subscription payment, this is by design: it shows up on the Failed Enrollments page (/admin/failed-enrollments) for you to decide |
| Webhook deliveries fail | The signing secret does not match the backend it is set on |
| A live payment tried to use a test card | You are on the live site with test keys, or the reverse. Recheck which keys are on which backend |