Miva Merchant 10.00.x Bug Reports

[oliverands]

There's been complaints in the past about the quotes module and price group pricing. I think I figured out what the issue is, and I would consider it a bug. I wrote up what I found here:

https://www.miva.com/forums/forum/on...136#post716136

[Eric Foresman]

There's been complaints in the past about the quotes module and price group pricing. I think I figured out what the issue is, and I would consider it a bug. I wrote up what I found here:

https://www.miva.com/forums/forum/on...136#post716136

Hi oliverands

Thanks for reaching out and letting us know about this. We have a bug filed for this and the fix is in testing for the next release.

Many Thanks

-Eric

[oliverands]

Since migrating to using Braintree for payment processing last month, I have noticed that quite regularly I am getting authorization failures with the message "Unable to authorize payment: Merchant account does not support 3D Secure transactions for card type." I was not able to determine what was happening with my investigation, so I reported the issue to Braintree. This is their response.

Taking a look at our logs for Errors associated with 3DS, I was able to find the error that you ran into, "Merchant account does not support 3D Secure transactions for card type." Looking at the parameters for that API call, I can see that the transaction attempt was made using a Discover card. At this time, Braintree doesn't yet support Discover cards for 3D Secure. To avoid running into error you can either avoid having customers go through 3DS if they pay with a Discover card or you can pass the threeDSecure Required field to false within the transaction sale call when someone attempts to check out with one.

Looking at an example customer who ran into this issue, customer name [XXXX], they attempted an initial transaction with Discover, but made their successful attempt with a Visa, transaction [XXXX]. As this is the case, it would seem that the errors occur with unsupported 3DS card types, but the customers then move to a valid card type that is supported by 3DS. At the current moment, Braintree's 3DS is compatible with Visa, Mastercard + Maestro, and Amex cards.

I have the module configured with the option for 3D Secure set to "Require if 3D Secure is Enabled on Card." Using this option, I would assume that if 3D Secure is not enabled on Discover cards that Miva would not be coming back with an authorization failure but would instead let the card process without requiring 3D Secure.

It appears that something in the module is not handling 3D Secure correctly on Discover cards. Or it should provide the option to enable or disable 3D Secure by card type.

[oliverands]

To follow up on the last post, I asked Braintree if it was possible on their end to disable 3D Secure for Discover at an account level to get around this problem. They report back that the call made by the Miva module is requiring 3D Secure on these cards--even though 3D Secure is not available for them and even though I have the module configured to only require 3D Secure if it is enabled on a card.

As Discover isn't enabled for 3DS within Braintree already, the main issue is that your integration is calling 3DS for those cards. As a fix, your integration would need to determine the card type using the information they gather at the time the nonce is created for the transaction and then selectively choose not to run 3DS for the non-3DS supported payment methods. Based on the current option you have available to you in your integration, it seems the only workaround to this particular error from our side would be to disable Discover as a payment method, at which point we could re-enable it once you have fixed the issue with your integration. If you would like to move ahead with that option, please let me know and I'd be happy to put you in contact with the team that can make that change.

[Leanne]

Maybe I'm doing something wrong, but I just had an interesting issue while working in a template branch on the CTGY page. This was my first time unassigning content items in a branch -- the store had two instances of the category product listing (category_listing and product_list) and I wanted to start fresh, so I backed them up, and then unassigned them from the non-production branch. Previewed the page in the non-production branch, and yep, the product listings were gone. Switched the view to production and was very surprised to see that the product listings were gone from there as well. I would have thought that in a separate branch, items could be assigned or unassigned without affecting the production branch. I don't know if this was a one off or something buggy with this particular site, but that was a tad bit disconcerting.

[SidFeyDesigns]

Leanne I felt the same way but maybe add this page to your bookmarks.

https://www.miva.com/forums/forum/on...plate-branches

Very helpful list of the changes you make that will be global or branch specific.

[Leanne]

Thanks SidFeyDesigns! Bookmarked!

[SidFeyDesigns]

Huge bug with the new 10.03.00 update.

It completely wiped every category's category tree image field.

Looks like I'll have to fill in all those fields manually, unless there is a way to retrieve what used to be in there.

[Rick Wilson]

Make sure support is aware, we're working on a fix.

[SidFeyDesigns]

Rick Wilson I already have a ticket open with support for the recent migration to Miva's hosting, so I let Joseph Kelemen know in that ticket.

Would you suggest I open a separate ticket?

Thanks.

[Rick Wilson]

No that's fine.

[lesliekirk]

Huge bug with the new 10.03.00 update.

It completely wiped every category's category tree image field.

Looks like I'll have to fill in all those fields manually, unless there is a way to retrieve what used to be in there.

Category Tree Tree Image field? I ran the update on a dev site and checked that field after seeing this post. The site I ran the update on still has it's Category Tree Tree Image fields filled. BUT what was the image path for your fields? Do you recall? This site has graphics/00000001/7/ (how it got to 7 I do not know). Wondering if that could be part of the issue you are seeing?

[Rick Wilson]

The issue appears to only impact people who's Category Tree Template images are not using the Image Machine, so limited in scope. We've pulled the patch until it's fixed though. We expect to be able to fix this on any sites that end up with this issue.

[SidFeyDesigns]

All of our Category Tree images are in their own directory (created by me) that I upload via ftp.

The directory is graphics/category-images/

I did this a while back when we used to just use Miva image machine generated images from certain products.

But if I ever changed the product image and deleted the old one we would have broken images.

So, I put them in their own directory that can't be deleted within Miva.

[lesliekirk]

The issue appears to only impact people who's Category Tree Template images are not using the Image Machine, so limited in scope. We've pulled the patch until it's fixed though. We expect to be able to fix this on any sites that end up with this issue.

Point of clarification? The site I checked, uploaded these images via the standard Category Tree Tree Image which I assume is now part of the Image Machine even though not where most people used to associate uploading images using the Image Machine (via the Images tab in the Product edit screen). That would make sense then that SidFeyDesigns lost all paths because they were hand crafted and added to the field.