Accept Bitcoin easily and save the blockchain. Use Inputs.io

[🏰 TradeFortress 🏰]

It takes 30 seconds to register for an Inputs.io account. It takes about 5 minutes to start accepting Bitcoin.

Assuming you have an average LAMP (linux apache mysql php) website, with a MySQL database of users and their balances, this script will work for you - name it callback.php and set the full path as your callback:

$mysqli = new mysqli("localhost", "user", "password", "databasename");
$apikey = "my_api_key";
$pin = "1234";
if($_SERVER["REMOTE_ADDR"] == "50.116.37.202"){
   if(isset($_GET["note"])){
      $note = $mysqli->real_escape_string($_GET["note"]);
      $amount = $mysqli->real_escape_string($_GET["amount"]);
      $userExistsQ = $mysqli->query("SELECT COUNT(*) FROM users WHERE username='$note'");
      if($userExistsQ->fetch_row()[0] === "0"){
         // user does not exist. send the coins back
         $sendBackTo = urlencode($_GET["from"]);
         $returnNote = urlencode("Error: Username not found. Please include exactly your username in the notes field.");
         $url = "https://inputs.io/api?key=$apikey&action=send&address=$sendBackTo&amount={$_GET['amount']}&note=$returnNote&pin=$pin";
         if(substr($note, 0, 7) != "Error: "){
            // do not callback error messages
            file_get_contents($url);
         }
      } else {
         $mysqli->query("UPDATE users SET balance=balance+$amount WHERE username='$note'");
      }
      echo "*OK*";
   } else {
      // Someone sent to our Bitcoin address. This shouldn't happen if we don't post it anywhere.
   }
}

For more info, see our API. https://inputs.io/api

Feel free to ask any questions here or to support@inputs.io

[Jaxkr]

It takes 30 seconds to register for an Inputs.io account. It takes about 5 minutes to start accepting Bitcoin.

Assuming you have an average LAMP (linux apache mysql php) website, with a MySQL database of users and their balances, this script will work for you - name it callback.php and set the full path as your callback:

$mysqli = new mysqli("localhost", "user", "password", "databasename");
$apikey = "my_api_key";
$pin = "1234";
if($_SERVER["REMOTE_ADDR"] == "50.116.37.202"){
   if(isset($_GET["note"])){
      $note = $mysqli->real_escape_string($_GET["note"]);
      $amount = $mysqli->real_escape_string($_GET["amount"]);
      $userExistsQ = $mysqli->query("SELECT COUNT(*) FROM users WHERE username='$note'");
      if($userExistsQ->fetch_row()[0] === "0"){
         // user does not exist. send the coins back
         $sendBackTo = urlencode($_GET["from"]);
         $returnNote = urlencode("Error: Username not found. Please include exactly your username in the notes field.");
         $url = "https://inputs.io/api?key=$apikey&action=send&address=$sendBackTo&amount={$_GET['amount']}&note=$returnNote&pin=$pin";
         if(substr($note, 0, 7) != "Error: "){
            // do not callback error messages
            file_get_contents($url);
         }
      } else {
         $mysqli->query("UPDATE users SET balance=balance+$amount WHERE username='$note'");
      }
   } else {
      // Someone sent to our Bitcoin address. This shouldn't happen if we don't post it anywhere.
   }
}

For more info, see our API. https://inputs.io/api

Feel free to ask any questions here or to support@inputs.io

What safety features are in place to unsure you don't steal money? Client side crypto or something else.

[🏰 TradeFortress 🏰]

All APIs have access to your private key - including Blockchain.info

[lexxus]

All APIs have access to your private key - including Blockchain.info

That doesn't mean it should stay like this forever, right?

[K1773R]

haha, look at this:

Code:

$returnNote = urlencode("Error: Username not found. Please include exactly your username in the notes field.");

there is alot to encode! typicall do magic developers 

[🏰 TradeFortress 🏰]

haha, look at this:

Code:

$returnNote = urlencode("Error: Username not found. Please include exactly your username in the notes field.");

there is alot to encode! typicall do magic developers 

This takes less than milliseconds.

[joele]

Do members have a copy of the private key?

[Mooshire]

Do members have a copy of the private key?

No.

[joele]

Do members have a copy of the private key?

No.

What if site goes down then our bitcoin is inaccessible at the same time.

[Mooshire]

Do members have a copy of the private key?

No.

What if site goes down then our bitcoin is inaccessible at the same time.

That's the risk you take.

[🏰 TradeFortress 🏰]

You can minimize this risk by simply automatically sweeping your coins to your own address.

[BitPirate]

Bloody hell, finding this on someone's server would be a goldmine!

So sending coins away is as simple as one GET request? The wrong people will be drooling over this.

Unless I'm misunderstanding something, I strongly recommend you forget about advising people to automatically return funds to non-existent users, and strip all that stuff out. Read-access to a server shouldn't result in this kind of compromise.

[🏰 TradeFortress 🏰]

Bloody hell, finding this on someone's server would be a goldmine!

So sending coins away is as simple as one GET request? The wrong people will be drooling over this.

Unless I'm misunderstanding something, I strongly recommend you forget about advising people to automatically return funds to non-existent users, and strip all that stuff out. Read-access to a server shouldn't result in this kind of compromise.

