<p>I wrote a very basic webshop using Armory that does a lot of what you're talking about, though in Flask:</p>

<p><a href="https://github.com/goatpig/BitcoinArmory/blob/master/webshop/server.py" rel="nofollow noreferrer">https://github.com/goatpig/BitcoinArmory/blob/master/webshop/server.py</a></p>

<p>The sensible way to go about doing this would be to run your own bitcoin node so you can be notified whenever payment is sent to the address. You can, of course, use an SPV server (like an Electrum server) or even a public block explorer (blockchain.info, blockcypher) to get notified of payment to an address, but then you start risking customer (and your) privacy.</p>

<p>As long as the private key(s) are held offline, there's no actual risk of losing bitcoins. The big risks are from a privacy perspective and the way to combat that is to run your own node so you don't leak information.</p>

CC BY-SA 3.0
2016-11-21T18:24:10.493Z
2016-11-21T18:24:10.493Z
Jimmy Song
<blockquote>
  <p>Is this a sensible secure way of going about this?</p>
</blockquote>

<p>I think so.</p>

<blockquote>
  <p>What are the potential risks?</p>
</blockquote>

<ul>
<li>Blockonomics could give you an incorrect balance, either accidentally or intentionally.</li>
<li>If you give them your extended public key to generate addresses, then giving them any private key from that extended key is the same as giving them the master private key to that extended public key. Solution: Don't give them any of your private keys.</li>
</ul>

CC BY-SA 3.0
2016-11-21T06:56:27.513Z
2016-11-21T06:56:27.513Z
Nick ODell
<p>i was thinking of using a service like blockonomics linked to an offline store via Xpub.
When a user signals their intent to make a payment, the app would generate a new address (API call), display it, set a timer for blocking the address, then use its HTTP callback to wait for Confirmed before updating the user balance. Without knowing the TX id I would poll the address and see whether the amount had been received since the timer started.
All payments go to a single cold address pool.</p>

<p>Is this a sensible secure way of going about this? What are the potential risks?</p>

<blockchain><ecommerce>
Accepting cryptocurrency in Django app
Alicelovesbob
# Accepting cryptocurrency in Django app

(Asked by: username_0 on 2016-11-21)

i was thinking of using a service like blockonomics linked to an offline store via Xpub.
When a user signals their intent to make a payment, the app would generate a new address (API call), display it, set a timer for blocking the address, then use its HTTP callback to wait for Confirmed before updating the user balance. Without knowing the TX id I would poll the address and see whether the amount had been received since the timer started.
All payments go to a single cold address pool.

Is this a sensible secure way of going about this? What are the potential risks?

**Tags:** blockchain, ecommerce


---

## 2 answers

### Answer by username_1 on 2016-11-21. Score: 2

I wrote a very basic webshop using Armory that does a lot of what you're talking about, though in Flask:

<https://github.com/goatpig/BitcoinArmory/blob/master/webshop/server.py>

The sensible way to go about doing this would be to run your own bitcoin node so you can be notified whenever payment is sent to the address. You can, of course, use an SPV server (like an Electrum server) or even a public block explorer (blockchain.info, blockcypher) to get notified of payment to an address, but then you start risking customer (and your) privacy.

As long as the private key(s) are held offline, there's no actual risk of losing bitcoins. The big risks are from a privacy perspective and the way to combat that is to run your own node so you don't leak information.


---

### Answer by username_2 on 2016-11-21. Score: 0

> Is this a sensible secure way of going about this?

I think so.

> What are the potential risks?

* Blockonomics could give you an incorrect balance, either accidentally or intentionally.
* If you give them your extended public key to generate addresses, then giving them any private key from that extended key is the same as giving them the master private key to that extended public key. Solution: Don't give them any of your private keys.


---

