Miva Merchant 10.00.x Bug Reports

[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.

[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]

No that's fine.

[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]

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

[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.

[Leanne]

Thanks SidFeyDesigns! Bookmarked!

[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]

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.

[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.

[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.

[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]

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

[delcorsets]

oliverands

The order remains perpetually in Partially Shipped status, and I don't see a way to manually change the status to Shipped.

We've been sporadically experiencing a similar but not quite identical issue. We use ShipStation for order fulfillment and occasionally all products will be shipped, a tracking number and cost will imported, but the order status in Miva perpetually remains as Pending. We've noticed that there is a specific kit product in the order when this happens. I've only been able to isolate 4 orders so far where this is this case, so it could definitely be a different root cause, but so far, in the orders where I've been alerted to the problem the kit is in each of them.

[oliverands]

I've just noticed something odd that may be a bug--or at least it doesn't work like I would think it should.

I sell both physical and digital products in my store. When I have an order that contains only digital products, Miva automatically sets the order to Shipped status. If an order contains only physical products, I import a CSV with shipping information, and Miva automatically sets those orders to Shipped status and saves the carrier, tracking number, and cost to the order.

But the behavior is different when an order contains both physical and digital products. For these orders Miva initially sets the order to Partially Shipped status. I can import the shipment information on the physical products, and it will save to those products in the order. But Miva does not then update the order to Shipped status--even though all items have now shipped. The order remains perpetually in Partially Shipped status, and I don't see a way to manually change the status to Shipped.

UPDATE: I just had to manually add tracking information to an order with mixed products. When I manually added this to the physical product in the order, Miva updated the status to Shipped. So it appears that it's likely only when importing a CSV with shipment information that this happens.