feature(plg): Use custom Stripe checkout#62955
Conversation
0924826 to
7025763
Compare
There was a problem hiding this comment.
I'll follow up with more specific questions in Slack, but I don't see what the actual benefit to this PR is.
Does the "Custom Stripe Checkout" just give us more flexibility in how we render the Stripe Checkout page? If so, then is the point of all of this just to restyle the "+/- seats" buttons when a new subscription is created? But we would still have the same limitations that we have today with Stripe Checkout, in that it can only be used for creating new subscriptions, but we would still need to roll our own UX for updating existing subscriptions?
Ultimately, this doesn't seem like it is something we would want to merge.
We want to:
I've investigated the alternatives and haven't found a good one, so I currently intend to merge this PR once it's done. I'm open to hearing the alternatives I might've missed, though. |
6f1fca7 to
8270582
Compare
aecdd3e to
19528b6
Compare
Use debouncing Add "loading" states Redirect after successful payment
19528b6 to
cc6a388
Compare
chrsmith
left a comment
There was a problem hiding this comment.
I didn't look super-close at the React code, but this all looks good to me. 
We want to:
...
I've investigated the alternatives and haven't found a good one, so I currently intend to merge this PR once it's done. I'm open to hearing the alternatives I might've missed, though.
All of the things you listed are great, and I am super-duper excited to have a better looking UI for the new subscription experience!
The "alternative" I'm referring to is just that, once we have all of the UI components working the way we want. (And aren't relying on Stripe Checkout to power the specific HTML/DOM.) Then we should be able to cut Stripe Checkout out of the equation entirely.
And just call our own API to create the new Stripe Customer / Subscription object. Since if we have the user-supplied seat count, name and billing address, and payment method, we have all the things we need. And being able to remove Stripe Checkout and rely on just our code for the entire experience, seems like it would simplify our overall codebase. (So perhaps not in this PR, but maybe we are within striking distance of doing that in 1-2 follow up PRs.)
taras-yemets
left a comment
There was a problem hiding this comment.
LGTM. Thank you!
Left a few comments inline.
The PR
Context: In our previous Stripe checkout implementation, we didn't have the freedom to design our seat selection UI and other parts of our checkout experience.
Problem: The current state causes three difficulties:
Solution:
I found Stripe's "Custom Checkout with Elements" solution (here), which seemed to solve all our problems without major changes or completely custom implementations of complex controls like the payment form or the address form. But then I realized that this solution was in a "Private Beta" state. I contacted Stripe, who quickly got back to me and gave us access to the API, assuring us that regardless of the Beta state, it's safe to use in production.
So I've modified the back end in:
Notes:
Current caveats:
Changelog
Test plan
No automated test, but I did a thorough QA.
Here is a 4-minute demo of a run-through.
Note: the new page is behind a feature flag and won't be in production yet.