In my E-Commerce application, I have to associate each incoming Ethereum payment with my internal order ID in order to distinguish different purchases. In Bitcoin world, I could simply record an address in my database when sending a user to payment page, then use it to pick a that order from my DB when Bitcoin payment will be received & confirmed.

Do I understand right that

  1. I shouldn't use the same approach in Ethereum, because accordingly to that article, I shouldn't expose personal.newAccount to RPC. Also, in that case I will not be able to withdraw all accumulated funds to another address in a single transaction.

  2. If I use an approach described in another article which seems idiomatic for me, I will also have to teach each of my customers how to load my smart contract in his Ethereum client because there is no widely-accepted standard of embedding smart contracts in QR codes and pay URLs?

1 Answer 1


You can certainly give each order a different address. I don't understand the bit about exposing personal.newAccount. I agree you shouldn't do that, but I don't understand how it relates to your question. You can just generate a addresses on the fly, or, for better security, generate them ahead of time offline (so the private keys are not sitting on your servers).

If you do give each order a new address, there is the downside of having to pay a transaction fee for each account to consolidate the funds.

There are a few other options you might want to consider:

  1. Have everyone pay the same address (smart contract), but pass an order ID as a parameter. This is pretty easy for users who are interacting with a website using MetaMask, but this is nontrivial for people who need to pay on mobile or through an exchange. Note that EIP 67 tries to standardize a URL scheme that includes a data field. I don't know what tools support that, but such URLs would make this easy for any user.
  2. Have a fixed number of addresses that get reused, each of which is a smart contract that simply forwards funds to your main account and raises an event. Each order can be associated with one of these addresses, and an address shouldn't be reused until the order is paid for (or canceled).
  3. Have everyone pay the same address and encode the order number into the amount. E.g., for an item that costs 0.01 ether (10000000000000000 wei), order number 123 pays 10000000000000123. The extra cost (123 wei) is insignificant, and it's easy for you as the recipient to track which payment is for which order. (For convenience, you could have a smart contract receiving these payments and emitting events that make the order ID explicit.)
  • > I agree you shouldn't do that, but I don't understand how it relates to your question. You can just generate a addresses on the fly Do you mean that there is a way to generate a new address apart from personal.newAccount?
    – vdudouyt
    Jan 11, 2018 at 13:38
  • Yes. You just need to generate a random number and then do a little math. No need for a network connection. See npmjs.com/package/ethereumjs-wallet for an example library in JavaScript.
    – user19510
    Jan 11, 2018 at 13:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.