Polar integration

[Genyus]

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 correct moduleResolution that Polar's SDK depends on in our tsconfig.

Contributor Checklist

Make sure to do the following steps if they are applicable to your PR:

• Update e2e tests: If you changed the /template/app, then make sure to do any neccessary updates to /template/e2e-tests also.
• Update demo app: If you changed the /template/app, then make sure to do any neccessary updates to /opensaas-sh/app_diff also. Check /opensaas-sh/README.md for details.
• Update docs: If needed, update the /opensaas-sh/blog/src/content/docs.

[Genyus]

@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 selection

The 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 PAYMENT_PROCESSOR_ID environment variable which can be used to select any one of the supported platforms.

Updated schema validation

OpenSaas 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 job

The 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.

[vincanger]

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.

[vincanger]

Ok @Genyus I'd say go ahead with the implementation. It's looking good! I'm tagging @sodic here, as he will continue with the review from here on out.

[FranjoMindek]

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.

[FranjoMindek]

Good job.
Mostly docs sentence improvements suggestions.

We are missing doc changes on two locations through:

1. Setting up your Polar production webhook - https://docs.opensaas.sh/guides/deploying/
2. We need to mention Polar on guided tour, like we do with others - https://docs.opensaas.sh/start/guided-tour/

[FranjoMindek]

We are still missing docs changes mentioned here:
#461 (review)

Also before the merge it would be good to format files under template/app with prettier.

[FranjoMindek]

Hey, sorry this took a while we had of stuff happening at Wasp.

This is my final review.
The webhook logic is fine and works.
Found a little bug in fetchTotalPolarRevenue and handling of UnhandledWebhookEventError errors.
The rest are just small improvements.

After you fix these I we will have another person take a look at the PR as a sanity check.

If all goes good we are ready to merge. 🎉

[FranjoMindek]

The problem here is that we only ever fetch 100 orders.
If we have more than 100 we will never take them into consideration.

[Genyus]

That's incorrect. The list method returns an async iterator which yields each page of results, as you can see in the following lines:

/* iterates through each page */
for await (const page of result) {
    const orders = page.result.items || [];

    /* iterates through items of each page */
    for (const order of orders) {
      if (order.status === OrderStatus.Paid && order.totalAmount > 0) {
        totalRevenue += order.totalAmount;
      }
    }
  }

The iterator pattern eliminates the need to manually manage pagination parameters or check for more pages.