Payments (Stripe)

Stripe payments let a project connect payment-related behavior to a real Stripe setup when the project and workspace are configured for it.

Payments are sensitive. Plan first, configure carefully, and test before launch.

What the Stripe payment workflow is for

Use Stripe payments when your app needs:

• Checkout or paid access.
• Subscription or plan-based flows.
• Payment status awareness.
• A real payment provider instead of mock buttons.

The codebase includes Stripe connector and project payment integration surfaces. Availability may still depend on your plan, workspace policy, project setup, and required secrets.

When to plan first

Always use Plan mode before payment work. Payments touch user trust, billing, security, and support.

Use Plan mode before implementing payments.
Goal: add a paid plan checkout flow.
Inspect current project readiness and Stripe payment configuration.
Do not mock payment success.
List blockers, required settings, and tests before any code changes.

Payment safety checklist

• Confirm Stripe is configured for the project.
• Use test mode before live mode.
• Do not hardcode secret keys.
• Do not simulate successful payments for production flows.
• Test successful, canceled, and failed payment states.
• Review pricing copy.
• Confirm support and refund expectations outside the app.

Good build prompt

Build the pricing CTA flow using the configured Stripe payments integration.
Use test mode if available.
Do not hardcode Stripe secrets.
If payments are not configured, stop and explain the blocker instead of creating a fake checkout.

Limitations

If Stripe is not configured, the safe result is a clear blocker, not a fake payment flow. A mock payment UI can be useful for prototypes only when clearly labeled and never used as production behavior.

Next steps

• Plan payment work: Plan mode
• Review publishing safety: Publish your project
• Learn security basics: Privacy & security