tbirnseth

For the time being, the old checkout is still avaliable as an add-on. It still comes with new installations of CS-Cart (for example, with the latest 4.10.4 SP1). Eventually, deprecated add-ons stop coming with new installations, but remain in existing stores after upgrades. That way, those who used the add-on in the past can continue to do so, if they'd like.

We understand that not everyone is happy with the new checkout. Yet saying that everyone is unhappy based solely on the feedback in this topic would be an overstatement. We see that there is a large number of people who asked for the new checkout and are using it. That's why we can't immediately act on suggestions to deprecate the new checkout and bring back the old one.

However, since there is a problem, we'll be reviewing all the feedback received at the forum so far (here and in other threads) to see how we can improve the new checkout. These improvements probably won't come with 4.11.1 (it is almost finished, and is scheduled for release rather soon), but may come in later versions.

How about fixing (or at least responding to) the currently submitted defects against lite-checkiout?  I submitted a defect in 4.10.1.  You provided a solution (partial) but it does not fully work.  It works for one case only but any variation fails.  You have also NOT provided any developer documentation on any of the new attributes that need to be used on the lite-checkout page.

Also, rather than having admins have to mess with the layouts for the step-by-step addon, why not have the addon installation do that for them?  Isn't that what software is for; to automate tasks/activities so that the results are accurate?  Given the variety of languages of your customers, offering instructions (versus software) is fraught with potential error.

Note that many of us have attempted to develop addons for cs-cart that use zippay and afterpay.  The issue is NOT with cs-cart nor the addon developers.  

What happens is that when a customer goes to zip/afterpay and wants to get an api key, they deny it because the integration is NOT from one of their approved integrations.

When I contacted them to find out what needed to b done to get a new integration for cs-cart approved I was told they were no longer accepting new integrations.

Good luck getting an api key for a non-approved integration.

At least that's the way it was a couple of years ago when I tried for 2 separate clients.

Really poor business decision by cs-cart not to support developers.

So, cs-cart can't provide a list of supported attributes, their valid values and description of behavior.  How are we supposed to port addons to the new checkout?  Guess?  Or am I supposed to dig through the JS and find the attribute names and then follow the code to figure out what they do?

This is such a horrible release as it relates to changes, support and information.

Are you talking about a Product CSV import?  There are many different types of imports.  You'll have to be more specific.

This is actually one area where the documentation is mostly sufficient for most needs.

The language issue is the biggest barrier. i've had to turn down work for Portugal and S. America because documentation for requested integrations was only available in Portuguese.  However, there are many reliable vendors here.  I would look at how long people have been developing for cs-cart.  Cs-cart development is very specific and takes study time to get up to speed.  

