-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Polar integration #461
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Polar integration #461
Conversation
- improve encapsulation and separation of concerns - simplify stats calculation
- add JSDoc comments for PaymentProcessor methods - improve JSDoc comments for exported object
- Enable processor selection by environment variable or specified override for testing scenarios - Refactor env var validation
- Add type-safety to webhook handler - Apply current Wasp env var validation
@vincanger Still a WIP, but as I've gotten to the point where I can create orders and subscriptions, I thought I should share the changes I've made that affect other parts of the codebase for discussion. Configurable provider selectionThe current codebase requires the developer implementing the template to modify the codebase to select which payment provider to implement. I understand the reasoning behind this decision, but it also makes it impossible to implement e2e tests for multiple providers without modifying the codebase. To address this, I implemented a new Updated schema validationOpenSaas currently uses a custom validation function to ensure the required env vars are set, but with the introduction of Zod validation, this seems redundant and so I implemented Zod-based validation for this provider, which could also be applied to the existing platforms, if desired. Refactored stats jobThe stats job previously contained functions for both Stripe and LemonSqueezy, which felt like a bit of code smell as it violates the open/closed principle, so I refactored that code to make the revenue calculation a function of the PaymentProcessor interface to be implemented by each integration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did a quick review. I see out moduleResolution
is causing import issues for the polar SDK. Hopefully we can get that sorted out quick. Everything looks to be on the right track though! The main thing I'd like to change at the moment is to remove comments that are redundant as many of them just repeat what's discernible from the function name.
- Fix order status checking - Remove redundant subscription status mapping type and custom status values - Remove redundant JSDoc comments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @Genyus,
went over the PR.
Great work on this.
I'm sorry that we are asking you to remove so much from PR, but we want to focus on getting only Polar working here first.
Also I would appreciate it if you could reduce the amount of unnecessary jsdocs/comments. Didn't want to point it out everywhere since there is a lot. Do take care to use it only when we need it.
For now I've only went through the code, didn't run anything yet.
After you implement changes I would like to actually test everything out with Polar sandbox account. I would recommend you do the same.
- Remove payment processors and types - Restore hard-coded payment processor references - Remove validation schemas
- Remove unnecessary try/catch blocks - Remove excessive JSDoc comments
- Remove env var and rely solely on polar.customerSessions.create call
- Refactor sandbox mode selection logic
Merge upstream changes
- Remove ts-ignore statements
- Remove redundant type - Relocate middleware function - Rename functions - Replace string references with enum values - Remove redundant error handling
- Simplify handling logic - Remove unused types - Replace metadata parsing with built-in Polar response property checking
@FranjoMindek I may have discovered a bug, just want to check if/how it should be handled. If a user purchases some credits, then purchases a subscription, but then that sub is revoked/cancelled, while the previously purchased credits remain on their account, the user will never be able to see how many they have due to the current logic that checks for the subscription status, plan ID and payment date. Currently, all those values remain set even after cancelling a sub, so I'm wondering if the logic shouldn't be amended to display the current credits if there's no sub or if it's been deleted? |
- Simplify event handler logic - Add property assertions - Improve variable naming - Improve console output
Thanks for reporting this. This is an issue the we want to fix this, but not as part of this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job.
Not much to comment currently.
The code should work correctly, I just have some organization/renaming suggestions.
This is a good time to add the documentation changes.
(opensaas-sh/blog/src/content/docs
).
Once we resolve above + add the docs the PR is ready to merge!
- Extract updateUserPaymentDetails function to paymentDetails.ts - Enable handling of duplicate events - Improve readability of order payment handler
- Inline getCustomerPortalUrl function - Remove centralised type definitions
Merge upstream changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job.
Mostly docs sentence improvements suggestions.
We are missing doc changes on two locations through:
- Setting up your Polar production webhook - https://docs.opensaas.sh/guides/deploying/
- We need to mention Polar on guided tour, like we do with others - https://docs.opensaas.sh/start/guided-tour/
opensaas-sh/blog/src/content/docs/guides/payments-integration.mdx
Outdated
Show resolved
Hide resolved
opensaas-sh/blog/src/content/docs/guides/payments-integration.mdx
Outdated
Show resolved
Hide resolved
opensaas-sh/blog/src/content/docs/guides/payments-integration.mdx
Outdated
Show resolved
Hide resolved
opensaas-sh/blog/src/content/docs/guides/payments-integration.mdx
Outdated
Show resolved
Hide resolved
Co-authored-by: Franjo Mindek <[email protected]>
Prevents possibility of a mismatch in the persisted package
- Relocate polarMiddlewareConfigFn to match other implementations - Remove obsolete exports
Description
Adds support for Polar payments platform. Closes #441
Related to wasp-lang/wasp#3034 as we need to remove
Stitches
internally in order to be able to use the correctmoduleResolution
that Polar's SDK depends on in our tsconfig.Contributor Checklist