search

peakshift / bitcoin-ux

💅💸 Ongoing assessment of bitcoin payments and privacy UX for @BitcoinDesign Community as well as tools to help designers understand the underlying protocols and specifications.
https://bed.money
GNU General Public License v3.0
41 stars 7 forks source link

Problem / Underpaid Invoices #8

Open johnsBeharry opened 3 years ago

johnsBeharry commented 3 years ago

Discussion to @pavlenex write up on problems dealing with merchants.

Accepting bitcoin in a merchant use case doesn't seem so straight forward as giving out a bitcoin address. Thats where the bitcoin merchant invoice comes in.

Scenario: Paying from an exchange leads to underpaid invoice

Oftentimes, the buyer pays an invoice from an exchange. Unfortunately, some exchanges consider that a withdrawal, deducting usually a small fee from the total, without communicating that in the UI. That means that once the payment reaches the merchant, it becomes underpaid.

Majority of payment processors would then notify via the invoice that there’s a due amount. However, even when the user buyer pays, there will again be a deduction and the invoice – underpaid.

On the buyer side they can only solve this by making multiple payments to the invoice (at least 2).

  1. Is it just a buyer facing UX issue or does this pose any problems for the merchant?
  2. How long would invoices remain underpaid?
  3. Can we get some concrete examples? Perhaps interview merchants, or see their support tickets to understand how they deal with it underpaid invoices?

This not only causes frustration on the buyer’s end, but also increases the cost for the merchant. Buyer paying from multiple outputs means that the fee for a merchant who needs to move those funds later will be higher.

pavlenex commented 3 years ago

On the buyer side they can only solve this by making multiple payments to the invoice (at least 2).

On the buyer side, if they pay from an exchange for the second time, the invoice can in that case also remain underpaid. Because exchange would again dedcut the fee from the amount you're sending, which means as a buyer, unless you send more than exchange proposes (enough to cover the fees which vary) you end up in a loop of trying to pay an invoice.

  1. Is it just a buyer facing UX issue or does this pose any problems for the merchant?

This is a big issue for merchants as well. Imagine a buyer bombarding you with transactions, it will cost you way more to move those funds later. In BTCPay we add a protection mechanism for merchant called the network fee, which isn't the same as miner's fee. Check this. This is on by default on the second transaction. So if you underpay an invoice, your second transaction includes due + network fee which protects the merchant. So overall a big issue which increases the cost for everyone.

  1. How long would invoices remain underpaid?

Until it gets paid. If the invoice timer (usually 15 min) expires, and invoice gets paid afterwards, for merchant his invoice is marked paidlate and it's up to them to decide if they want to consider it complete or not.

  1. Can we get some concrete examples? Perhaps interview merchants, or see their support tickets to understand how they deal with it underpaid invoices?

Direct feedback from a merchant dealing with digital items:

We tell people to pay more, or whenever possible offer them a lower gift card based on actual paid amount not really possible for a physical item unless the merchant wants to take a loss

Q do you generate new invoices for them, use payment request, manually tell them to pay via email?

A: we tell them to pay the next invoice address on that specific invoice. I want the payment specifically applied to the invoice so it comes as paid late. It's crucial for accounting purposes.

Eskyee commented 3 years ago

I agree with @pavlenex & bk that paying from exchange is the most common problem here.

because of the added network fee.. which to a end user they now they hear of two fees, ie mining fee, then network fee..

underpaid. overpaid. non SegWit wallet issue, and certain wallets with incorrect fees, can change a dollar.. to 99 cents, so if all these problems can be sorted without the end user having to learn even more stuff on top of what they are learning.. would be a great UX -contact bitcoin wallet devs talk about this problem maybe! for improvements I could put a list of wallets which I find the best, but for now I won't here..

also this has come up quite a few times.. but not so often over the three years in support https://github.com/btcpayserver/btcpayserver-doc/issues/599

some good info has been provided here already https://docs.btcpayserver.org/FAQ/FAQ-Stores/#consider-the-invoice-paid-even-if-the-paid-amount-is-less-than-expected

so I guess the real problem is with wallets and transfer .. I find mempool space to give the best idea of a next bock fee, for bitcoin, many wallets seem to have a big delay with fee estimation .. which results in more fees paid than should be.. or a low fee the takes forever to confirm.. so like waiting for a bus... all you need to know is the timetable, and the fare to pay. the wallet or exchange wallet all need to agree on the same info

I find btcpay hot wallet to be quite great a getting a low fee and fast block times correct quite well.. much better than other wallets I play with for testing out!! the UX is all I care about... their are many wallets I stopped using because of bad UX. etc etc

https://github.com/btcpayserver/btcpayserver/search?q=underpaid+invoice

over all I see 9 issues posted.. https://github.com/btcpayserver/btcpayserver/search?q=underpaid+invoice&type=issues

Eskyee commented 3 years ago

would be nice to maybe talk more about the best wallet UX experience .. in other GitHub issue!! if you guys wanna open it.. I happy to join in the discussion

Eskyee commented 3 years ago

I agree with this

Buyer paying from multiple outputs means that the fee for a merchant who needs to move those funds later will be higher.

Solution: Educating both users and exchanges about the potential setbacks when paying directly from an exchange. Exchanges should communicate more transparently and clearer in their UI if they’re deducting a fee from the total.

johnsBeharry commented 3 years ago

@Eskyee @pavlenex I expect Underpaid Invoices may not be a problem when the invoice is paid via lightning?

Eskyee commented 3 years ago

Correct!! I never seen a underpaid or overpaid invoice via lightning.

pavlenex commented 3 years ago

@johnsBeharry Correct, since the amount is hard-coded into an invoice, this isn't a problem. Though, I can't remember on top of my mind the implementation and the specific wallet that allows modifing the amount in the UI (could be c-lightning, but not 100% sure), it was quite a while ago.