[Traveler]

The problem is not clear for me unfortunately . Could you post any screenshots here?

Zeke,

i do not have screen shots - but I thank you for asking.

Instead you may want to take a look at a new issue that I am wondering about:

http://forum.cs-cart...ew&vbug_id=1860

[jobosales]

The problem is not clear for me unfortunately . Could you post any screenshots here?

zeke-

This was a configuration issue. When the "Pay order again" option was checked on the 'Processed' order status, the customer could mistakenly think that his payment attempt was unsuccessful; they would then make the payment again which resulted in the storeowner having to pay additional credit card fees for the extra authorizations and the refund. Traveler has now fixed the issue by unchecking the "Pay order again" for the 'Processed' status.

This situation should be further improved with the new successful order landing page which should eliminate any confusion about the payment status.

Bob

[jobosales]

zeke-

Will you be implementing this suggestion from above?

Please provide a separate message to be displayed in the 'Create account' area of the landing page so that we can pitch the benefits of registration. For instance, I would want to display:

Registered customers enjoy these additional benefits: order history, reward points, lower member prices, special promotions or advanced notice of general promotions. Enter your username and password below to create your account.

This could be implemented as a language variable since it would not likely be modified often.

Bob

[phazei]

When checking out using paypal ( and probably google ), the option to register isn't available, it just puts in the basic info, it should still be an option, not just auto guest if they aren't already logged in.

[zeke]

zeke-

Will you be implementing this suggestion from above?

Please provide a separate message to be displayed in the 'Create account' area of the landing page so that we can pitch the benefits of registration. For instance, I would want to display:

Sure, we'll implement them.

[tbirnseth]

What about providing the customer with information about WHY their order failed. I.e. an AVS mismatch where address is okay but zip is not, expiry date is wrong, bad CVV code, etc. This is huge in getting keeping the customer's frustration down and giving them the feedback they need to complete the order successfully.

