October 2, 2018 at 7:37 am #4622vorticismParticipant
The deposit is currently failing.
The address is displayed normally. There seems to be no problem with api key.
Sent Successfully: No ‘is displayed on the deposit transaction of the IPN history.
(IPN Date: status_text = ‘Deposit confirmed’)
All deposit transactions are failing.
Coinpayment balance is recognized in the balance. However, the balance does not increase for plugin users.
withdraw works.October 2, 2018 at 8:21 am #4625
OK, this is definitely due to the IPN messages failing. Have you checked Wordfence? Any new plugins/servers/firewalls, etc?October 8, 2018 at 5:00 am #4732
I have same issue – user has deposited coins to its generated adress with us – transaction history shows the deposit on coinpayments – the coins are added to our main wallet ( can be showed in the cold storage (online wallet balance) – but the user newer receives it in their account.
I have wordfence installed and working smoothly – have installed a couple plugins that is not related to your plugin – ( i installed flamingo and contactform 7)
Please advise – wallet shows ZERO for user.
kind regardsOctober 8, 2018 at 8:50 am #4739
@jzntech Hello, this is the most common problem people face at first when installing the CoinPayments adapter. Most likely some firewall is blocking your incoming IPN notifications.
1. Have you checked the troubleshooting section, under “Deposits come through to the CoinPayments platform but do not show up in the plugin.”?
2. Also, are you encountering this problem on a new installation, or did deposits work before?
Please let me know
with regardsOctober 8, 2018 at 10:23 am #4741
Deposits worked up until 1 oct…. the changes i made was to install exchange plugin, wordfence ( now deactivated to test ) …
Have gone through Defender pro wpmudev plugin (deactivated for test) – allowed all connections from coinpayments on firewall —
and still no deposits are showed up on wallets (showed in cold storage on coinpayments tough) ….
checked ipn´s – they are retried and refused –
Im stuck on where to trouble shoot – all connections are on allowed … have entered credentials 2 times now – lowered http chache to 60 sec instead of 180…
Would be grateful for fast help…October 8, 2018 at 11:32 am #4742
The first step to debug this would be to log on to coinpayments.net and go to IPN history.
See if the messages are delivered. They are probably not being delivered.
Click on the date/time of a failed IPN message and see the details. There should be some information there as to why the messages are not being delivered.
Besides wordfence, there can be other reasons why the incoming messages are not reaching your site. Possibly some firewall.
Please let me know what you found in your IPN message history.
with regardsOctober 8, 2018 at 12:03 pm #4743
check pdf file ….
Attachments:You must be logged in to view attached files.October 8, 2018 at 12:07 pm #4745
Thank you for showing me the details. This is definitely some firewall.
Remember there can be several firewalls in place, and your hosting provider might know something more about this.
Ultimately you must find out why https requests to that URI are not passing through.
best of luckOctober 8, 2018 at 2:27 pm #4751
DOing troubleshooting now with hosting .-… same issue…October 8, 2018 at 2:44 pm #4752
i get a error now where the public keys are
Last IPN error:
IPN Mode is not HMAC
Local time of last error:
??October 8, 2018 at 3:06 pm #4753
Do you know what ip coinpayments is using to send their call to the script ? .. so we can identify the ip in the firewall logs ?October 8, 2018 at 3:37 pm #4754
The error ‘IPN Mode is not HMAC’ would show if you attempt to visit the IPN URL from your browser. This is normal. The IPN URL should be accessed from the CoinPayments platform and the request should signed with a signature to verify authenticity.
IPN requests usually come from
220.127.116.11.October 8, 2018 at 5:49 pm #4755
definitely a error on just that site..
Tried same plugins on different site on same server different api keys … no error ….
Tried same fresh api keys on old site (with error) … same error – “though shall not pass” kind of style 😉 ….
conclusion… not firewall issue (becuase working site is on same account and same server ) … have to search within the plugins then…October 8, 2018 at 6:30 pm #4757
All security plugins deactivated . – no firewall – reduced all plugins besides wallet …
Still same issue …
No way to troubleshoot the IPN history either besides the history that dosent” say to much . – what ip adress is it coming from – what adress is it going to ..(https://superdomainname.com?wallets-cp-ipn=1)
This is annoying … dont want to reinstall the plugins…
Any ideas ? .. can we hire someone who is more knowledgeable than us on this matter ? … spent a couple days now on trouble shooting… all other dashed plugins deactivated… no wordfence or no security …
Kind regards..October 9, 2018 at 6:29 am #4759
This looks like it is a matter of networking if IPN messages are not being delivered.
I would start by thinking what is different on those other sites where deposits work:
1. Are you using a different CoinPayments account? Then it could be something to do with the account settings. If you follow this guide then everything should be in order. Make sure to not specify a custom IPN URL.
2. Do you have a different web server config? Since you mention that other sites on the same server work, I would also compare the web server config of those other sites with the one that causes problems. Perhaps it is due to some rewrite rule. Do you see the incoming IPN in your server’s access log or error log? There could be indications towards the problem there.
Unfortunately I am not available for hire, as explained in the FAQ. Also, it is likely that the problem is not within WordPress or its plugins, so I wouldn’t be able to help you anyway. This is probably due to some server configuration.
Ultimately there is an incoming connection to your server. It either stops at your hosts firewalls, or your server’s firewall, or it reaches your web server, in which case it is stopped by your rewrite rules, or it is stopped at WordPress. There are logs for all of these layers. I would recommend that you start from the first one and determine at which point the message stops.
- You must be logged in to reply to this topic.