Relay spec assumes 1:1 envelope:transaction

[dbrain]

The relay /pay and /status spec is geared towards singular transactions.

• /pay outputs are expected to be validated on the /pay call and error if something is incorrect there
• /status (or /pay response) is relative to a single transaction

Bullet points so I don't need to form human sentences:

• Given we're working with dogecoin: URIs and have fallbacks for the classic "pay address amount" usage there isn't anything preventing weird payments getting through. A customer may pay 5 DOGE in one transaction from one account and 5 DOGE in another transaction from another account
• Assuming the payment address is the identifier: there's room for things like underpayment/overpayment
• A potential scenario would be customer pays via wallet that does not support dogeconnect, gets told the payment was too low because they accidentally modified the amount/something, goes to pay again via a wallet that does support doge connect and is unable to pay because a tx has already been created

Questions:

• What should we do here? Am I missing something obvious or is this something we should support and be a bit more open to multiple payments?
• I guess another thing: As the person awaiting payment am I also polling /status or am I supposed to be smarter?
• Is address supposed to be the core tx identifier? I guess that forces HD wallets for anyone wanting to accept payments?

Probably all a bit edge casey, but it's an edge casey world.

[dbrain]

@SomeoneWeird @raffecat - FYI

[raffecat]

Assuming the payment address is the identifier: there's room for things like underpayment/overpayment

Yeah Gigawallet handled both of these cases, telling you that an invoice is currently paid/underpaid/overpaid and letting you make a refund payment for the extra amount. It's a vendor concern to have some way to refund money to customers; it can be a manual process. (We could add a refund button that sends a payment to an address, and adjusts the paid total maybe?)

goes to pay again via a wallet that does support doge connect and is unable to pay because a tx has already been created

Hm, that's an edge of an edge case.. yeah idk what we do here, maybe they can manually make another payment to the fallback address (we can make this flow nicer later, if it's really worth it?)

It's worse.. even if someone pays via dogeconnect, they can always still send extra money to the fallback address for fun.
(This case is kind of buyer beware, it's like depositing money randomly into a vendor's bank account for no reason.)

A customer would typically contact the vendor directly in cases like this to sort it out; the real world is messy and things happen.

As our own Vendor Relay:

• We can use a single HD address for both dogeconnect and fallback address. We could be nice and keep adding up payments received until >= the invoice amount. Yeah there's a chance of overpayment. We could just bump up the amount received in the vender app. (They can refund it themselves.) If they make a dogeconnect payment, most of these cases won't come up.
• The /status API is meant for the buyer, we had web clients and hardware wallets in mind as well (no access to blockchain.) The dogeconnect spec only covers the payment interaction, between buyer's wallet and vendor's Relay (gateway). It doesn't cover how the vendor talks to their Relay, that's up to the Relay Provider, or Vendor themselves if they run their own (our case.) In other words, we can do what we like behind the scenes on the vendor side.
• Yeah the address can be considered the Invoice ID that needs to be paid, this design fell out of Gigawallet. The problem is with the fallback address: you're receiving money out of thin air, so you need to use a unique address to know which invoice is being paid.

As the customer's wallet:

• You scan the QR code and choose between dogeconnect if you support it, or classic pay to address.
• If you use dogeconnect you get to see what you're buying etc, but your tx must conform to requirements. You can also request the status of that Payment (e.g. Invoice) at any time, or just watch the blockchain for the txid in a block. (We return the txid, but the wallet makes the signed tx, so they can calculate it themselves, it's just a double-sha256 hash.)
• If you don't use dogeconnect, you're just sending money to a random address. You transmit the tx to the blockchain yourself, and track it yourself like any other outgoing payment.

[raffecat]

Oh eyah, what does our wallet do if it gets a dogeconnect payment which has two addresses, but there's only a single fallback address? Easy, it makes a dogeconnect payment.

[raffecat]

Because we support our own standards.