Jump to content

Harald Ponce de Leon

  • Content count

  • Joined

  • Last visited

  • Days Won


Posts posted by Harald Ponce de Leon

  1. There is a bug with the Braintree App v2.011 that does not respect the Payment Zone if one has been specified. Until the next App update is pushed out, those affected by this issue can easily apply the following change.

    In the following file:


    on lines 95 and 97, the following constant is being referenced:


    simple replace both instances with the following constant:


    and save the file.

    Payment Zones will then work as normal.

  2. BTW, at https://demo.oscommerce.com, vault storage has been enabled for the following payment modules:


    Please use a test credit card number to test it out, eg:

    any expiry date in future
    any cvv code

    The stored cards are then managed in the My Account area. For your next purchase, the payment module should detect a stored token and automatically select the payment module for the order.

  3. 32 minutes ago, imusorka said:

    I think it would be best not to include the possibility of storing card details so as to safeguard inexperienced osC users from potential risks. In the US, you may not store cardholder data as per PCI DSS anyway. Are there similar regulations in the EU and Australia?

    I did not refer to storing the actual card information locally in the database - that I advise against unless you know what you're doing with PCI DSS (you 99% don't, so don't try). What I'm referring to is allowing the payment service provider store the card information on their servers and have them deal with PCI DSS (they are 100% compliant as it's their business). The payment service provider sends you a token which is stored locally in the database and is referenced for future payments. This token must be of course secured locally just the same as your payment service provider credentials must be secured. The last 4 digits of the card number is stored so the customer knows what card is going to get charged. It is here where CVV and 3D Secure can be configured to be asked for again as they have already been verified when the first purchase was made.

    The PayPal and Braintree Apps have this as a configuration option. Other payment modules that support vault storage are also configurable to enable the feature. The card input fields are loaded via iframe from the payment service provider so the card information never touches your server. There is no need to worry about PCI DSS even when stored tokens are enabled.

  4. 17 minutes ago, burt said:

    On shopping_cart.php a summary (estimated) shipping price, (estimated) taxes and so on.  So they see their grand total prior to starting a checkout.

    The shopping cart page could act as a checkout confirmation page for existing customers as their information and preferred payment options are already known. There is no need to go through the checkout steps, if the customer needs to use a different address they can click on the "edit" link and return straight back to the checkout confirmation page.

  5. Another issue to consider is the general speed loading time of your site. If it's slow, don't think a one page checkout will increase sales by 650% just because "AJAX is fast". It may be fast because the rest of the site is slow :mellow:

    Remove the left and right columns of the checkout procedure and it's a giant step towards the "one thing per page" concept.

  6. 2 hours ago, greasemonkey said:

    they do - and therefore do what knowone on here would recommend... they store you CC details.

    I advise against that too if you're going to store the details locally in your database due to PCI-DSS regulations, however there is absolutely nothing wrong with storing card details if you have a payment service provider providing you that service (most do today without an extra charge).

    To be on the safe side it's nice to have a checkbox option near the card input fields to save the card details for the next purchase. Some sites don't have the checkbox and always store the card details - this always comes down to your business and your target audience. At the very minimum it should then be described in your privacy or terms and conditions page.

    Requiring CVV and 3D Secure is common for first time purchases (though I believe amazon.de asks for neither) and is usually configurable if the CVV and 3D Secure should be asked for again for future purchases to allow one-click purchases. This again comes down to how strict you want the security checks to be to protect against fraudulent sales.


  7. There isn't a one page checkout procedure in v2.3 due to the legacy codebase having the ideology of working on browsers with cookies enabled or disabled and JavaScript enabled or disabled. The v2.4 release will still have a standard checkout procedure however it doesn't share the same ideology and can have a one page checkout in a future v2.5 or so release.

    Regarding entering card information before the checkout confirmation page, we moved those fields in the payment modules a while ago to the checkout confirmation page. I don't remember if there is a European law on it, but it's more satisfying for the customer to see the real and exact order total when entering their card information in. If something alters the order total during the checkout payment page and the checkout confirmation page (card acceptance fees?), the customer will feel cheated of giving up their card information for an order total they didn't agree to.

    For the cases where card acceptance fees are passed to the customer, the customer chooses Credit Card on the checkout payment page and first enters their card information on the checkout confirmation page where the fee is included in the order total rows. The customer sees the exact order total before entering their card information in.

  8. Sorry, I didn't write anything constructive in my post :blush:

    I think just by judging the way that one page checkout screenshot looks is overwhelming the customer with too much information on the screen at once. The checkout process column on the right is not needed as I presume that information is shown again in the last step for the confirmation. The same edit links are also available with each step listed.

    Having a JavaScript based one-page checkout procedure is nice and can outperform a standard checkout procedure, but only if it has been designed properly. The idea behind a one-page checkout procedure is to keep it as simple as possible for the customer experience, not the technical achievement experience.

  9. 2 hours ago, Roaddoctor said:

    For this type of error....

    Is there some safety net coding that could be implemented that would catch the SoapFault exception and prevent the http 500? Way over my head, but getting http 500 really throws customers for a loop and they are gone...

    Thanks for any ideas!

    Are you able to see what error is being logged that causes the http 500? Maybe an exception can be caught that automatically disables the module for that page request can be added to the code.

  10. Just now, superfrank said:

    - IPN Verification Postback to HTTPS
    I understand HTTPS should be used *IF* IPN is being used. However, the standard module does not feature "IPN" (it would involve an add-on). So that means I do not need to change anything.
    Is this correct?

    Yep, that's correct. The legacy "paypal.php" payment module does not use IPN. This first started with "paypal_standard.php".

    3 minutes ago, superfrank said:

    - Merchant API Certificate Credentials Upgrade
    A similar situation: I understand this is only if "Express Checkout" is being used. Which is not the case with the standard built-in PayPal module. So no need to change anything.

    Our PayPal modules have never used the Merchant API Certificate Credentials so nothing needs to be changed here either. The newer modules use the Merchant API Signature Credentials, nothing needs to be adapted here either.

    Regardless of which module is being used, if you can process a PayPal transaction in sandbox now, then you won't have any issues on the live server on June 30.

  11. If you can connect to the sandbox server now then you will be able to continue to connect to the live server with TLS v1.2. The sandbox server already requires TLS v1.2 connections.


    If you cannot connect to the sandbox server, it is recommended to upgrade to the latest PayPal App version which has a configuration parameter to test and force TLS v1.2 connections.


    More information about the TLS v1.2 setting in the PayPal App can be read at:



  12. That's why I asked if I could just delete the PayPal.php out of it rather than delete the directory itself.


    In that case it's safe to just delete the "admin/paypal.php" file :thumbsup: 

  13. Harald, I just did the last Paypal App updates you did and it says to delete the /admin folder if you have a custom named admin folder. Is that accurate or can we just delete the PayPal.php file out of it that your earlier update put in there?


    It's safe to delete the "admin/" directory if you use a custom admin directory with another name. You can confirm that this would be safe as the only file in the "admin/" directory should be "paypal.php" - there should be no other file or directories in the "admin/" directory.


    PayPal App v5.016 includes a full "paypal.php" file that will be copied to your custom admin directory (this file is part of the PayPal App).


    The files in the online update zip packages are separated to "catalog/" and "admin/" at the root level for the shop frontend and the administration tool files. In two online update packages the updated admin file was left in the "catalog/admin/" directory where it should have been placed in the top level "admin/" directory of the online update package. This is why the "admin/" directory was created in your shop directory. This has been corrected in our backend scripts to prevent this from happening again.

  14. it appears to be with Pay Pal standard only that they are removing commas for the thousands point. I attempted to check your demo.. but for the life me of I cannot remember the pass I used on that site and the pass forgotten email never came LOL


    It's a demo site - create another dummy account :lol: 


    I just looked through the git history of the payment modules - the PayPal modules were updated around Dec 4, 2007 (for the v2.2RC2 release on Jan 15, 2008) where the amount sent to PayPal changed from using the PHP number_format() function (using "," as a thousands separator) to a custom function where only a decimal separator is used.


    If you've experienced issues after that date, it could be possible that a third party add-on/module was used that still uses number_format() and the thousands separator to format the order total value.

  15. @@Roaddoctor Can you check and confirm on the osCommerce Administration Tool -> Tools -> Server Info page that the curl extension is enabled in your PHP installation? Searching for "curl" on the page will bring you to the curl extension information and even show you the SSL Version it is compiled with.

  16. @@birdiebitsnbites TLS v1.2 support was first added in cURL v7.34.0 (in 2013) and in OpenSSL v1.0.1 (in 2012). The cURL package may need to be updated on your web server which may trigger a system wide upgrade depending on the operating system dependencies.

  17. @@Roaddoctor Try changing the SSL Version parameter in the PayPal App General settings page.




    This parameter and the Test Connection button was added in v5.010.


    If the connection fails for both Default and TLV v1.2 settings, try disabling the Verify SSL parameter. If connections work with Verify SSL disabled but fail when it is enabled, you'll need to update your server environment to be able to verify SSL certificates correctly.

  18. Refreshed my test store and I'm receiving the following error from all the modules.


    Sandbox Server:


    Failed! Please review the Verify SSL Certificate settings and try again.


    The Verify SSL Certificate setting is not about your web server SSL certificate, it's about verifying PayPal's SSL Certificate when transactions are sent to their servers.


    Can you confirm that the following files exist:


    1) ext/modules/payment/paypal/paypal.com.crt, or

    2) includes/cacert.pem


    If those files exist and you are still getting the same error, disabling the Verify SSL parameter on the PayPal App -> Configuration -> General page will allow transactions again. This is only a temporary solution though, it is highly recommended to get your web server environment working with this parameter enabled.


    More information is available here: