New unique payment address for payment

Looking at integrating algorand into a payment system. However am unclear what’s the ideal flow to be used to achieve the following:

  1. New payment address per transaction regardless whether the payment is completed
  2. Payment under a similar merchant is derived under the same key
  3. Opt-in of ASA (USDT / USDC) issue if constantly generating new address (doesn’t seem elegant since fee is incurred regardless whether a payment is made)

Seems like having a unique address per merchant is the best trade-off imo? Who paid the merchant has to be dealt with under memo?

Would be great to know if my understanding is correct.

Hi @Tony

If you want to avoid users generating and managing N different public/secret key pairs for N merchants one thing you can do is having a 2 out of 3 MultiSig account, in which 2 keys belong to the user (always the same, avoiding key management complexity) and the 3rd belongs to the merchant but has no authority (it is just used as placeholder to have a unique user:merchant mapping, saving the user form handling large number of keys).

In this way the user can interact with N merchant with the same 2 keys.

Thanks @cusma

The scenario I’m looking at is slightly different from what you’re describing. Let me list out the best approach I can think of:

User perspective

  1. User enters payment page
  2. See a QR code to pay with
  3. Makes payment (with memo)
  4. Transaction confirmed

Payment gateway perspective

  1. Payment gateway has a single multisig key
  2. It generates fixed address for each merchant based on nonce / id
  3. During payment, it detects if a transaction is made with specified memo
  4. Matches on DB based on created payment on payment gateway & transaction memo
  5. If matched, transaction completed

The above seems workable but not sure if it is the ideal way to do it.

We only manages merchant’s address and take payment. Thus there’s nothing to manage on the user’s end.

  • Thank for the reply btw. Appreciate it.