TomB01

Excellent! My next test order was Prepared, Transacted, and Received all in one fell swoop! I figured I was missing something. Thanks!

I'm confused. I've installed stripe_sca on my Phoenix 1.0.4.0 store and everything appears to work OK. However, I noted this in an earlier post: So, I could not tell anything in Phoenix Admin after successfully processing a shopping cart. I kept trying to update the order status to something that would call the webhook, to no avail. So, after seeing the post with the quote above, I went to Stripe's dashboard and saw that there was a button to "Capture" the credit card payment. That registered a successful call to the webhook and it looks like I finally got the money (in test mode). I rarely, if ever, visited the Stripe site in managing my existing 2.3.4 store. Is there nothing that will call the webhook from Phoenix? Do we have to visit Stripe to capture the payment every time we get a credit card purchase? Probably I'm missing something, as usual ...

I have the same issue. I simply loaded the Phoenix 1.0.4.0 Stripe module, input the correct information (a live API is still working on my 2.3.4 store), but testing doesn't work. Stripe shows a 404 error from using a "GET" with the following string: /v1/charges/oscommerce_connection_test. I don't know if that will help someone find the issue, but I'm going to try the SCA, since the current Stripe module in Phoenix appears to use APIs that originated in 2014 and have been updated twice by Stripe since then, according to their site.

I have FedEx Web services working on Phoenix 1.0.4.0 and PHP 7.1. The attached two files from the 9.5 FedEx Web Services were edited to remove the old references "TABLE_", "DIR_FS_" and "DIR_WS_." Lower case table names without the "TABLE_" prefix were used to replace; full, lower-case path strings were used to replace the "DIR_" references. fedex-common.php5 is placed in catalog/includes/library/ (you create the "library" folder on a new install) fedexwebservices.php is placed in catalog/includes/modules/shipping/ These have been far from completely vetted, but everything seems to be working fine on my Phoenix build. fedex-common.php5 fedexwebservices.php

I see. Well, maybe Kymation will update this USPS add-on when he gets a chance. Thanks again!

SUCCESS! I didn't realize Inserting into the database would add those lines to the Admin pages. I copied and entered the SQL, the lines appeared as you said they would, then entered my store's zip code. Checked my running Phoenix and USPS works! (Yeah, I have to grab the USPS logo gif, but I can handle that based on the earlier posts.) Many, many thanks!! Do we need to tell Gary/Burt to include those database items in later Phoenix fixes?

1) A bit of miscommunication; I'm familiar with phpMyAdmin, and am prepared to copy and poke. I was just trying to figure out where to place the actual values in those SQL statements. I think the country is already defined in your first SQL statement with ID = 223, but was trying to figure out the best place to put the real value of my zip code (5 digits) in the second SQL statement. 2) Kymation has taken it upon himself to support the USPS Rate V4 module for the last several years, thank goodness! I will be dead as an e-commerce store if I don't have USPS shipping.

OK - haven't used SQL for awhile, but the top "INSERT INTO" doesn't need anything, right? Country of origin is already "United States" when the id = 223. Correct? On the 2nd INSERT INTO, I replace 'Enter the Postal Code (ZIP) of the Store to be used in shipping quotes." with my store's zip code numbers, as in 'xxxxx' - correct?

Where is Country of Origin and Post Code stored in the database? Maybe I can manually poke them into the database until Gary updates 1.0.4.0.

Interesting ... I think I was getting mixed up in the former post. The older version of OsCommerce that runs my live store has it stored under Configuration->Shipping/Packaging, not Modules->Shipping. I'll continue to search for differences, re: 1.0.3.0 and 1.0.4.0.

Yes. I checked my copies of 1.0.3.0. and 1.0.4.0. Both only have 4 files under includes/modules/shipping: flat.php item.php table.php zones.php These seem to match up exactly with the options I have under Modules->Shipping. None of those have anything about entering a zip code, postcode or whatever. The store address under the Admin Configuration has it, but there is no formatting discipline with that entry and probably has nothing to do with an actual store originating postcode.

1) 1.0.4.0 2) just sloppy copy/paste - it's not present on the actual site's page

1.0.4.0

"These items are not available in the Admin->Configuration->Shipping/Packaging for Phoenix (might also be why I could never make USPS work for any CE version)." Unless I'm missing something, there's no zipcode entry in any of these: Shipping/Packaging Title Value Action Enter the Maximum Package Weight you will ship 35 Package Tare weight. 3 Larger packages - percentage increase. 10 Allow Orders Not Matching Defined Shipping Zones False (sloppy cut and paste)

