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.

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.

I don't know why the module would not be installed. It's not possible to install the module in the traditional manner as it will redirect you to the Braintree App Configuration page.
 
Try deleting the OSCOM_APP_PAYPAL_BRAINTREE_CC_SORT_ORDER parameter from your configuration table:
 
 
delete from configuration where configuration_key = 'OSCOM_APP_PAYPAL_BRAINTREE_CC_SORT_ORDER';  
Then visit the Braintree App Configuration page and it should auto-install the module for you.

@@Gergely, can you remove that charset addition and instead try the following in your PayPal account:
 
PayPal Profile -> Selling Preferences -> Language Encoding -> More Options -> UTF-8

@raiwa done!

@raiwa done!

My ethos is;
Make it very simple for the customer to do things.   As far as a checkout goes, what can be more simple than;
login > choose shipping > choose payment > review order > complete
It has been proven many times that a bite-size of cake, followed by a bite-size of cake...is far better than ramming a whole cake down ones throat.

What I would like to see [in CORE]...which is sort of related...
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.

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.

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.

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.

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.

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

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.

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

Thanks for pointing the error out. I can confirm the problem is using empty() on a constant (this produces an error on PHP < 5.5 Servers).
 
An update will be pushed out within a few hours.

Hi Fabrice..
 
 
The v2.3.5 release is based on v2.3.4 (not BS). The BS is a separate community release series.
 
v2.3.5 is based on the previous v2.3 release series. The BS release series is incompatible to v2.3.x and will merge to v2.4 when the production ready release is pushed out.

v5.0.10 has just been pushed out! This includes using the suburb value as the street2 parameter for the payment modules.
 
Thanks to Jack_mcs and greasemonkey for reviewing the address changes.

It's a one click procedure. The App checks once every 24 hours if an update is available and displays a notice. A check is always performed on the Help/Info page.
 
The update procedure makes sure the file and directory permissions are sufficient for all files being updated before the files are overwritten.
 
Feel free to try on a backup beforehand.

This will be added to the next update. v5.001 only fixes the coding error in the Payments Standard module that v5.000 introduced.

Thanks for pointing this out! This has been fixed in v5.0.1 - to apply it, visit the Info/Help page and the update notice should appear.

:thumbsup:  Another update to the PayPal App will be pushed out soon that adds an option to force TLS v1.2 connections.

It looks like you're using the latest development source code from out Github repository which is for v2.4.0beta.
 
This release series will not work with existing modules for v2.3.x - a compatibility module is planned though and will be release in a short while.
 
If you'd like to stick to the v2.4.0beta development code, try the latest source code from the PayPal App for v2.4 at https://github.com/haraldpdl/oscom2_app_paypal

Hi Derek..
 
Can you confirm that the PDT Identity Token has been setup on the PayPal Seller Profile and that the value is entered in the PayPal App -> Configure -> Payments Standard -> PDT Identity Token field?
 
It needs to match the same value as on the live or sandbox account.
 
PDT can be found on the following page at PayPal:
 

Hi Derek..
 
The response should not be empty.
 
Could you check your web server / php error log to see if errors around those times have been logged?