Why ClubCP settled on card payments, and dropped PayPal

This post used to argue for supporting both Stripe and PayPal. That was true when it was written and it is not true any more, so here is the honest version. ClubCP takes card payments, through Stripe, and nothing else. The money still goes straight to your club's own account, which was always the point.

Why one rail instead of two

Two payment rails meant two sets of edge cases, two ways for a payment to half-succeed, and two code paths that had to agree about what a member was charged. In practice almost nobody used the second one. Carrying it made every payment change slower and riskier for the clubs that were actually taking money, so it went.

How it works

Your club connects its own Stripe account once, through Stripe's own onboarding. After that:

• Membership purchases: members pick a plan, get redirected to Stripe Checkout, complete the payment, and their membership is created on return.
• Event ticket purchases: same flow, with adult and child counts factored into the total before checkout. Members on a paid tier can get a discount automatically applied.

Money goes straight to you

ClubCP never holds funds. Stripe pays your club's account directly. That keeps the platform simple (no escrow, no compliance overhead) and means your money is your money. You handle refunds, chargebacks, and tax obligations through Stripe.

When something goes wrong

Payment edge cases are nasty: charges that succeed but never complete on our side, mismatched amounts, mid-flow cancellations. Every rejection path on the payment-execute endpoint now logs a structured event to GlitchTip with a stable reason code, so when something fails I see it without needing a user to screenshot the warning. The most dangerous case (“money taken, membership not created”) ships full stack traces so it can be fixed and refunded fast.