jasehead

I haven't tested 6.1.14 under PHP 7.4 - but given that some versions of CubeCart work/don't under different PHP versions, all I wanted to know was a PHP version where both the old and new carts would work. I didn't want to jump in at the deep and have days where the store was broken.

Then is there a mid-step version of CubeCart that will work with both PHP 7.0 (or the highest that CC6.1.14 finds compatible) and PHP 7.4?

I have an online store running CubeCart 6.1.14 with PHP version 7.0.33. I want to upgrade to CubeCart 6.5.3 which will require PHP version 7.4 (with 8.2 recommended). Is there a PHP maximum/minimum sweet spot for both versions of CubeCart so I can continue to run the old store while I test and modify the new one?

The orders list was to show how hit and miss the PayPal Commerce is working - it looks like two different methods. The orders list is basically the default Admin/Orders screen from 6.1.14 with a column added for gateway (my needs) - also, rich text because I couldn't attach an image. I abbreviated names when posting here for customer privacy, and highlighted the duplicate orders in red so you could see that a blank gateway and the paypal_commerce gateway were both shown for much the same order. This is the same gateway information in Admin that would be visible if I clicked through to the individual order (except the underscore is removed): Delivery Information Delivery Method By Weight Delivery Product Parcel Post Gateway paypal commerce But, if the gateway is blank in my orders list, then the individual order is also missing the whole "Gateway paypal commerce" row. The customer has since responded to say that she didn't notice, click or do anything differently when she was placing her order and duplicated the payment. So, if it was just a resubmit after a few seconds then why was it processed and charged differently? And if PayPal Commerce is sometimes charging a higher amount when a lower charge may apply, then isn't this potentially costing CubeCart merchants money?

Are the recent versions of CubeCart usable if we don't have a web host that supports Elasticsearch? Will future versions of CubeCart work across the board, or will all future updates be dependent on Elasticsearch? Does that mean that CubeCart merchants without access to Elasticsearch are stuck at 6.4.10? Will a non-elastic branch of CubeCart continue to be developed and updated, or at least security patched occasionally? To quote Al from 2017, considering adding Elasticsearch to CubeCart:

Orders Order Number Customer Gateway Status Date Total 231103-182455-8318 Ms M M-P paypal_commerce Processing Today, 18:24 $33.90 231103-172004-2229 Mrs J B Card_Capture Processing Today, 17:20 $44.90 231103-160532-9624 L J paypal_commerce Cancelled Today, 16:05 $37.90 231103-160525-7896 L J Processing Today, 16:05 $37.90 231103-121946-2995 Dr N R paypal_commerce Processing Today, 12:19 $15.51 231103-050647-7344 J L paypal_commerce Processing Today, 05:06 $51.43 231103-001054-8764 R P Processing Today, 00:10 $36.90 231103-000326-9144 R P Processing Today, 00:03 $43.90 231102-223011-5478 R S Processing Yesterday, 22:30 $37.90 231102-182734-8990 F V Processing Yesterday, 18:27 $33.90 231102-152831-1280 Ms J V N C PayPal Processing Yesterday, 15:28 $51.90 231102-141655-3744 T W Processing Yesterday, 14:16 $51.90 231102-130545-7361 Mrs F B Card_Capture Order Complete Yesterday, 13:05 $39.40 231102-115254-6062 Mr R T Card_Capture Order Complete Yesterday, 11:52 $37.90 231101-213219-9727 K W Order Complete Nov 01 2023, 21:32 pm $85.85 231101-210216-8780 Ms C W paypal_commerce Order Complete Nov 01 2023, 21:02 pm $37.90 231101-200803-4564 A O Order Complete Nov 01 2023, 20:08 pm $40.90 231101-195315-4301 mrs C R PayPal Order Complete Nov 01 2023, 19:53 pm $42.83 231101-193420-1939 M H Order Complete Nov 01 2023, 19:34 pm $33.90 231101-190934-6652 V A paypal_commerce Order Complete Nov 01 2023, 19:09 pm $33.90 Just to show how patchy the paypal_commerce looks (blank gateways). PayPal is the old PayPal Standard, which I was hoping to phase out.

