Add a warning about possible plan activation delay

[meeh0w]

Overview

• Adds a warning about possible plan activation delay to prevent users from impulsively purchasing another subscription. For more details, please refer to code comments.
• Smuggles a fix to prop types of <Slider /> component (they were placed one level too deep).

Example for Visual Changes

• 

Checklist

• [x] All git commits are signed. (REQUIRED)
• [x] All new methods or updated methods have clear docstrings.
• [ ] Testing added or updated for new methods.
• [x] Verified if any changes impact the WebPortal Health Checks.
• [ ] Appropriate documentation updated.
• [ ] Changelog file created.

Issues Closed

SKY-976

[linear[bot]]

SKY-976 Warn users about subscription activation time

It's possible that after a user subscribes via Stripe, Stripe will notify us right away. The webhook event may take some time to come in and be processed. In that time, user can get confused — they paid, yet the dashboard doesn't show their subscription plan. To prevent users from impulsively trying to subscribe again, let's show an alert with a note like "It may take up to 15 minutes for your subscription to be activated on our portal. Please contact us via hello@skynetpro.net if this doesn't happen.".

[github-actions[bot]]

Deployed to https://200dfgqrfobqg2v4fsbu1ljp3p4uu7ibl0b3ilajv74h0ifnh9vb0ug.siasky.net/
Skylink: sia://EADXw1t-F6gL5H8X4NZ5HknvHkuoFjlVU_nJEEn3in6weg

[meeh0w]

@kwypchlo Yes, that's the perfect solution, but for that kind of page we'll need the backend to verify the session id attached by Stripe to the success_url. When users hit the success page, backend needs to hit Stripe's API and verify if the customer actually made a payment (and update user's tier if that's the case). This would also get rid of the need for a webhook event (at least for first purchases).

This PR here is just adding some communication while we work on a better solution (Ivo is on vacation :))

[kwypchlo]

@kwypchlo Yes, that's the perfect solution, but for that kind of page we'll need the backend to verify the session id attached by Stripe to the success_url. When users hit the success page, backend needs to hit Stripe's API and verify if the customer actually made a payment (and update user's tier if that's the case). This would also get rid of the need for a webhook event (at least for first purchases).

This PR here is just adding some communication while we work on a better solution (Ivo is on vacation :))

Ok that sounds fine although can't we just execute GET /user every couple seconds and await subscriptionStatus / subscribedUntil / subscriptionCancelAt change ?

[meeh0w]

@kwypchlo That can work too - and I do agree such a screen will be much better than this message here.

I'll update the task and work on the payment success page. But I also think we should (in the future) add that check on the backend, as without it this screen could be displayed indefinitely (there is no real timeout we can set).

[kwypchlo]

@kwypchlo That can work too - and I do agree such a screen will be much better than this message here.

I'll update the task and work on the payment success page. But I also think we should (in the future) add that check on the backend, as without it this screen could be displayed indefinitely (there is no real timeout we can set).

@meeh0w I am willing to merge this if we follow up with the proper awaiting-page, this is definitely better than current state. I am not sure @ro-tex is exposing return url configuration in his api (if we need that) so in any case so this might still be a good first step in case the follow up gets blocked.

[github-actions[bot]]

Deployed to https://2009qvc267itv5alassi2g4kir65882khesikehlki1f2h9643v20ko.siasky.net/
Skylink: sia://EACdfYIx5d-VVVc5IUCUlsxUIFSLuSo6NaSC8UUmIP4gUw