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)

We're proud to announce the introduction of a new App endeavor with the release of PayPal App for osCommerce Online Merchant! We've worked in close collaboration with PayPal to not only bring you updated PayPal payment modules but have also bundled all PayPal modules, including Log In with PayPal, into a single App package for an even tighter integration with osCommerce Online Merchant to enhance both sellers and buyers experiences with PayPal. The PayPal App is optimized for and will be bundled with the upcoming osCommerce Online Merchant v2.3.5 release and can be installed on existing installations from v2.2RC2a to v2.3.4. The PayPal App has been architectured to preview and showcase the direction we are taking the new osCommerce Online Merchant v2.4 series in and how the new series will allow you to install and update Apps on your online store through the Administration Dashboard. The PayPal App includes an online update feature that can update itself with a click of a button that will be part of the core in v2.4 for all Apps to take advantage of. We are also extremely proud to be one of the first self-hosted e-commerce solutions to allow the PayPal App to configure itself by securely retrieving the PayPal account API Credentials for you. This is currently available for US and UK sellers and allows you to sign into or create a PayPal live or sandbox account to retrieve the API Credentials from. This makes it extremely easy for new PayPal sellers to start experiencing the PayPal payment methods through a sandbox account and to create a live account as soon as they are ready to accept payments - directly from the osCommerce Administration Dashboard. In addition, the PayPal App includes: - Updated payment modules - Payments Standard: Support for Payment Data Transfer (PDT) payments - Payments Standard: Stock management in IPN notifications - Order Administration: Capture full or partial authorizations, refund full or partial transactions - API Logging: All parameters sent in and received from API calls are logged Documentation for the PayPal App is available at: http://library.oscommerce.com/Package&paypal The PayPal App can be downloaded for free at: http://addons.oscommerce.com/info/9184 We look forward to your feedback on this announcement! Please post your feedback to this topic and any support related enquiries to the following channel: http://forums.oscommerce.com/forum/54-paypal/

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.

That definitely does not sound right. Could you provide a screenshot of how that page looks? Be sure to censor out any sensitive information.

Can you describe the problem further? Does the popup window appear with the input fields to enter the amount in? This is how they should function: https://library.oscommerce.com/Package&en&paypal&oscom23&order_administration Are errors being logged and displayed in the PayPal -> Log page?

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