I had an instance of one customer submitting a duplicate order via PayPal Commerce within moments of the first order, and in CubeCart I could see a blank gateway and paypal_commerce (comparing the order numbers is looks like only 7 seconds later, so not enough time to enter new payment information?). Both orders were processed and PayPal collected the payments. I manually refunded the second order. IDs are replaced with xxx in the examples shown below. First Order# 231103-160525-7896 - blank gateway shown in CubeCart: (info in PayPal) Gross$37.90 AUD PayPal fee-$1.29 AUD <-- different fee to second order, see below Net total$36.61 AUD Transaction Logs Transaction ID Status Amount Gateway Date/Time Notes xxx Completed $37.90 PayPal Today, 16:07 Payment successful. Address: confirmed Payer Status: unverified This Transaction ID has been processed before. Recipient account didn't match specified PayPal account. xxx COMPLETED $37.90 PayPal Commerce Today, 16:06 Payment completed for AUD 37.9 AUD xxx COMPLETED $37.90 PayPal Commerce Today, 16:05 Seller Protection: ELIGIBLE Settlement Mode: Capture PayerID: xxx Second Order# 231103-160532-9624 - paypal_commerce gateway shown in CubeCart: (info in PayPal) Gross$37.90 AUD PayPal fee-$0.96 AUD <-- different fee because of card payment? Then how was the first order different if only 7 seconds apart? Net total$36.94 AUD Also included card and the processor response details (not shown in the first order): Card type: VISA Address Verification Service (AVS): U CVV: Match Authentication status 3DS: Y- Cardholder enrolled ECI 3DS: 5- Cardholder authenticated by the issuer ECI Submitted 3DS: 05- Cardholder authenticated by the issuer Transaction Logs Transaction ID Status Amount Gateway Date/Time Notes xxx Refunded $37.90 PayPal Today, 21:57 You, the merchant, refunded the payment. This Transaction ID has been processed before. Recipient account didn't match specified PayPal account. xxx Completed $37.90 PayPal Today, 16:09 Payment successful. Address: unconfirmed Payer Status: unverified This Transaction ID has been processed before. Recipient account didn't match specified PayPal account. xxx COMPLETED $37.90 PayPal Commerce Today, 16:07 Payment completed for AUD 37.9 AUD xxx COMPLETED $37.90 PayPal Commerce Today, 16:07 Seller Protection: NOT_ELIGIBLE Settlement Mode: Capture Payment Method: Card liabilityShifted: true authenticationStatus: YES authenticationReason: ERROR

Does an IPN need to be set up in my PayPal settings for PayPal Commerce? I can see an old IPN in PayPal is set up for modules/gateway/PayPal/ipn.php - this may be a relic in my PayPal settings from an older version of CubeCart as far back as v3. Update: Searched forums and changed PayPal IPN to .../index.php?_g=rm&type=gateway&cmd=call&module=PayPal

Gateway name is definitely only showing in Admin/Orders half the time for PayPal Commerce. No issues with PayPal Standard.

Yes, shipping information. I likely changed a lot of the language files long ago. We don't send any parcels by ship. It was the one order that also had "Disabled in PayPal" as the phone number. We have had two other orders with PayPal Commerce. Just implemented the plugin in the last 2 days. The order in question was #2 of 3, so we're getting normal results as well - but there are different ways a customer can place their order with this gateway. Edit: Have since had other PayPal Commerce orders with no gateway info, but all now have phone numbers (all international format but no plus at the start). Also receiving orders with gateway info, so I suspect the blank gateway issue may depend on whether the customer is using a Buy Now PayPal button or working their way through the Secure Checkout in CubeCart.

Gateway information for the one order is also not showing in the Order>Overview>Delivery Information section for that order. However, it is showing in the Transaction Logs tab.

