Stripe.com payment integration module

[carlwhat]

i have installed v3.0.0 of stripe on a zc v2.1.0 install on a development box.

i have added a test public key and a test secret key.

i have then enabled stripe.

this system makes use of standard 3 page checkout.

orders are getting completed without any input of credit card data or anything.

is this intended behavior?

there are errors getting generated on the dev tools console. i am just not sure if they are relevant and need to be researched. i have a feeling they are.

in any event, if this is the intended behavior, i think something is adrift with the design. if it is not intended behavior then something is getting missed as one should not be able to get an order completed without the input of any payment data.

i have created the following screencast to show what is happening.

here is the corresponding screenshot of the square dashboard.

appreciate any guidance.

best.

[lat9]

@carlwhat, that first screenshot simply shows that woefully old jQuery 3.4.0 is being loaded; the second requires a stripe login.

Since I "simply" restructured the existing code, the original 'design' remains (that's why there's no debug).

I've run a test transaction through my zc210/bootstrap local test site. Using either 3-page or OPC. clicking stripe's "Confirm Order" button without filling out any of the fields results in javascript/jScript errors.

I believe that the issue with your installation is that jQuery 3.4.0 load.

[carlwhat]

@carlwhat, that first screenshot simply shows that woefully old jQuery 3.4.0 is being loaded; the second requires a stripe login.

Since I "simply" restructured the existing code, the original 'design' remains (that's why there's no debug).

I've run a test transaction through my zc210/bootstrap local test site. Using either 3-page or OPC. clicking stripe's "Confirm Order" button without filling out any of the fields results in javascript/jScript errors.

I believe that the issue with your installation is that jQuery 3.4.0 load.

the first link is NOT a screenshot. it is a screencast; ie a video replaying of what is on the screen.

i do not know what browser you are using, but i have verified that the screencast works properly in firefox and chrome. it is 41 seconds long. there is a play icon at the bottom left of the window that initiates the start of the screencast.

if you are using microsoft edge, i am sure there is something similar somewhere. but i do not know where.

the 2nd link is a screenshot. it does NOT require a stripe login. it is a screenshot of my stripe dashboard, that shows 3 different transactions, all of which say incomplete on the stripe dashboard.

this is despite the fact that on ZC, the order got completed, and the customer did not enter any CC data.

the 41 second screencast shows how the order got completed WITHOUT the customer entering any cc data.

in the 41 second screencast, i have included the dev tools console to show the errors that are coming up there.

the stripe dashboard screenshot shows the transaction of the completed ZC order, but stripe says incomplete.

in my experience, store owners infrequently look at their gateway dashboards. they rely on their ZC admin dashboard. which now has an order. and most owners would now assume a payment.

i as the customer am not sure what to make of what just happened on my computer. i have a completed order without entering any payment, and am now hoping to get some free goods; or i am wondering why this website is so messed up, and i am shopping elsewhere.

if this plugin requires a minimum jQuery version, then can you please update the installation instructions to state what the minimum prerequisites are?

even if a minimum jQuery version is required, one should not be able to complete an order without entering any payment data.

as far as your "simple" restructuring, i have followed the development and support of this payment module for quite some time. i believe i have even previously commented on this support thread. i have never felt that the coding of the original author was up to a minimum standard required for use, but i did admire his tenacity and the work that he put into it.

with your name now on it, i thought perhaps it now might be ready for prime time use.

but my testing, at least to me, still shows issues. i was hopeful that you could follow along as i thought my documentation of the problem was clear.

best.

[lat9]

Once the Stripe form-fields are displayed, control is 'owned' by the stripe-hosted javascript. I'll check their documentation to see if they have identified a minimum jQuery version.

[balihr]

carlwhat - is that a standard 3-page checkout? It seems you're on the checkout_payment page, you select your payment module and move on to checkout_confirmation, but if I'm not mistaken, that page seems to be configured to auto-submit? If that's the case, then yes, it will go straight to the success page. Stripe's payment form is displayed on checkout_confirmation and the plugin makes sure the original button is hidden so you don't submit the checkout_confirmation form, but instead you're using Stripe's button to proceed. If your checkout_confirmation has an auto-submit javascript, you're bypassing Stripe's processing and it just goes through to success.
I recently learnt this the hard way...

[carlwhat]

it is a standard 3 page checkout.

and whether i have it set to auto submit (which i am not sure how i did that), what you learned the hard way should not be allowed to happen. you should not have a completed order without having entered any payment data. bypassing stripe's processing when stripe is selected should result in an error and back to the payment page, not order success page.

i'm glad that you see the problem and understand it.

[balihr]

it is a standard 3 page checkout.

and whether i have it set to auto submit (which i am not sure how i did that),

I've done this modification numerous times when I wanted to skip the checkout_confirmation page and reduce the number of steps in checkout because the confirmation page doesn't really bring much value to the process except a final review. Plus, the original wording is horrible - step 3 of 3 is saying you're done and customers sometimes believe that's it, order placed. So, I often just hide the entire contents of checkout_confirmation and add a new block with just the spinner and have javascript submit the page. It results looking exactly like your screencast.

what you learned the hard way should not be allowed to happen. you should not have a completed order without having entered any payment data. bypassing stripe's processing when stripe is selected should result in an error and back to the payment page, not order success page.

i'm glad that you see the problem and understand it.

Oh, I couldn't agree more - this should NOT be allowed to happen and there should be a check in checkout_process that takes you back to checkout_payment in a case like this, I totally agree. But, until someone decides to update the plugin and fix this, at least we know what's happening...

[lat9]

Do the changes in this Zen Cart PR (https://github.com/zencart/zencart/pull/7453/changes) correct the issue?

[carlwhat]

Do the changes in this Zen Cart PR (https://github.com/zencart/zencart/pull/7453/changes) correct the issue?

no they do not.

[lat9]

no they do not.

Crud, although totally bypassing the confirmation step of checkout is quite the site-specific customization. For OPC's "bypass" of confirmation, the confirmation page is still 'hit' to allow the associated processing on the page. The difference is that for the "bypass", the form on that page is auto-submitted.

It feels like your site-specific change needs to check to see if "Stripe" (or any other payment module that gathers its data on the confirmation page) is selected before automatically submitting the form to proceed to the checkout_process step.