Cursor rules for authentication and billing work
How to encode durable access, payment and verification constraints in repository-scoped Cursor rules without turning one rule file into a vague prompt dump.
Keep a small always-applied architecture rule, add scoped rules for authentication and billing files, reference the source-of-truth documents, and require server-side authorization plus end-to-end verification for every state transition.
Use rules for invariants
A good rule preserves constraints that must survive many tasks: which identity system is authoritative, where authorization is enforced, which payment events create entitlements and which credentials may never reach the client.
Task-specific instructions such as “change this button” belong in the current request, not in a permanent rule.
- Keep the always-applied rule short and architectural.
- Scope detailed rules to relevant paths such as auth, billing, API and database migrations.
- Reference source files rather than duplicating large documents.
Describe state ownership
Authentication and billing bugs often come from two systems disagreeing about state. The rule should state whether the identity provider, application database or Stripe owns each field and how changes are synchronized.
For subscriptions, the browser redirect is user experience. The signed webhook is the durable server signal. The entitlement stored in your application is what the product should authorize against.
- Never grant paid access from an unverified client redirect.
- Process relevant webhooks idempotently.
- Reconcile subscription and entitlement state when events are delayed or missed.
Require negative verification
Rules should make the agent test what must not happen: unauthenticated access, cross-account access, unsigned webhooks, duplicate events and cancelled subscriptions retaining premium access.
This produces evidence for the boundary, not only for the expected happy path.
- Run the build and affected tests.
- Inspect browser network and server logs for the complete flow.
- State what could not be verified without a real external event.
Version the rules with the code
Repository-scoped rules should change when architecture changes. Review them like code because outdated instructions can make an agent consistently implement the wrong design.
Cursor Project Rules are stored in the repository, can be scoped by path and can reference other files, which makes them suitable for this layered approach.
Common questions
Where should Cursor Project Rules live?
Current Cursor documentation places project rules in .cursor/rules as version-controlled files scoped to the codebase.
Should authentication and billing share one rule?
Keep shared architecture invariants together, but use focused scoped rules when the detailed constraints and affected files differ.
Can rules replace tests?
No. Rules guide implementation and verification; tests and runtime evidence determine whether the implementation works.
Primary references
Platform behavior changes. These primary sources define the external capabilities referenced in this guide.
Cursor: RulesStripe: Subscription webhooks