Is your proposal related to a problem?
Yes. The current Stripe payment integration relies exclusively on Stripe Connect (OAuth, Standard accounts). For self-hosted operators, completing Connect onboarding now forces biometric identity verification — a government photo ID scan plus a live selfie processed with facial-recognition/biometric technology. Many people choose to self-host Cal.diy specifically for privacy and data-sovereignty reasons, and being required to hand a government ID and biometric facial data to a third party directly conflicts with that motivation. There is currently no way to accept card payments through Stripe on a self-hosted Cal.diy instance without submitting to this biometric KYC flow, which effectively locks privacy-focused self-hosters out of Stripe entirely.
Describe the solution you'd like
Add support for a direct Stripe integration mode that uses the operator's own Stripe API keys (secret key + publishable key + webhook secret) to create charges/PaymentIntents directly on the operator's own account — i.e., the same model that projects like Invoice Ninja use — as an alternative to the Stripe Connect OAuth flow. Because the operator is charging into their own single account (not acting as a marketplace paying out to third-party sellers), there is no need for Connect, client_id, or platform-mediated onboarding. This would let a self-hoster who already has a verified Stripe account accept payments by simply pasting their keys, without initiating a separate Connect onboarding that triggers biometric verification. Ideally this would be a configurable choice at the instance or app level: "Stripe (Connect)" vs. "Stripe (own account / API keys)."
Describe alternatives you've considered
- BTCPay Server app — works well and avoids KYC entirely, but only serves Bitcoin-paying customers; it doesn't cover clients who expect to pay by card.
- External automation (Cal.diy webhook → Invoice Ninja API via n8n/Zapier) to generate and send invoices on booking, or to gate a hidden event link behind an Invoice Ninja payment. This works but is fragile: payment status isn't linked back into Cal.diy, so it can't enforce true pay-to-book, and it requires maintaining a separate automation stack.
- Proceeding with Stripe Connect anyway — rejected because it mandates biometric identity verification, which is the core problem.
Additional context
- Self-hosted deployment via StartOS (
cal-diy-startos), which recently added a Stripe configuration Action exposing STRIPE_PRIVATE_KEY, NEXT_PUBLIC_STRIPE_PUBLIC_KEY, STRIPE_CLIENT_ID, and STRIPE_WEBHOOK_SECRET. The STRIPE_CLIENT_ID (ca_...) requirement is precisely the Connect-specific piece that necessitates the onboarding this proposal seeks to make optional.
- Prior art for the "own API keys" model: Invoice Ninja lets operators paste their Stripe secret/publishable keys and charge directly to their own account with no Connect onboarding.
- (Please link any related/duplicate issues found in a search of
calcom/cal.com for "stripe connect", "stripe api key", "stripe without connect".)
Requirement/Document
Is your proposal related to a problem?
Yes. The current Stripe payment integration relies exclusively on Stripe Connect (OAuth, Standard accounts). For self-hosted operators, completing Connect onboarding now forces biometric identity verification — a government photo ID scan plus a live selfie processed with facial-recognition/biometric technology. Many people choose to self-host Cal.diy specifically for privacy and data-sovereignty reasons, and being required to hand a government ID and biometric facial data to a third party directly conflicts with that motivation. There is currently no way to accept card payments through Stripe on a self-hosted Cal.diy instance without submitting to this biometric KYC flow, which effectively locks privacy-focused self-hosters out of Stripe entirely.
Describe the solution you'd like
Add support for a direct Stripe integration mode that uses the operator's own Stripe API keys (secret key + publishable key + webhook secret) to create charges/PaymentIntents directly on the operator's own account — i.e., the same model that projects like Invoice Ninja use — as an alternative to the Stripe Connect OAuth flow. Because the operator is charging into their own single account (not acting as a marketplace paying out to third-party sellers), there is no need for Connect,
client_id, or platform-mediated onboarding. This would let a self-hoster who already has a verified Stripe account accept payments by simply pasting their keys, without initiating a separate Connect onboarding that triggers biometric verification. Ideally this would be a configurable choice at the instance or app level: "Stripe (Connect)" vs. "Stripe (own account / API keys)."Describe alternatives you've considered
Additional context
cal-diy-startos), which recently added a Stripe configuration Action exposingSTRIPE_PRIVATE_KEY,NEXT_PUBLIC_STRIPE_PUBLIC_KEY,STRIPE_CLIENT_ID, andSTRIPE_WEBHOOK_SECRET. TheSTRIPE_CLIENT_ID(ca_...) requirement is precisely the Connect-specific piece that necessitates the onboarding this proposal seeks to make optional.calcom/cal.comfor "stripe connect", "stripe api key", "stripe without connect".)Requirement/Document
cal-diy-startosrelease adding Stripe config: https://github.com/Start9Labs/cal-diy-startos/releases/tag/v6.2.0_4