OK - got past the modules.php thing and have it installed in Phoenix 1.0.4.0 (thanks, Kymation!). In Admin, everything looks fine. However, USPS shipping won't even appear in the checkout. I set the Debug e-mail and apparently, the USPS server has no idea where my store is located. In previous versions of oscommerce, this was set in the Configuration->Shipping/Packaging, which included items in the list for "Country of Origin" and "Postal Code." These items are not available in the Admin->Configuration->Shipping/Packaging for Phoenix (might also be why I could never make USPS work for any CE version). Where can I set my store's zip code so that the USPS server can respond with shipping rates?

OK - at least with my hosting service (HostGator), it seems all I had to do was upgrade to PHP 5.4. That fixed everything.

OK - it's all fixed and I even went back to the original UPSXML v1.61 file. It seems that all I had to do was upgrade my PHP to 5.4 on my server.

I'm sorry, but the very reason I mentioned the UPSXML is because adding the curl statement you suggest worked for the UPSXML issue. I referenced "curl_setopt($curl, CURLOPT_SSLVERSION, 6);" in my original post that created this thread. (UPSXML used $ch instead of $curl.) Trying that statement in stripe.php however, did not work. Why would it work for UPSXML, but not stripe? Note that in UPSXML I also had to specify $this->use_exec = '1'; but this statement doesn't exist in stripe.php. I just tried it again using "curl_setopt($curl, CURLOPT_SSLVERSION, 6);" It failed. My hosting service is HostGator. I have spent hours with them before on the TLS issue regarding UPSXML and it took this forum to finally come up with a solution. I'm hoping that you will find what's wrong here.

Maybe I should've posted my issue here. Stripe is telling me that unless I start using TLS later than 1.0, my store's requests will not go through as of June 13, 2018. I am using the Harald Ponce de Leon module v.1.1. Experience with a similar issue for UPS XML shipping tells me the issue is in the stripe.php file. That's how we were able to upgrade the calls to TLS 1.2 with the UPS shipping module (upsxml.php). I can't find similar code in the stripe.php file, however. I'm pretty sure it has to do with the curl calls, but like you said, it's way above my pay grade.

I've been using the Stripe.js 1.1 payment module since I loaded OScommerce 2.3.4 several years ago. It's worked without a hitch since then. However, I received an e-mail a couple of weeks ago from Stripe. It said my OScommerce store has been making Stripe requests using TLS 1.0. Further, Stripe says they will disable all requests using TLS 1.0 as of June 13, 2018. My ham-handed effort at testing the stripe.php file and using the Stripe test API keys, also results in this: This is identical to a problem I discovered recently with my UPS XML 1.6.1 shipping module. We solved that and it works great - link here: Since my UPS shipping now works, that means my hosting service has all the proper tools to use the later TLS 1.2. However, I cannot find similar code in the stripe.php. I found the section using curl, and tried to add this line that we added in the UPS module: curl_setopt($ch, CURLOPT_SSLVERSION, 6); That failed. Anyone know how I can make my Stripe module use TLS higher than 1.0?

Yeah, I forgot the new URL was imbedded in the middle of that description up there. That's what probably broke it in the first place, but I had installed the new version of UPSXML in the interim and then developed the security issue.

That error happened spontaneously. I only discovered it recently when using a test account to my store. (My store has operated for many years.) I had just experienced a recent change with USPS that broke my 1st Class Shipping (1st Class Parcel to 1st Class Package - Retail). In fixing that, I noticed that the UPS Shipping was broken, too - with that error message. My first reaction was to upgrade to the latest UPS XML as mentioned in the first post up there. That didn't fix it and resulted in the numerous posts above, until Valeriy's post up there fixed it - changing the "0" to "1" in the code of upsxml.php. That line that Valeriy references is somewhere in the middle of that file, but fairly easy to locate: $this->use_exec = '0'; The latest UPSXML contrib has the "0" as default. Anyway, changing that "0" to "1" fixed it for me. Numerous trouble chats with both UPS and my HostGator services accomplished nothing.

I'll be danged - that worked! Many thanks, Valeriy! It's unbelievable how much difference it made changing a '0' to '1' on that line.

There is something else going on. HostGator has proven to me that TLS 1.2 is working on my server. Yet, UPS still gives that as the reason for the cURL error 35. Ideas, anyone?