Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

TomB01

Members
  • Posts

    414
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by TomB01

  1. 4 minutes ago, mhsuffolk said:

    In the Stripe module in your website's admin change authorise to capture. 

    Excellent!  My next test order was Prepared, Transacted, and Received all in one fell swoop!

    I figured I was missing something.  Thanks!

  2. 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:

    Quote

    implemented authorise only transactions. Authorised transactions have to be captured using the Stripe dashboard, which will then fire the call to the webhook and complete the order

    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 ...

  3. 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.

  4. 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

  5. 3 minutes ago, ArtcoInc said:

    To enter your ZIP code into the SQL statement, replace the 'NONE' with your ZIP code (include the single quotes). Or, like I said, just update it in Admin.

    M

    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?

  6. 2 minutes ago, ArtcoInc said:

    1) You can use something like phpMyAdmin. Log into the correct database. Copy and paste the two lines above into the SQL box, and run. This will add the two entries into the correct table.

    Once the entries have been made, you should be able to use Admin -> Configuration -> Shipping/Packaging to adjust/edit these settings.

    2) I have confirmed that these two entries have been dropped from Phoenix 1.0.4.0. Since this USPS module uses the entries, the module now needs to be updated to include the instruction of how to do so! Unfortunately, it seems that the module has not been updated since 2012, nor has the original developer been here since.

    M

    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.

  7. 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?

  8. 1 minute ago, ArtcoInc said:

    @TomB01

    I've just downloaded 1.0.4.0 , and I can confirm that Country of Origin and Postal Code are not being defined in the database.

    M

    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.

  9. 11 minutes ago, ArtcoInc said:

    Are you a member of the Phoenix club?

    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.

  10. "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 pixel_trans.gif
    Title Value Action 
    Enter the Maximum Package Weight you will ship 35 icon_arrow_right.gif 
    Package Tare weight. 3 Info 
    Larger packages - percentage increase. 10 Info 
    Allow Orders Not Matching Defined Shipping Zones False Info 

     

    (sloppy cut and paste)

  11. 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?

  12. 8 hours ago, BrockleyJohn said:

    If your server is rated OK then it may be that it is not set to use TLSv1.2 by default and it must be specified.

    From a quick scan of the stripe module there are a couple of ways it communicates. It uses javascript but that's all pulled from the Stripe site so it's out of your control and probably ok. As well as that there are curl calls made by the module so you can try forcing them to TLSv1.2

    To do this find the function sendTransactionToGateway which sets a lot of curl options before the call. Add among them somewhere:

    
              curl_setopt($curl, CURLOPT_SSLVERSION, 6);

    If this doesn't do it, then the most likely explanation is that your server apparently supports TLS1.2 but it's not been done properly and the right ciphers aren't available. I had this with a customer this week (trying to get paypal going on TLS1.2).

    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.

  13. 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.

  14. 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:

    Quote

    Support for test mode requests made with versions of TLS lower than 1.2 has been disabled, and support in live mode will be dropped on June 13, 2018. Please initiate HTTPS connections with TLS 1.2 or later. You can learn more about this at https://stripe.com/blog/upgrading-tls. Please try again and if problems persist, please try another payment method.

    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?

     

     

  15. 1 hour ago, wHiTeHaT said:

    @TomB01 , what did you changed according to the innitial error: This module supports only xpci version 1.0001 of the UPS Rates Interface.

    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.

  16. 4 hours ago, ruden said:

    CURLE_SSL_CONNECT_ERROR (35)

    A problem occurred somewhere in the SSL/TLS handshake. You really want the error buffer and read the message there as it pinpoints the problem slightly more. Could be certificates (file formats, paths, permissions), passwords, and others.

    try it, but I'm not sure

    
    $this->use_exec = '1';

     

    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.

×
×
  • Create New...