Yeah, I had worked out the settings in my PayPal account and have now switched the Customer Phone Number to ON (Optional). Maybe it needs to be set to required. It does seem dumb if the customer is required to enter a phone number in CubeCart checkout, but that phone number is overwritten by the PayPal Commerce plugin. Or is the customer skipping CubeCart secure checkout by going early to PayPal Checkout and the information in CubeCart is being fed by PayPal? (I have a separate issue with phone numbers being corrupted in CC6.1.14 - if a customer enters an international number, eg. +61419123123 and their order gets updated then the number may change to something like 122838246246 because the code is adding the number to itself. I hope that's been fixed in later versions. I've been manually fixing these as I find them because it's easy to divide by 2 (or more) to find the original number - the level of corruption depends on how many times it has been updated.)

Seems to be working. In the admin side of the CC6.1.14, my Orders list has a custom Gateway column ($order.gateway). The new gateway shows paypal_commerce, except for one order where the gateway is blank. There is information in the transaction log for that order, and it's showing in my PayPal account OK. In Cubecart, the phone number in the order shows "Disabled in PayPal" - is this an indication that the customer used Pay in 4? I still need a phone number for parcel tracking notifications or a secondary contact in case the email address is wrong.

Thank you. That fixed the blank screen problem. Will do some testing now. Does anyone know if Pay in 4 has any conditions against taking payment for pre-orders (3-4 months before completing the order)?

Tried the 1.8.7 PayPal Commerce plugin with CC6.1.14 some confirmation/return(?) screens during setup were blank (had to reload and go back through the Manage Plugins) - settings seemed complete and OK main store was blank screen, had to disable PayPal Commerce and return to PayPal Standard {foreach from=$HEAD_JS item=js}{$js}{/foreach} is definitely in my main.php head tag.

Should I try the most recent version of the PayPal Commerce plugin or an older version that might be more compatible with Cubecart 6.1.14 ?

Will I be able to experiment with PayPal Commerce without breaking PayPal Standard - so if it doesn't work I can disable it and go back to using standard?

I'm still running Cubecart 6.1.14 and I can't find an easy answer on whether the PayPal Commerce plugin will work OK for that version of Cubecart - does anybody know? Plugins often say they work with Cubecart v6 but I expect that often implies the later versions of v6 and not from 6.0 and up.

Is anyone using this successfully? Does anyone have advice or experience with this? How useful is it? What exactly does it do and not do? Does it help to track sales or just page visits? If it tracks sales, then does it work for all gateways?

store_title, store_meta_description, store_meta_keywords and store_copyright are all encoded into the config. Given that these fields can contain all sorts of store-specific text and code, some stores could occasionally trip mod_security after a server-level Core Rule Set update by the web host. If these fields turn out to be the source and the problem is reported by other stores, then maybe store information that is readily available to Google/customers doesn't need to be base64 encoded in the config array. If this problem turns out to be more widespread, then maybe it's the variables in the array. This was not a problem that I picked up right away, it was a few weeks after the CRS security update when I tried to update store settings (set a storewide discount for a temporary sale). Other stores that don't fiddle with store settings may be affected by a server update but never notice.

Finally resolved by the webhost by whitelisting a mod_security rule to avoid the false positive. My workaround in the meantime was to use .htaccess at the web root to temporarily disable mod_security, make my store settings changes and save as normal, then enable mod_security again: (in .htaccess) ## Remove hash from start of lines below if mod_security is throwing a 403 error, comment out with hashes again when done. # <IfModule mod_security.c> # SecFilterEngine Off # SecFilterScanPOST Off # </IfModule> I think the 403 forbidden/permission error, in this case, did relate to the base64 encoded config array - probably because mod_security detected a word like "ON" within the base64 text ((( OntpO decodes to :{i ))) which was common in the CubeCart_config arrays. Mod_security is probably going to be a recurring problem for some stores because: there's no telling what legitimate text is going to base64 encode into banned words, hosts using mod_security continually update the CRS (Core Rule Set) which may result in new matches/problems, and base64 can be used to hide malicious payloads - so mod_security is focussing more attention on any obfuscated code.

I did try a blanket reset of file and folder permissions - didn't fix the problem.

My webhost runs a suPHP environment. Am I going to cause issues with CubeCart if I blanket reset file permissions to 644 and folders to 755 ? Anything I need to be careful about or make custom changes afterwards?

Still no luck with the webhost. Do you think that encoding the config could be tripping a security rule? There has to be some reason why saving the store settings produces a different result to the other admin tasks.

I exported the database, deleted the duplicate rows from CubeCart_config, dropped all tables then imported the database. I was then able to assign a unique key to the name column and edit the table. Still talking with the webhost trying to sort the mod_security issue. So I decoded the config, made my settings changes, re-encoded it as Base64 and pasted it back - my changes are working OK. I'm going to need to make another settings change later, so I'm hoping to get the 403 permissions error sorted with the webhost by then.