search

Automattic / camptix

Moved to https://github.com/WordPress/wordcamp.org/
177 stars 97 forks source link

New Stripe Integration - Bug & Enhancement #233

Open EliW opened 5 years ago

EliW commented 5 years ago

Hey there, I'm happy to contribute some code to fix these issues, as I've already written my own fixes locally via overriding some of the JS. But I wanted some guidance from @coreymckrill & whoever else has merge access as to what solution you feel you'd prefer. Two things here, but they can be a bit interrelated so:

BUG 1) . The Stripe code at the moment, throws JS errors, a lot. Basically as it stands, CampTixStripe.init hooks up the Stripe form_handler to ANY <#tix form> - Not just a real checkout form. So when you happen to choose ticket types on the first page and click to register, you get an error because StripeCheckout is not initialized yet. Since StripeCheckout doesn't get added except on the checkout form. Really the main issue here is just that all the Stripe code for camptix, got put in the big camptix.js file, and so gets executed every time.

There are multiple solutions to this: We can just tweak the code to only hook up the form_handler if StripeCheckout exists. (Simple, quick). OR we can pull the stripe 'bits' of CampTix.js out into a separate file again, and only include it on the page when stripe itself is included ... since it's properly already only included on the real checkout pages.

FEATURE 2) . At the same time, I noticed that stripe checkouts can be rather slow, especially on bad wifi (I was at WordCamp Baltimore doing some tests, and the wifi was ... ''ok'' ... ) -- You'd click to checkout with Stripe, and then a good 5 second delay would happen as you saw the browser to through the 'contacting stripe, reading data, etc'. Before finally the popup appeared.

I was looking through the Stripe Checkout documentation, to see why it was so slow and if a spinner could at least be turned on. And then I realized that currently the Camptix implementation is not 100% correct (though it works).

When you read the docs, it's designed for you to make a call to StripeCheckout.configure as soon as the page is loaded and you have the information you need. And then you hook up only StripeHandler.open to your checkout button. This way, while the user is sitting there filling out the form with their information, its taking care of getting the stripe token, and is ready to start the checkout process as soon as they click the button.

The current implementation waits until the person clicks checkout, and THEN executes the Stripe-configure, which causes the lag/wait for the software to prep itself.

I've written the code to do this the recommended way, and it works, and makes checkout SUPER snappy.

HOWEVER: There is one catch. Currently part of why the software waits is to read in the email address that the user has filled out on our form and give that to Stripe to save the user that step of re-entering it. To pre-configure. You can't do this. Personally, I think that's fine, because so often none of our attendees are the same people as the person making the purchase. So it makes sense not to autofill any attendee information into the 'billing information' field.

....

Anyway, as I said, I've already written code that can solve both of these things. I just need to know:

  1. How you'd prefer the first one be solved, via just a code check, or refactoring the .JS out

  2. If you want the fix to the latter, knowing that it means the email will have to be re-entered (but, IMO, with benefit.)

laurentdebricon commented 5 years ago

Please yes fix StripeCheckout is not defined !!!

EliW commented 5 years ago

Just wanted to re-ping here. As I said, I have code written to fix this. I just don't know how the team here would prefer the #1 be fixed (separate JS, or check for existence before attaching). Don't want to submit code for one fix and it be declined because the other code is preferred.

Also, I'd really love to submit the code to fix #2 - it REALLY speeds up checkout on Stripe. Just has the one catch-22 as mentioned.

Tagging @coreymckrill since it seems a lot of these older submissions/bugs/etc aren't being responded to, moved forward (or closed if needed). Is there someone else that is 'in charge' at the moment and I should be pinging Corey?