I'm guess this is what's in the "big red box" or similar to the co_fail addon that was developed to address this whole area (http://www.ez-ms.com...t-failure.html).

[jobosales]

I'm guess this is what's in the "big red box" or similar to the co_fail addon that was developed to address this whole area (http://www.ez-ms.com...t-failure.html).

I pressed this issue pretty hard and zeke confirmed that the "big red box" would contain an explanation what of specifically is wrong. It will be interesting to see this in action because you are right: this is a really critical step to get the customer back on-track to a successful checkout.

Bob

[tbirnseth]

I pressed this issue pretty hard and zeke confirmed that the "big red box" would contain an explanation what of specifically is wrong. It will be interesting to see this in action because you are right: this is a really critical step to get the customer back on-track to a successful checkout.

Bob

Yep Bob, it is a big deal. Unfortunately, the developers are not merchants so what makes "development sense" does not always translate to "merchant sense". The goal should be to lighten the load on the merchant wherever possible, prevent phone calls and prevent them having to follow up with a customer just to get them to enter the correct CVV code from their credit card or to enter a correct street address..

Not sure why they can't use the co_fail addon as an example. I think it has met everyone's needs who has purchased it. It tells the user the response from the provider and presents them with the address/CC fields to update/change and then resubmit.... Pretty straight-forward from a customer and a merchant perspective.

[adodric]

Yep Bob, it is a big deal. Unfortunately, the developers are not merchants so what makes "development sense" does not always translate to "merchant sense". The goal should be to lighten the load on the merchant wherever possible, prevent phone calls and prevent them having to follow up with a customer just to get them to enter the correct CVV code from their credit card or to enter a correct street address..

Not sure why they can't use the co_fail addon as an example. I think it has met everyone's needs who has purchased it. It tells the user the response from the provider and presents them with the address/CC fields to update/change and then resubmit.... Pretty straight-forward from a customer and a merchant perspective.

I'm hoping that their solution is a little more indepth. I want the error message returned to be even more precise. On my CS Cart, I have the exact or a simplified more specific error message returned to the customer based directly on the error code my processor returns. Besides just the error message I redirect the user back to the payment page, allowing them to change the payment information and/or also edit the address information. This I feel is required for a smooth checkout and I hope they allow for this also.

[tbirnseth]

I'm hoping that their solution is a little more indepth. I want the error message returned to be even more precise. .

Can't provide information they don't have. Not too confusing to see "address matches, zip code does not".

[adodric]

Can't provide information they don't have. Not too confusing to see "address matches, zip code does not".

The processor returns a more detailed error message, at least Authorize.net does. It could be used in conjunction along with the other error details returned, such as "address matches, zip code does not".

[adodric]

But yes, any message with some detail is better than the default functionality that is currently in the cart.

[Traveler]

Probably most payment gateways give merchants detailed error messages Our gateway has pages of them but a few such as amount declined or address mismatch are the main error reasons for us.

So in some ways I do not want more detail as my current error email is nice and polite and generic.

So to make everyone happy the error information should be optional and adjustable.

As an example I am not sure that I want an amount declined by bank error message going out as it could be embarrassing. As in the customer does not want us to know why the transaction was declined.

[tbirnseth]

The processor returns a more detailed error message, at least Authorize.net does. It could be used in conjunction along with the other error details returned, such as "address matches, zip code does not".

Okay, I'm confused. In the addon I developed, this is exactly what is provided to the customer. See the screen-shots in the documentation (I know, documentation for cs-cart is a no-no) in the product detail page (http://www.ez-ms.com...t-failure.html). The documentation is in the attachments area.

After viewing the problem, the upper area of the order invoice screen has a block that is similar to the "repay" block but has the billing address and CC fields so the user can correct them and resubmit immediately upon closing the pop-up that tells them what's wrong.

Any time a failed or declined order is viewed, they get the message and the dialog for making the changes it is triggered from the order status, not from the checkout sequence.

[GHilton]

I'm just wondering when these features are going to be implemented? Does anyone have a date or a rough timescale?

[jobosales]

They will be included in version 2.1. zeke has commented in another thread that a beta should be available in mid-May. Add at least one more month for a production release.

Bob

[tbirnseth]

They will be included in version 2.1. zeke has commented in another thread that a beta should be available in mid-May. Add at least one more month for a production release.

Bob

Personally, I hope they slow the schedule down a bit and allow for more than 1 month of Beta. They rushed 2.0 out the door in 3 months or so and seemed to rely strictly on customers to find the bugs (no acknowledgment of validity of bugs or confirmation of fixes).

I would much prefer that they spend much more time internally testing and verifying compatibility with existing sites, then when they can't find any more bugs, release it into beta and leave beta "open" until all issues have been addressed. My worst fear is that it breaks the look and feel of all my customer's existing sites.

[Traveler]

Personally, I hope they slow the schedule down a bit and allow for more than 1 month of Beta. They rushed 2.0 out the door in 3 months or so and seemed to rely strictly on customers to find the bugs (no acknowledgment of validity of bugs or confirmation of fixes).

I would much prefer that they spend much more time internally testing and verifying compatibility with existing sites, then when they can't find any more bugs, release it into beta and leave beta "open" until all issues have been addressed. My worst fear is that it breaks the look and feel of all my customer's existing sites.

I second the motion!

[jobosales]

Personally, I hope they slow the schedule down a bit and allow for more than 1 month of Beta. They rushed 2.0 out the door in 3 months or so and seemed to rely strictly on customers to find the bugs (no acknowledgment of validity of bugs or confirmation of fixes).

I would much prefer that they spend much more time internally testing and verifying compatibility with existing sites, then when they can't find any more bugs, release it into beta and leave beta "open" until all issues have been addressed. My worst fear is that it breaks the look and feel of all my customer's existing sites.

I agree that the developers should take their time with this release. There are a number of big changes being delivered (new checkout and order placement routines and new tax calculations) so thorough testing is an imperative. There is also the issue that they need to deal with the new MasterCard and Discover requirements (http://forum.cs-cart...ew&vbug_id=1861) which was not on their agenda till last week.

My remark was meant to suggest that it will be a minimum of two months before 2.1 is delivered; if CS-Cart behaves responsibly with this release it will likely be a longer wait.

Bob

[Traveler]

Will there be a 2.0.15 before 2.1?