feat(api): include user emails in metadata - #559
Conversation
Add user email metadata in payment transactions and subscriptions for better traceability. Update worker processes to query and include user emails associated with organizations.
WalkthroughThe changes update Stripe payment integration logic across multiple modules to include the user's email address in the metadata for payment intents and subscription sessions. This enhancement is applied to payment creation, saved method top-ups, and auto top-up workflows by augmenting the metadata sent to Stripe with the user's email. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant API
participant Stripe
Client->>API: Initiate payment or subscription
API->>API: Retrieve user and organization details
API->>Stripe: Create PaymentIntent/CheckoutSession (metadata includes userEmail)
Stripe-->>API: PaymentIntent/Session confirmation
API-->>Client: Return payment/session info
Estimated code review effort🎯 2 (Simple) | ⏱️ ~7 minutes Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. ✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Pull Request Overview
This PR adds user email metadata to payment transactions and subscriptions to improve traceability and audit capabilities. The changes ensure that user emails are consistently included in Stripe metadata across different payment flows.
Key changes:
- Enhanced worker process to query and include user emails for auto top-up transactions
- Added user email metadata to subscription creation
- Added user email metadata to payment intents and saved payment method transactions
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| apps/gateway/src/worker.ts | Queries user organization relationship to include user email in auto top-up transaction metadata |
| apps/api/src/routes/subscriptions.ts | Adds user email to both checkout session and subscription metadata during pro subscription creation |
| apps/api/src/routes/payments.ts | Includes user email metadata in payment intent creation and top-up with saved payment method |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
apps/api/src/routes/payments.ts (1)
94-94: LGTM! Consider adding null safety for user email.The addition of user email to payment intent metadata is consistent and aligns with the PR objective. Both implementations follow the same pattern as existing metadata fields.
Consider adding a null safety check to ensure robust handling:
metadata: { organizationId, baseAmount: amount.toString(), totalFees: feeBreakdown.totalFees.toString(), - userEmail: user.email, + ...(user.email && { userEmail: user.email }), },Also applies to: 543-543
apps/api/src/routes/subscriptions.ts (1)
110-110: LGTM! Consider adding null safety for user email.Good approach adding user email to both session metadata and subscription metadata - this ensures the email is available for both checkout tracking and subscription management.
For consistency with the suggestion in payments.ts, consider adding null safety:
metadata: { organizationId: organization.id, plan: "pro", billingCycle, - userEmail: user.email, + ...(user.email && { userEmail: user.email }), },Apply the same pattern to both metadata objects.
Also applies to: 118-118
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
apps/api/src/routes/payments.ts(2 hunks)apps/api/src/routes/subscriptions.ts(1 hunks)apps/gateway/src/worker.ts(2 hunks)
🧰 Additional context used
📓 Path-based instructions (4)
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
Use localStorage instead of cookies for client-side data persistence
Files:
apps/api/src/routes/payments.tsapps/api/src/routes/subscriptions.tsapps/gateway/src/worker.ts
**/*.{js,ts}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
**/*.{js,ts}: Use drizzle with the latest object syntax for database operations
For read queries, always usedb().query.<table>.findMany()ordb().query.<table>.findFirst()
Files:
apps/api/src/routes/payments.tsapps/api/src/routes/subscriptions.tsapps/gateway/src/worker.ts
{apps/api,apps/gateway,packages/db}/**/*.ts
📄 CodeRabbit Inference Engine (CLAUDE.md)
{apps/api,apps/gateway,packages/db}/**/*.ts: Use Drizzle ORM with latest object syntax for database operations
For reads, usedb().query.<table>.findMany()ordb().query.<table>.findFirst()
Files:
apps/api/src/routes/payments.tsapps/api/src/routes/subscriptions.tsapps/gateway/src/worker.ts
**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/general.mdc)
Never use
as anyor: anyin TypeScript files.
Files:
apps/api/src/routes/payments.tsapps/api/src/routes/subscriptions.tsapps/gateway/src/worker.ts
🧬 Code Graph Analysis (1)
apps/gateway/src/worker.ts (2)
packages/db/src/db.ts (1)
db(13-17)apps/api/src/stripe.ts (1)
handlePaymentIntentSucceeded(316-425)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build / run
- GitHub Check: e2e / run
- GitHub Check: autofix
🔇 Additional comments (2)
apps/gateway/src/worker.ts (2)
126-136: LGTM! Good implementation of organization user lookup.The query correctly uses Drizzle ORM with the latest object syntax as specified in the coding guidelines. Fetching the first user associated with the organization is a reasonable approach for auto top-up metadata.
185-185: Excellent null safety pattern.The conditional spread syntax
...(orgUser?.user?.email && { userEmail: orgUser.user.email })provides robust null safety and should be the preferred pattern across all implementations.This approach could be adopted in the payments.ts and subscriptions.ts files for consistency.
Add user email metadata in payment transactions and subscriptions for better traceability. Update worker processes to query and include user emails associated with organizations.
Summary by CodeRabbit