Just like how sending coins away is just as simple as a JSON-RPC request..

Read-access to a server does give you wallet.dat

[BitPirate]

Bloody hell, finding this on someone's server would be a goldmine!

So sending coins away is as simple as one GET request? The wrong people will be drooling over this.

Unless I'm misunderstanding something, I strongly recommend you forget about advising people to automatically return funds to non-existent users, and strip all that stuff out. Read-access to a server shouldn't result in this kind of compromise.

Just like how sending coins away is just as simple as a JSON-RPC request..

Read-access to a server does give you wallet.dat

Not on any server I would be doing business with!

Sending coins out should only be initiated by a trusted user. That might come at the expense of easy automation, but said automation comes at the expense of losing all your coins.

If that API key and PIN are the only things needed to spirit away coins, they have no business sitting together in a file -- conveniently next to the URL for making it happen. They belong in someone's head.

If you want to automate, you can use a hot wallet, but it looks like this wallet will be receiving coins directly from customers?

EDIT: Sorry for coming across a bit harsh, I don't mean to be a dick -- but as you say, this is intended for the "average lamp" website. Such sites normally have a massive attack surface -- they can't also contain the customer's "crown jewels", which is what this script is. :-)

[Jaxkr]

Bloody hell, finding this on someone's server would be a goldmine!

So sending coins away is as simple as one GET request? The wrong people will be drooling over this.

Unless I'm misunderstanding something, I strongly recommend you forget about advising people to automatically return funds to non-existent users, and strip all that stuff out. Read-access to a server shouldn't result in this kind of compromise.

Just like how sending coins away is just as simple as a JSON-RPC request..

Read-access to a server does give you wallet.dat

Not if the wallet.dat is encrypted.
Using inputs.io is no where near as secure as an encrypted bitcoind instance over RPC.

[super3]

Bloody hell, finding this on someone's server would be a goldmine!

So sending coins away is as simple as one GET request? The wrong people will be drooling over this.

Unless I'm misunderstanding something, I strongly recommend you forget about advising people to automatically return funds to non-existent users, and strip all that stuff out. Read-access to a server shouldn't result in this kind of compromise.

Just like how sending coins away is just as simple as a JSON-RPC request..

Read-access to a server does give you wallet.dat

Not if the wallet.dat is encrypted.
Using inputs.io is no where near as secure as an encrypted bitcoind instance over RPC.

Is there a service that offers bitcoind instances on a VPS? Might be something to look into.

[🏰 TradeFortress 🏰]

Bloody hell, finding this on someone's server would be a goldmine!

So sending coins away is as simple as one GET request? The wrong people will be drooling over this.

Unless I'm misunderstanding something, I strongly recommend you forget about advising people to automatically return funds to non-existent users, and strip all that stuff out. Read-access to a server shouldn't result in this kind of compromise.

Just like how sending coins away is just as simple as a JSON-RPC request..

Read-access to a server does give you wallet.dat

Not if the wallet.dat is encrypted.
Using inputs.io is no where near as secure as an encrypted bitcoind instance over RPC.

Where is the password stored in? On the same server? Back to where you started.

On a different server? How do you get the password from the different server? Using automated functions on the same server? Back to where you started.

[Mooshire]

osnap

[BitPirate]

Bloody hell, finding this on someone's server would be a goldmine!

So sending coins away is as simple as one GET request? The wrong people will be drooling over this.

Unless I'm misunderstanding something, I strongly recommend you forget about advising people to automatically return funds to non-existent users, and strip all that stuff out. Read-access to a server shouldn't result in this kind of compromise.

Just like how sending coins away is just as simple as a JSON-RPC request..

Read-access to a server does give you wallet.dat

Not if the wallet.dat is encrypted.
Using inputs.io is no where near as secure as an encrypted bitcoind instance over RPC.

Where is the password stored in? On the same server? Back to where you started.

On a different server? How do you get the password from the different server? Using automated functions on the same server? Back to where you started.

So, you do understand the problem then! That password should never be stored on the client server, unless they are willing to take the risk to lose those BTC. Perhaps, at a stretch, they could store it in a TPM on a dedicated server. We expect tight security for CC payments, why accept anything less for Bitcoin?

I don't think this can be understated: Merchants must not store something on their server that would allow their customer's bitcoins to be trivially stolen. This is a web server we're talking about, not a vault. The server probably has a bunch of other (insecure) sites hosted on it. haven't we learned anything from all the Bitcoin hacks? e-commerce providers should be aspiring to higher security than this.

I looked at your other posts, you seem to know your stuff -- so you know that you should be promoting layers of security -- inbound customer coins should go to a cold wallet, and concerns should be separated -- give each process the minimum required permission it needs to perform it's job, and don't let it exceed those bounds. A coin receiver callback does not need to know how to send coins.

EDIT: Oh... and you missed the "OK" in the above script.
EDIT2: And you should really do $userExistsQ->free()

[domob]

EDIT2: And you should really do $userExistsQ->free()

Funnily, this is something I see very, very frequently in PHP code written by others.  I'm not sure whether it is just lazyness or caused by lots (?) of PHP programmers who didn't ever use a non-garbage-collected language where free'ing memory is inherent to the language much more than in PHP.