Harald Ponce de Leon

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: catalog/includes/modules/payment/braintree_cc.php on lines 95 and 97, the following constant is being referenced: OSCOM_APP_PAYPAL_DP_ZONE simple replace both instances with the following constant: OSCOM_APP_PAYPAL_BRAINTREE_CC_ZONE and save the file. Payment Zones will then work as normal.

@raiwa done!

BTW, at https://demo.oscommerce.com, vault storage has been enabled for the following payment modules: braintree_cc sage_pay_direct stripe Please use a test credit card number to test it out, eg: 4111111111111111 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.

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.

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.

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 Remove the left and right columns of the checkout procedure and it's a giant step towards the "one thing per page" concept.

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.

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.

Sorry, I didn't write anything constructive in my post 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.

6 steps, and entering credit card information before the checkout confirmation page? That's not an improvement.

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.

All PayPal modules we have included in our releases have always used HTTPS and POST. If you would like to make sure that your module works without disruption after June 30, you can check now by performing a test order and transaction using the PayPal sandbox server.

Yep, that's correct. The legacy "paypal.php" payment module does not use IPN. This first started with "paypal_standard.php". 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.

That's totally fine. That legacy module also uses POST to send the order information to PayPal.

This will be fixed over the weekend. It's due to API differences the forum software update introduced with the user integration implementation used in our main websites.

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: https://library.oscommerce.com/Package&en&paypal&oscom23&ssl_version

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

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.

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.

@@Sam-AUST Please test this at https://demo.oscommerce.com - it is currently on PayPal App v5.018.