Payment protocol

[rotilho]

Hello,

Recently there were discussions about a payment protocol on Nano Forum however there's a strong position from Nano Foundations to not implement any sort of arbitrary field so any kind of reference id, payment id or description won't be possible at the protocol level.

I honestly agree with their position, especially that the arbitrary field is just important for 2 parties involved in the payment and will have 0 value for them after the payment is finished.

Since the discussion there is not getting anywhere and keep reverting back to the arbitrary field I'd like to bring this discussion here; Natrium is the most used Nano wallet and you guys are also responsible for Kalium and Banano so I think it's the perfect place.

Yesterday I came up with a possible solution to this problem that doesn't rely on the protocol to exchange payment ids and I'd like to hear your opinion on this.

Here's my idea:

1. Website
   1. Create payment id
   2. Generate callback url
   3. Create QR code with callback and payment modes
2. Natrium
   1. Read QR code
   2. User confirm transaction
   3. Generate the transaction
   4. Send the hash to website callback
   5. If website return http 200 publish transaction

QR code: nanopay:nano_xxxxxxx?amount=1&callback=https://yyyyy/payments/payment-123&modes=ONLINE&expires=<timestamp>

Online mode: { "mode": "ONLINE", "hash": "<hash>" }

Offline mode (need to be polished): { "mode": "OFFLINE", "transaction": {<transaction>} }

Multi wallet:

1. Website create QR code with payment options
2. Kalium access link, choose Banano and follow same previous flow

QR code: http://yyyyy/payments/payment-123

Supported currencies:

{
   "currencies":{
      "BANANO":"banpay:ban_xxxxxxx?amount=2&callback=https://yyyyy/payments/bananos/payment-123&modes=ONLINE&expires=<timestamp>",
      "NANO":"nanopay:nano_xxxxxxx?amount=1&callback=https://yyyyy/payments/nanos/payment-123&modes=ONLINE&expires=<timestamp>"
   }
}

Advantages:

1. No one-time-use accounts
2. Totally compatible with current protocol
3. Just 2 transactions: send and receive (instead of 4)
4. Allow creation of private-key-less payment gateways
5. No payment id leakage. Just the parties involved in the payment will know the payment id.

What do you guys think? Is second layer payment something you guys may consider to add to Natrium and Kalium?

[bbedward]

Check #140, I think that would be the direction we go in