|
Akseli Olavi Ahopelto
|
February 3, 2016 at 4:48 am
Hello,
We migrated our whole WP installation with EE4.8.32p to a new VM on Azure last night, but obviously maintaining the same domain.
I dumped the MySQL database from the old server and imported it into the new one, along with cloning our full WP installation from our Git repository.
Now, it seems that something has gone horribly wrong. We rely on constant payments through RedSys (a third-party payment provider) using their plugin for EventEspresso.
Everything worked fine on the old server, but after the migration payments have stopped processing correctly.
The payment is sent to the provider in the correct amount, the payment is accepted, but when we are redirected to the Checkout/Confirmation page, EventEspresso notifies us that we are “Pending Payment”.
If we look up the registration in the admin dashboard, we get the following:
The payment type under the amount should read Credit/Debit RedSys… but it says in Cash ??
Then, if we head to the transaction details page, we see the correct payment method is registered Credit/Debit… but the Gateway Response is blank.
Finally, if we look at the e-mail that we receieve for Pending Payment it says:
Which has a random price of 22e associated with it that came from nowhere.
If anyone can provide any assistance it would be greatly apprecieted! This is really a very time sensitive matter as we rely on EE to process all our registrations for Trips and Events which the company lives off.
Thank you!
|
|
Akseli Olavi Ahopelto
|
February 3, 2016 at 5:14 am
Just to add some extra info, I also found that looking at the Log in the Payment Methods section, there seems to be something wrong with the Transaction IDs.
The transaction should have a way higher number, but it seems stuck at 170 and isn’t incrementing.
Also, we can see that the payment module is indeed working correctly as it’s receiving the IPN information, but that’s not being processed correcty by EE.
The 170ID that we see is associated to one of our first events which, curiously, had a price of 22E. What could be the cause of this?
|
|
Akseli Olavi Ahopelto
|
February 3, 2016 at 5:37 am
After some more troubleshooting I’ve found that the issue seems to be in the Transaction ID for sure.
If I look at the Payment Methods log, I find that the ID is incrementing correctly, but that the Transaction ID is constantly stuck at 170. It seems like half of the log is suddenly showing 170 as its TransactionID.
|
|
Seth Shoultes
|
February 3, 2016 at 9:56 am
Have you checked to make sure that the Transaction ID column in the new database is set to auto increment?
Also, you might want to try deactivating and reactivating Event Espresso on the new server. That should make Event Espresso check for the correct database tables etc.
|
|
Akseli Olavi Ahopelto
|
February 3, 2016 at 10:24 am
Hey,
I’ve enabled/disabled EE and the settings for the transactions table are the following:
And we are still experiencing the issue. Any other ideas?
|
|
Akseli Olavi Ahopelto
|
February 3, 2016 at 10:36 am
Ok, based on your idea on checking the TXN_ID I ran through a few more tabled an ran into repeated indexes in the REGISTRATION_PAYMENT table.
The PAY_ID is not being incremented when the payment is done through the gateway.
When the payment is applied manually through the administrator dashboard, the number is incremented correctly (thus the few values that are correct between the incorrect ones).
|
|
Lorenzo Orlando Caum
|
February 3, 2016 at 2:35 pm
Hi, you mentioned that this does not happen with manual payments but does when RedSys is in use.
Are you able to duplicate the issue on another payment method (e.g. invoice)?
—
Lorenzo
|
|
Akseli Olavi Ahopelto
|
February 3, 2016 at 3:54 pm
Hello again,
No, the issue is not replicated with other payment types. PayPal Standard, for example, works perfectly like always. I’ve found an error in the Apache error log that repeats itself each time that we attempt to use the payment method:
[Wed Feb 03 22:40:03.447982 2016] [:error] [pid 5690] [client xx.xx.xx.xx:15798] PHP Warning: array_merge(): Argument #2 is not an array in /var/www/bemadrid.com/wp-content/plugins/EE4_Redsys/Redsys/lib/RedsysAPI.php on line 131
[Wed Feb 03 22:40:03.448030 2016] [:error] [pid 5690] [client xx.xx.xx.xx:15798] PHP Warning: array_merge(): Argument #1 is not an array in /var/www/bemadrid.com/wp-content/plugins/EE4_Redsys/Redsys/lib/RedsysAPI.php on line 131
The referenced piece of code reads:
function stringToArray($datosDecod){
if (PHP_VERSION_ID < 50200) {
$this->vars_pay = $this->json_decode4($datosDecod);
} else {
$this->vars_pay = json_decode($datosDecod, true); //(PHP 5 >= 5.2.0)
}
$_REQUEST = array_merge($_REQUEST,$this->vars_pay); // LINE 131
}
So the way I see it, it seems like $_REQUEST and vars_pay arrays are not being filled.
Do you believe that this issue may be causing the DB issue above?
|
|
Josh
|
February 4, 2016 at 8:32 am
I’m not sure, have you contacted Redsys support about this? They will be able to work with you on how to troubleshoot their plugin.
|
|
Akseli Olavi Ahopelto
|
February 4, 2016 at 8:51 am
After lots of troubleshooting the issue is solved.
Turns our that RedSys uses an atypical user-agent string (Java/1.5.0) when it returns the payment confirmation to EventEspresso, and this was being blocked by Azure’s VM Firewall.
There is a similar issue with people running CouldFlair’s services.
— If you’re running Cloud Flair’s Firewall, you have to de-activate ‘Browser Integrity Check’ and things will work.
— If you’re on Azure, the only solution I’ve found has been to remove the VM from ALL Security Groups and use an internal firewall on the machine.
PD. Rummaging through all the code I found that
event-espresso-core-reg/core/business/EE_Transaction_Processor.class.php
has an extra white-line in the middle of a multi-line comment at line 417. Just through you might want to clean that up for the next release.
|
