I am writing an online store able to accept XMR payments. I know there are some existing solutions to do so, but this project is self-educational rather than commercial. Serverside, I run a monerod full node and a monero-wallet-rpc on top of it, to which store's json-rpc client is able to communicate. So far I learned how to manage accounts, wallets and addresses and how to see incoming payments using "incoming_transfers" rpc call. Had to say that the official wallet rpc documentation on getmonero.org is extremely confusing. For instance, a lot of methods require payment ID value as input but none mention where to get it, or rather which of the numerous transfers/payments/whatever hashes/keys/whatevers is ought to be used for it. Anyway, I can see the incoming transfers but I can not see a way to specify which shop item each transfer was made for. I assume the workflow of an online store include the client reviewing the catalog of items, picking some, clicking checkout and be presented with QR code or "monero:" payment URI to make actual payment. But how would store's backend know what item the client had picked to deliver it? There must be a way to embed an arbitrary item ID into the QR or URI so it is then seen in the incoming transactions. Any clues?
1 Answer
There are several different ways to accomplish merchant needs, which one use is up to you.
Payment ID's are just any 8 bytes. You can assign whatever 8 bytes you wish to each product/shop/user then generate an integrated address and resulting QR code for each. Then use get_payments/get_bulk_payments to filter/track.
You could even get smarter and automatically generating payment IDs (and QR codes) based on a combination of customer ID and product ID (i.e. 4 bytes for a customer ID and 4 bytes for product ID), thats two 4 byte integers. Use make_integrated_address to create them in advance or on the fly with random 8 bytes and pair those to an order table row in your orders database.
Then of course there are subaddresses (thus making use of incoming_transfers to track), you could create/assign those by customer/shop/product. These can also be created in advance or on the fly (using create_address).
All the tools are there, just there's no single right or wrong way to organize things, that part is up to you. Research the different approaches and pick one that works best for you.