Many of my clients come to me because of the delays in communication due to timezones (one message back and forth a day just doesn't work when defining a project) and language barriers with other developers.  They are never quite sure that the developers understand what they're stating and that makes them nervous.

Obviously I'm a developer and been working with cs-cart for over 10 years.  Have been developing production addons since 2008 but have stopped doing production development of addons because the demand just isn't there to recoup my investment.  And now with fiascos like 4.10.x has virtually destroyed my addon business unless I can afford to re-invest 100 hours to adjust my addons to be compatible with 4.10.x!  Thanks cs-cart.   However we have over 200 clients that I work with for all sorts of custom development.  We focus on backend functionality/extensions versus frontend look and feel.

Not to mention that also the community can be blamed in this situation. They have released 3 RC versions for us to review and we have not given them any comments on the checkout. If people were really that keen on new things as quickly as possible, they should've given their input at that time. 

 

Now the argument might arise that you pay them to make proper software, but its clear that CS-Cart likes to take community input when it comes to these things and since they are based in Russia, it is very hard for them to know exactly what your needs are (take a look at GDPR). 

 

So please, before starting to bash CS-Cart for their new checkout, take a look in the mirror, as you could have also prevented this if you would've just opened dev.demo.cs-cart.com

Verifying RC releases post-facto is not really what merchants sign up for.  Not sure about other's by my clients certainly don't have the time to install at test site and spend hours verifying functionality that has changed.  A supplier (cs-cart) should gather their customer requirements and build products that meet their customer's needs.  In this case, it is a fail because the "build it and they will come" strategy doesn't really work.

Where were the requests for input on a redesign of the checkout process (I.e. the essence of a cart)?  We continually get get things dropped on us that break our business process or piss off our customers.  First I heard of a new checkout was when the release was announced.

I contend that product marketing within cs-cart did NOT do their job on determining customer needs before the new checkout method was designed and implemented.  No one likes to go back and redo what they've done.  But no one will upgrade to a cart version that pisses off their customers and/or breaks their business process (including data that integrates with 3rd party environments).

Hi, can you please write how do you do this validation of billing address? 

Please write a workflow on how it organised on you side.

 

From what I know, all CC payment processors try to move to 3DS Secure, and it's rare case when some payment requires billing address.

It is the banks that do AVS.  The merchants collect the info, gateways collect from merchants and pass the data to the Banks (or for payment methods that are direct to banks, the gateway is not present) and the Banks give back AVS info like: zipcode - ok, address-ok, name match - ok, etc. (if direct to bank, merchant configuration at bank decides pass/fail)  The Gateways (or banks) are configured to let the customer choose what degree of fraud detection they want and how "tight" to make it.  There can be false positives and that's why it's configurable.  In either case, billing address info is required if you want any fraud detection at all.

As an example, our Squarepay payment method sends billing address info to Square.  Square verifies that the zipcode entered on their iFrame form matches the zip in the billing address AND the zip from the bank's billing address.  If this 3-way match doesn't validate, the card is declined.  A shipping zipcode would have zero relevance.

I realize you don't understand US banking nor US taxes.  We try to educate you but you constantly tell us what we're telling you is wrong.

Even if was "just because", it is what your customers are asking for.  That should be reason enough.

 

It's not a good idea to create extra fields for such rare case. And this can be solved by a comment. 

 

 

I did not find billing address on Amazon. Only multiple shipping profiles. If you can provide me with screen that would help.

 

You're not creating, you're taking away.  Many CC processors in US require a billing address that is matched against Address Verification for fraud.  You will lose most of your US customers or freeze them at 4.9.3.SP1.  Comments can't be processed in an automated fashion.  Comments are a lame way to add billing info.  Just consider that in US, billing address is required for most purchases and must match up against the card being used.

As I explained, Amazon has multiple payment types to choose from (I.e. different cards tied to the same account).  They are a bit special in that they do their own payment processing rather than using a gateway or aggregator, hence they utilize different fraud detection than AVS (address verification services).  They also have multiple shipping addresses.  You can just as easily order something from Amazon and use a different credit card, then cancel the order.  Go back in and order another product and you'll see the multiple payment methods (note that their payment methods are different than cs-cart.  It would be like having multiple configurations of a single payment method in cs-cart.  I.e. multiple credit cards)

If you wanted a more elegant solution, reverse shipping/billing and have the checkbox for use shipping address as billing address.  That will solve 80% of orders.  But no one can afford to loose the orders because you made a change that's inappropriate outside of your locality.

Also note that many 3rd party addons reference the customer billing address info for data.  You will break many many addons since their error log will now be filled with Notice: undefined index b_address in their error log (1 for each field referenced).

If you're going to break compatibility like this it should have been deferred to 5.0 rather than the current 4.x base.  My addons are intended to run on any 4.x system.  But now, that will be impossible.

Being unable to get a decent customer support for paid software=garbage.
If you're not a member of this Software House, you're not entitled to reply to my rants IMO. So, please, move on. 

You are on the community forum, not the cs-cart helpdesk!

Seems like it's recent.  One of my customer brought it to my attention (4.9.3.SP1) and I see it on my site and other customer sites.

Guess I'll submit a bug report.  Maybe they'll say working as designed.....

https://forum.cs-car...lesmanage-page/

EZ Admin Helper addon has been updated to detect and inoculate a new trojan malware file named adminer.php

If you are a current client, you will be automatically upgraded (as with all our addons) in the next couple of days.  I you want to upgrade immediately, use the following url to force the upgrade.

[your admin url]?dispatch=ez_maint.upgrade.force

Did not have time to unpack the affected file to see exactly what it does.  But it seems to accept commands from GET parameters and most likely accesses user and order data from your database.

Well, I feel stupid....  It was in the hidden sidebar on my client's site.

One of the joys of "rapid development models" is that a core set of assumptions is made at the beginning and there is no allowance for change. So even if it's wrong, it will be implemented incorrectly. It then becomes too much work to go back in and change things so that compatibility is maintained with both the wrong way and the right way.  The resultant code will be more buggy than if the project was reset and new information incorporated into the core assumptions and then done right.

Sorry about the negativity, but this has gone on this way for the past 10 years that I've been involved with cs-cart.  The cs-cart team only reaches out after they've implemented something and are very reluctant to admit that their assumptions were wrong or incomplete.  Hence we end up with new features that are continually patched over the next year or so of releases to account for customer demands that could have been known if input was requested and acted on before implementation.  Find a release that does NOT contain a paypal patch/fix of some kind.  It changes every release and is a very mature interface.

Then in the end when you submit bug reports, you get "working as designed" even though the defect IS the design.

I'll return to not spending my time providing input that is almost always ignored.  Cs-cart should be grateful that they have merchants and developers who are willing to spend time reviewing their plans (actually we never see plans, only rapid development implementations).  But dumping a RC out there and expecting merchants and developers to do your testing for you is simply not gonna happen.  If you have not built "testability" into your implementations, then that is something you need to correct internally.  Your test cases should use realistic situations with a wide variety of data types.  Relying on tee-shirts to represent a data set is naive.

Yep, how will they be distinguished in the back-end while making it readable/useful to the customer.  I.e. for hats, bikes, rings, etc. the customer should only see a liable of "Size".  What's needed is a label and identifier.  I.e. an identifeer might be ring-size (only visible on backend) and the label would be Size. (presented in display to customer).