[alexg]

Hello,

I believe what is happening is this: You generated a deposit address while you had entered an IPN URL. This didn’t work because the IPN URL, if present, should end with ?wallets-cp-ipn=1 . Then I told you to remove the IPN URL but the deposit address you had generated still had a faulty IPN. When you uninstall the plugin, the tables are not being deleted. This is done for safety. So the old deposit address remains. You could try to empty the addresses table. This will force the plugin to regenerate new deposit addresses. You can do this with the following SQL query:

TRUNCATE wp_wallets_adds;

making sure to replace wp_ with whatever your table prefix is. Then, try a new deposit to that address. If you want to test with LTCT, you can use this faucet to send testnet Litecoins: http://testnet.litecointools.com/

Try this and wait a few minutes. The deposit should work.

If not, we will need to look at the following:

1. Does the [wallets_deposit] shortcode show you deposit addresses?

2. Are there IPN attempts in your IPN history?

3. If there are IPNs what is their status? The CoinPayments platform lets you view whether an IPN message was received or not.

4. Are there any errors in your logs? Instructions for enabling the logs are here: https://codex.wordpress.org/Debugging_in_WordPress

Apologies, but I only offer support over email and the forums. This is also mentioned in the terms of service. There are good reasons for this. I do try to reply as quickly as possible whenever I am not sleeping or away from work.

Give this a try and let me know. Hopefully it will work now, but if not, please answer the above questions so we can find out what’s wrong.

kind regards

[alexg]

I have not yet found the reason why the plugin did not work to begin with.

The SQL I sent you was exported from my machine. Most of the collation and charset directives are not needed. Only the ones that refer to the latin1 charset. You should be OK with MySQL 5.5. I have edited the SQL code and removed any unnecessary charsets. Your system should now use whatever is default for the columns where it doesn’t matter.

So please do another attempt. Use the same pastebin link. I have edited it.

[alexg]

Additionally, try leaving empty the IPN URL altogether. There is no need to specify this as it is being set by the plugin on each callback address. The full IPN URL constructed by the plugin is something like http://example.com/?wallets-cp-ipn=1 but you do not need to worry about this.

[alexg]

Thanks, I didn’t know about this. I had never tried IPN with IP addresses instead of domain names.

To clear up any confusion:

Every time you send cryptocurrencies to a deposit address, CoinPayments will do an HTTP request to your site. We need to know 1) if it is being sent and 2) if it is being received. The “IPN history” page allows you to see both of these things. The screenshots you sent earlier indicated that no messages were being attempted. Probably due to the missing trailing slash.

At the very least you should now be seeing IPN attempts on CoinPayments, even if the messages do not arrive at your site.

Let me know how it goes.

regards
Alex

[alexg]

Hello,

A few people have reported this issue in the last couple of days but I was unable to reproduce the problem in a number of setups.

Is it possible for you to enable logs and send me whatever gets written out while you activate the plugin? Instructions for enabling logs are here: https://codex.wordpress.org/Debugging_in_WordPress This will help me know what’s wrong and what to fix.

Alternatively you can use the following SQL code in your console, to create the tables manually.

https://pastebin.com/huhbVPDT

The above code assumes that your DB prefix is wp_. If it is something else, you will need to replace the table names.

[alexg]

OK, first things first.

I only mentioned the csv export because I thought you wanted to migrate an existing transaction from one machine to another. If you have not performed any successful transaction yet, just ignore the export/import thing.

Also, if your IPN history is empty, that means that the CoinPayments platform never attempted to notify the plugin of any deposits. Could it be that you have not setup IPN correctly? Please confirm that you have followed the installation instructions on https://www.dashed-slug.net/bitcoin-altcoin-wallets-wordpress-plugin/coinpayments-adapter-extension/ and in particular the part where you create an IPN secret and set in the coin adapter settings.

[alexg]

If you have transferred the entire database contents then yes the transaction should show up. If you only did an export via the WordPress admin, that would not have transferred the transactions and addresses tables. The tables are normally named wp_wallets_adds and wp_wallets_txs.

You can also use the plugin to export the transactions to a csv file and reimport them to the new installation: To transfer the transactions, go to Wallets -> Adapters and choose the “export transactions to .cvs” next to each coin whose transactions you want to transfer. You can then go to the new installation to Wallets -> Transactions and at the end of the page, import the csv file. That should transfer your transactions.

