Braintree doesn't work on Magento CE 2.1.0 when using table prefixing (HTTP/1.1 400 Bad Request)

[flecxie]

The Magento CE 2.1.0 Braintree module seems to be broken when using table prefixing during installation. When setting up 2 stores (1 without table prefixing and 1 with table prefixing) then payments from the site with table prefixing fail.

Steps to reproduce

1. Install Magento-CE-2.1.0_sample_data-2016-06-23-02-34-56 twice, once with sql table prefixing & once without
2. Create a Braintree Sandbox account & enable Braintree on both sites (make sure you set merchant country)
3. Purchase product on both sites

Expected result

1. Purchase successful on both sites & transaction showing up on Braintree dashboard

Actual result

1. Purchase successful on site which didn't use table prefixing
2. Purchase fails on site which has table prefixing showing error "Unable to place Order. Please try again later." - the browser console also shows [HTTP/1.1 400 Bad Request] upon posting to payment-information
3. Payment from both sites does show up on Braintree dashboard, even the payment which was marked as failed from the site with table prefixing

See screenshot below for error:

[flecxie]

Related to #5714

[pboisvert]

@asemenenko can you have the team check into this one?

[flecxie]

WAR for now is to get rid of table prefixing, to do this in an existing store:

1. Rename all SQL tables
2. Update table references in the sales_sequence_meta table (otherwise all orders will fail)

I used a simple bash script to rename all SQL tables.
To update the tables references in sales_sequence_meta I ran the following SQL:

update sales_sequence_meta set sequence_table = replace(sequence_table,'YOURPREFIX_','');

[YevSent]

Hi @flecxie, please, attach debug and exception log.
Created internal ticket to investigate this issue MAGETWO-56344.
UPD: did you enable Vault for Braintree?

[flecxie]

Sorry, no longer have this environment but should be easy to replicate this issue locally.

Debug.log showed a successful Braintree transaction & the transaction did show up on the Braintree dashboard. Nothing in exception.log, but using Xdebug I could see an exception being triggered...

[flecxie]

Didn't enable Vault

[gabriel-sf]

Just to add a note (since I just fixed it after 3 full days), renaming the tables and removing the table prefix also solved the 400 error for PayFlow Pro.

[romeof1980]

Thanks @flecxie ,
deleting table prefixing fixed the issue for us too (both in 2.0.6 and 2.1.0).
Vault enabled or not didn't make any difference for us, nor did "Authorize" or "Authorize and Capture".

[redline10000]

Hello
I followed the suggestions in the the above post to remove the prefix from my magento database. I then did the table update update sales_sequence_meta set sequence_table = replace(sequence_table,'YOURPREFIX_',''); . However it seems that some tables are still referencing my old prefix mgxa_. When I try to add a new product I get the error

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'datbasename.mgxa_catalogrule_product_cl' doesn't exist, query was: INSERT INTO catalog_product_entity (entity_id, attribute_set_id, type_id, sku, has_options, required_options) VALUES (?, ?, ?, ?, ?, ?)

Any ideas on how to fix my db?

[gabriel-sf]

Hi @redline10000 , check this thread about the process on how to rename the tables.

http://magento.stackexchange.com/questions/103597/how-to-properly-remove-db-table-prefix-in-magento2/103599

[redline10000]

Hi @gabriel-sf

Thank you, the article makes sense but how do I figure out which table is looking for mgxa_catalogrule_product_cl?

[redline10000]

Upon digging deeper into my database it appears that the triggers are still referencing the wrong table names. They all still have mgxa_ in them. But my tables no longer have mgxa_

[gabriel-sf]

@redline10000 to be honest, I removed the prefix of all the tables and then followed those instructions. Sorry I dont have more info. Have you cleared your cache and index?

[redline10000]

Hi @gabriel-sf

I have cleared the cache and indexes. I removed the triggers and everything seems fine now. Yet I am still getting the 400 error when making a braintree payment.

[gabriel-sf]

I would suggest using xdebug to see what errors you are getting and try to debug it from there. There might be a table or something missing.

[romeof1980]

Hi @redline10000,
have you enabled 3D secure in Magento 2 Braintree configuration section?

[redline10000]

@romeof1980 thank you for the suggestion but I ended up just making a new db. My install was a new install and was not really worth all of the effort to fix. Fresh install w/o table prefixes fixed everything.

[romeof1980]

Sounds very good. Personally, when editing dtb and ending with errors, I'd not just delete the cache but I'd also delete and redeploy static content

---- On Fri, 19 Aug 2016 23:00:51 +0200 notifications@github.com wrote ----

@romeof1980 thank you for the suggestion but I ended up just making a new db. My install was a new install and was not really worth all of the effort to fix. Fresh install w/o table prefixes fixed everything.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[davidaddison]

Any ETA on a fix?

[YevSent]

This fix already merged to develop branch ce1160f and will be available in some of 2.1.x releases.

[dyushkin]

Hi @flecxie! Closing the issue, please feel free to reopen if the issue still reproducible for you.

[neilrd]

Is the fix available in 2.1.1?

[YevSent]

This fix will be available in Magento 2.1.3 version.

[neilrd]

I am pretty inexperienced with MySQL. However I have logged into the MySQL monitor via SSH as the root user. What are the exact commands I need to run to solve this problem - please explain step by step.

I copied and pasted this command:

MariaDB [storedB]>

ALTER TABLE sales_invoice_grid ADD base_grand_total decimal(12,4) AFTER grand_total;

but the following error was flagged:

Appreciate any support with this. Apologies for my lack of experience.

Kind Regards

[irfankhan86004]

hi
any one please tell me this issue i solve or not

Or

Give me some hint how can i solve this issue in mangeto2

Because it's argent

[davidaddison]

It worked for me with M2.1 after I reinstalled without prefixing on the database. It was a pain to reinstall and migrate everything around – took about 4 full days that I neither had in my schedule or budget. There are no good tools for migrating M2 data. The whole situation stinks.

But, I look at things for the good - I got more practice installing M2.1. And I got it fixed.

If I could do this project over again I'd think long and hard about using Magento. They've lost almost all of my trust.

[romeof1980]

You don't need to reinstall in order to remove table-prefixing.. Just google around and you'll find a lot of answers. It's a matter of running a SINGLE command and editing a line in env.php
:)

---- On Fri, 23 Sep 2016 20:58:31 +0200 notifications@github.com wrote ----

It worked for me with 2.1 after I reinstalled without prefixing on the database. It was a pain to reinstall and migrate everything around – took about 4 full days that I neither had in my schedule or budget. There are no good tools for migrating M2 data. The whole situation stinks.

But, I look at things for the good - I got more practice installing M2.1. The reinstall had lots of problems.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[davidaddison]

My managed Magento hosting firm (a big one that knows M2.1) did not like romeof1980's solution. They thought it safest to reinstall. I would have liked to do what romeof1980 says.

[romeof1980]

Hi @davidaddison,
good to know...
anyway, we can confirm that it works like charm both with single store mode and in multi store. We've tested it thoroughly and we use more than 20 extensions (tested with 2.1.0 too).
You know, saying you don't like it won't help too much other people that have gotten the same issue.. give more background info (like problem you think could arise) would be great.
Again, we spend just 5 minutes with our multistore in order to fix it: we're in production and it's been working like charm for more than 1 month..
cheers! ;)