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

[alexg]

Hi,

My apologies but I do support as well as everything else, as you know this is a one man project.

I saw only the second half of your post due to pagination, so sorry about that.

To answer your question, a few people are already using the plugin successfully.

Regarding the woocommerce extension, you can choose any admin to be the shop “owner” to receive the cryptocurrencies. This can be any administrator account. The expected behavior is that on checkout some amount of a cryptocurrency is transfered to the admin account.

Regarding the transactions that are not confirmed, let me ask you again if you received an email with a confirmation link? You can enable or disable this operation from the “Wallets -> Confirms” admin page. This could be simply that you have not setup emails on your server or it could be anything else. You can also set the plugin to not require User Confirmations in which case the transactions will be executed without it.

Let me know if this answers your questions and also let me know about the confirmation emails

[alexg]

Yes, in fact any coin adapter should work with any app extension.

This is the central idea behind Bitcoin and Altcoin Wallets: To mix-and-match wallets and app features.

[alexg]

Great news, you’re quite right, the API key permissions need to allow a few things, I have made a note to add this to the troubleshooting section.

thanks

Alex

[alexg]

Hello,

If I understand you correctly, communication with the API works in general, but user balances are not updated after depositing? Did you get deposit notifications over email?

Is there a deposit row in your transactions table? What status/confirmations? Can you send me a copy or screenshot in my email?

thanks

[alexg]

Hello,

Can you please be a little bit more specific? What do you mean by “wordpress module”?

The CoinPayments IPN mechanism is not directly related to PayPal IPN. They perform similar function but other than that they are unrelated things.

If I understand you correctly:

1. You first set up the CoinPayments adapter. In the adapters list the status is “responding”.
2. You attempted to display the frontend UI elements, either via shortcodes or via the widgets.
3. You see an error in a message box when you try to view the UIs and the UIs are empty.

Please have a look at the troubleshooting section in the manual, under “I do not see the UI elements in the frontend.”

1. Check that you have added the shortcodes correctly or that you are displaying the widgets in the right widget area.
2. Check that you are logged in.
3. Check that you are logged in as a user with the right capabilities, including has_wallets. The needed capabilities for each UI element are listed in the Shortcodes section of this document.
4. Check that at least one coin adapter is online. Go to Wallets -> Adapters and check the *status* column of each adapter.

If the problem persists after you have checked the above, can you please post the error message that you get?

Thanks

Alex

[alexg]

I did check your site and couldn’t figure anything out just by looking at the frontend.

I do understand that your site is a hidden service. It’s true I did not setup an onion site. The issue here is not how the browser connects to your site, but how your site connects to the other APIs. Just because your site exposes an onion service does not mean it itself uses tor to connect to the other APIs. Your block.io adapter connects to the block.io API over clearnet probably, not Tor. The block.io adapter does not know anything about proxies. Only the CoinPayments adapter connects to its API over tor. I have tested this on my end.

Can you tell me when you go to Wallets -> CoinPayments -> Coin Options, do you see your coins listed?

[Author]

Posts