NANO for ecommerce questions

Hello,

What is the fastest way to integrate NANO as a payment option for an ecommerce of physical goods?

To keep things simple, assume the customer will purchase only one product (no cart feature needed).
So, I assume that payments buttons (i.e. nano addresses) would be the quick and dirty way to implement this.

Appart from collecting the payment, the merchant needs three things:

  1. Collecting the customer name and physical address for the delivery.
  2. Knowing which product the customer purchased, and possibly which product options were selected.
  3. Being notified when the product was purchased and the payment arrived.

1. Collecting the customer name and delivery address
My understanding is that this is left to the ecommerce system, unless the protocol having reserved fields for that.

2. Knowing which product the customer purchased
How do I know which product was purchased?
Is the recommended solution having one NANO public address per product, and --since there is only one public address per wallet-- to create one wallet per product ?
If yes, and if using an offline wallet like NanoVault, how can the creation of the payment addresses be automated fort let's say 1000 products ?

If a product has only one set of price options and the price of each option is unique, the selected option could be deducted from the price paid. But should more complex option selections be stored by the webshop before the transaction or does the NANO protocol allow transmitting some optional value together with the transaction (e.g. product SKU) ?

3. Being notified when the product was purchased
How to be notified when a sale completed and the transaction was done?
I heard about web wallets solutions like Brainblocks.io and Coinbase can offer, but the perspective of a self-hosted solution/integration titillates my curiosity, and I would like to favour NANO's decentralization philosophy as much as possible.
In case of a self-hosted wallet, how to be notified about transactions and typically update a MySQL database. Are there already solutions for that ?

I apologize for these newbie questions. (I feel I should read the whitepaper again.)
Thank you for helping me to better understand how it works.

N.B. I'm not using Prestashop nor WooCommerce, so the plugins developed by Brainblocks.io are useless in my case.

2 Likes

What we do, with bitcoins also, is:

  • User enters checkout page;
  • User Selects Nano;
  • Server requests new address to the wallet server for amount X;
  • Wallet server talks to wallet daemon to generate address and listen to changes;
  • Address is shown to the user;
  • Wallet server then listens for payments, refunds eventual differences and waits for amount X to be on that address;
  • Once the payment is confirmed the wallet server notifies the web server;
  • The server confirms the purchase and changes the order status for the merchant panel;
  • The server then shows confirmation to the user (and usually sends an e-mail too).

This is the flow used in most e-commerces. Of course with bitcoin you can't refund the difference in case the user overpays.
Of course the web server is not always a single server, sometimes you have threads running with websocket connections for the real time updates, and those are considered separate servers.

@sparkcrz

Thank you Spark.
You mentioned the right way to integrate Nano into an e-commerce from a developer point of view
But I believe most people don't have the developper skills, nor the time, to set up such a system.

I'm really looking for the easiest, laziest way to offer NANO as a payment option, considering unique products (think to collectibles for instance), and without worrying about shipping options (as worldwide shipping can be included in price).

So, below I'll attempt providing a KISS (Keep It simple, Stupid) alternative to your procedure.
Think it as if we were using PayPal's payment buttons, or even easier.

  1. User enters checkout page
    

No checkout page, but products purchased directly from their own page.

  1. User Selects Nano
    

A "Pay with Nano" button is shown on the product page.
When clicked, the user is asked to send an email with its nano_ address, delivery_adress, and product reference, to the merchant's email, and the product unique nano_ address is shown. It is also suggested to the buyer to wait a confirmation-email that the merchant is awaiting his payment.
A payment link is directly displayed on the product page (and possibly a QR code).

  1. Server requests new address to the wallet server for amount X;
    

Payment links were generated in advance using a wallet with a NANO wallet, like Nault (or former NanoVault).
Since payment address are disposable (single-use), the merchant will only have to check that the right amount will be sent to the product's nano_ address.
Question 1: Any simple way to generate hundreds of nano_ addresses, since NanoVault and Nault are limited to 20 addresses per wallet?

  1. Wallet server talks to wallet daemon to generate address and listen to changes;
    

See point 3.

  1. Address is shown to the user;
    

Same. (The per product nano_ address is shown on the product page.)

  1. Wallet server then listens for payments, refunds eventual differences and waits for amount X to be on that address;
    

The user checks daily if a payment has been done to one of the products nano_ addresses.
Question 2: should one use nanocrawler.cc for this?
Question 3: any simple way to check many addresses in batch mode?

  1. Once the payment is confirmed the wallet server notifies the web server;
    
  2. The server confirms the purchase and changes the order status for the merchant panel;
    

The merchant checks manually that the payment has been done and unpublishes the product page.
For more security, he sends the funds from the receiving nano_ address to a main address that collects all its sales and then deletes the product's nano_ address.

  1. The server then shows confirmation to the user (and usually sends an e-mail too).
    

The merchant explains in an "How to buy" guide that the buyers's order will be processed within 24 business hours.
After checking for received payment, the seller send an email to the buyer, informing that payment was received and goods are being sent.

Note: in the above KISS procedure, we assume that a double-buy of the same product is very unlikely during a short time frame.

Anything wrong with this KISS procedure?
Suggestions?

Thanks.

Double buy, manual stuff = more work, but for single product marketplaces it should work. If product stock is always 1.