Harald Ponce de Leon

Hi All.. The new PayPal Express Checkout payment module is nearly ready and would like to ask if you could spend a few minutes to test it out at the demo site: http://demo.oscommerce.com Please perform an order with addresses inside and outside Florida, USA, and also change the shipping address during the Express Checkout flow. The new module is configured to use the new In-Context lightbox checkout flow but can break out and revert to the classic checkout flow depending on your browser and PayPal buyer account settings. As In-Context does not currently work with the Instant Update callback, the Instant Update feature is not enabled at this time. Line items may or may not be passed to PayPal depending if the line item calculations do not match the order total calculations. If they do not, then only the order total is passed to still allow the customer to make a purchase. Line Items will almost always be sent and will not in rare situations when extra order total modules need to manipulate the order total tax values. You will also notice that when testing and switching between addresses inside and outside Florida, USA, that when returning back to the store you may be redirected to the checkout confirmation page if the transaction total does not match the order total. This would be due to taxes being added or subtracted depending on the shipping address. Otherwise if the order totals match, the order is processed immediately. Thanks, and please report back on your findings. (BTW, the top Express Checkout button should be used on the shopping cart page. The one below it is for PayFlow which will be updated next with the recent updates)

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.

Hi All.. The PayPal modules will soon receive a big update by bundling all of the modules into an "App" and also prepares backend changes that extend the functionality of the Administration Tool. The App will first spend a short period being tested before the first official production-ready release is published. If you would like to help test the App, please be sure to do so on a test or backup installation first. In addition to updated modules, some new features of the App include: *) Order Management: Full and Partial Captures + Full and Partial Refunds (a replacement for admin/orders.php is required for OSCOM versions up to v2.3.4) *) Transaction Logging: All parameters sent to PayPal and received from PayPal are logged. *) On-Boarding: Allow the App to retrieve your PayPal API Credentials for new and existing Live/Sandbox accounts (currently only available for US/UK configured stores) *) Online Updates: Update notifications and one-click updates (requires minimum PHP 5.2 and Zip) *) Automatically migrates and configures older PayPal modules Online updates will be pushed out during the testing phase to help test the online update functionality. The App is striving to be as backward compatible as possible to our earlier releases. A replacement admin/orders.php file is available for OSCOM v2.2rc2a to v2.3.4. If you would like to help out and have a test OSCOM installation to test on, please read the known issues below and the README.md file in the download package (README.md is a normal text file) which describes manual code changes that must be applied. The following url will download the latest version of the App: http://apps.oscommerce.com/index.php?Download&paypal&app&2_300 The following url will download v4.000 of the App (to test out online updates): http://apps.oscommerce.com/index.php?Download&paypal&app&2_300&4_000 Please post your experiences and feedback in this topic. Thanks, Known Issues * Admin Order transactions missing for PayPal Payments Standard and PayPal Payments Pro (Hosted Solution) added to v4.027 (28-Nov) * Payflow missing from PayPal Payments Pro (Hosted Solution) * The result of Admin Order transactions should be improved added to v4.039 (09-Dec) * Stock deduction missing from PayPal Payments Standard IPN (stock is only deducted when customer returns back to the store) added to v4.016 (08-Nov) * Refunds not working with Payments Standard Future Features (after the first public release) * Recurring Payments * 3D Secure Payments * PayPal Log Filtering

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.