As for IPN history, since you were running the plugin locally, there should be failed attempts listed in your history when you log in to coinpayments. But now that you are running the plugin on a server the IPN requests should succeed.

[alexg]

Hello,

Could it be that you are running WordPress on a machine in your local network?

Deposit notifications come to your WordPress from the CoinPayments platform via their IPN mechanism. This is HTTP/HTTPS requests coming from CoinPayments. If your installation is not facing the outside world you will either have to install on a VPS or otherwise set up your firewall to forward these requests.

Check your IPN history in CoinPayments and see if the notifications succeed.

let me know

regards,
Alex

[alexg]

This is now out, see https://www.dashed-slug.net/exchange-rates-yobit-cryptopia-bitcoin-altcoin-wallets-wordpress/

[alexg]

Hello,

In the next release of bitcoin and altcoin wallets, 2.8.0 there will be a possibility to also use exchange rates from yobit or cryptopia. This will be out tomorrow.

regards,
Alex

[alexg]

Thanks for providing all of this information.

The screenshots from the CoinPayments account are irrelevant. You wouldn’t expect to see anything there.

I see that communication with the API works (adapter status is responding). You mentioned that the issue was with internal transfers being stuck in the unaccepted state. This is an internal operation that should only affect the database.

I’m afraid that due to your setup being unusual, you have an unusual issue. I will have to ask you to insert some debug logs into the code. That’s the fastest way to debug this and move forward.

As I mentioned earlier, the code that should be transitioning your transactions from unconfirmed to pending is in includes/confirmations.php, in function confirm_transactions(). You could start by adding a debug log in that function, then check your logs to see if it executes. Add the following:

error_log( __FUNCTION__ );

and you should see the name of the function in your logfile. Make sure that logging is enabled in your wp-config.php first.

Also, if that function runs and fails it will print out “failed to update unconfirmed moves between users.” Look for that in your logs too. As well as any other suspicious errors.

Let me know what you find. This shouldn’t be hard to debug.

[alexg]

Before attempting anything else, update to the latest patch version, 0.4.1-beta.

[alexg]

Normally no, you shouldn’t do anything to make sure cron works. In fact the plugin will warn you if it doesn’t.

The WordPress cron mechanism is not exact – it executes pending actions on the next page refresh. Some people choose to force WordPress cron to execute more regularly by triggering a curl request on the site, but this is rarely necessary. You can read about it here https://developer.wordpress.org/plugins/cron/hooking-into-the-system-task-scheduler/

Have you been able to determine if there are errors in the logs and if wp_mail works on your system?

If you don’t find anything in the logs you could insert some error_logs into the confirm_transactions() function to see if it runs, what it does, and if it fails at some point. Normally it is the one that should be changing your transaction status from unaccepted to pending.

[alexg]

Hello,

I see that you are frustrated with the plugin, bust rest assured that the functionality you are trying to achieve is being used every day. This is probably some system configuration issue that we can figure out and fix.

The screenshot you show me indicates that the transaction remains in an unconfirmed state even though you have provided the necessary admin & user confirmations. I cannot imagine why this happens to you, but the answer should be in the WordPress logs or your MySQL log.

Normally the cron job discovers unconfirmed transactions that have the necessary confirmations and changes them to a pending state. pending transactions are eligible for execution on the next cron. This is done in includes/confirms.php in function confirm_transactions(). I have again tested this in combination with the new tor extension, even though internal transfers never touch the coin adapter – they only manipulate the local database.

When a transaction is first entered, the user who entered it should be getting an email asking to confirm the transaction. The email is sent using the wp_mail() function. I would start debugging from there, as this is the first deviation from expected behavior. I suggest you do a tail -f /var/log/*.log and see if there is any error while you are entering a new transfer. There could be PHP errors, MySQL errors, or even mailer errors; this should catch them all.

In summary, let me know if you find any errors in the logs. I would start by figuring out if wp_mail() works and then if PHP mail() works. (Also check your spam folder just in case.)

One other thing you could try as a test, is to disable confirmations (Wallets -> Confirms -> Internal transaction confirmations) and uncheck Admin confirmation required and User confirmation required. Then do another move. Does it stay in unconfirmed state again? That should give us some clues as to what went wrong.

Let me know.
regards

[alexg]

Also, note that by default a withdrawal needs admin AND user confirmation. An admin confirmation on its own is not enough to execute the transaction.

[Author]

Posts