Stripe integration for Registration V2

[FinnIckler]

How do we handle the client secret? Do we just generate one for the user when he loads the page? Or do I still have to make a clientSecret URL to get it. It might depend on the registration though, so I think we need to do that first

[FinnIckler]

I added Donations and getting the clientSecret from the API. But there is still the issue that I need to set an initialAmount for the Payment Element. Do I return that with the Registration after registering? Doesn't sound too nice.

[FinnIckler]

Will it also just work like I do currently? I generate the payment intent without the donation amount, and then set it in the js by setting it in the Form.

[gregorbg]

I added Donations and getting the clientSecret from the API. But there is still the issue that I need to set an initialAmount for the Payment Element. Do I return that with the Registration after registering? Doesn't sound too nice.

I might be misunderstanding, but isn't this exactly what you were doing all along? When "entering" the payment step, you know how much the user should pay. That is by definition the initial amount that you can pre-load the payment element with.

In the past, this used to be the same amount you were requesting a Stripe PI + Client Secret for. The only difference is that now, there may be a positive amount to add to that. But as far as my understanding goes, the "initial amount" or "checkout total" was always fully specified.

[gregorbg]

Will it also just work like I do currently?

...test it out locally? Staring only at the code, it feels like you should also provide a currency to the Stripe Elements panel, but otherwise yeah this should work. You ask the backend for a Stripe PI Client Secret upon the click event, and if the amount+currency of that PI doesn't match the "temporary amount" that is loaded into the Stripe Elements thingy, the Stripe UI will complain.

[FinnIckler]

I added Donations and getting the clientSecret from the API. But there is still the issue that I need to set an initialAmount for the Payment Element. Do I return that with the Registration after registering? Doesn't sound too nice.

I might be misunderstanding, but isn't this exactly what you were doing all along? When "entering" the payment step, you know how much the user should pay. That is by definition the initial amount that you can pre-load the payment element with.

In the past, this used to be the same amount you were requesting a Stripe PI + Client Secret for. The only difference is that now, there may be a positive amount to add to that. But as far as my understanding goes, the "initial amount" or "checkout total" was always fully specified.

Currently yes, but if we have stuff like per event pricing, then we can't just use the Base Currency as the payment depends on the registration. Should we just deal with that later?

[gregorbg]

Currently yes, but if we have stuff like per event pricing, then we can't just use the Base Currency as the payment depends on the registration. Should we just deal with that later?

Yes. That is a distinct issue of per-event pricing and totally not within the scope of this PR (which is just about "reinstating" the existing payment functionality without per-event or other fancy fun)

[FinnIckler]

https://github.com/thewca/worldcubeassociation.org/assets/10168980/24ecf6c5-3090-4972-817c-001e408bb7a8

[FinnIckler]

Finally tested and ready for review!

[FinnIckler]

TODOS:

• Don't change order of steps, but set them all as completed :heavy_check_mark:
• Make Info Boxes Green :heavy_check_mark:
• Change Subtotal to non input field :heavy_check_mark:
• Look into only showing the edit registration panel when the user wants :heavy_check_mark:
• If the user is editing and has already paid, display an infobox saying so :heavy_check_mark:

[FinnIckler]

@thewca-bot deploy staging

[FinnIckler]

@thewca-bot deploy staging

[FinnIckler]

@thewca-bot deploy staging

[gregorbg]

On an unrelated sidenote: There's a bunch of merge conflicts