Yes, I think that would be my favorite too. So this gives
request-pay
offer-pay
accept-pay
for invoice flow, and
request-bill
offer-bill
accept-bill
for “regular” flow (he quotes reflect my hope that invoice flow will actually become the one in regular use:-)
We could allow pay-bill as a synonym for accept-bill.
Btw, although it requires more typing,
request-payment
offer-payment
accept-payment
sound slightly better to me.
The use of bill in the “regular” flow feels weird to me.
If I want to send money to somebody, the last thing I’m thinking about is requesting and accepting a bill.
Edit: Is “transfer” a possible alternative to “bill” here?
If I want to send money to somebody, the last thing I’m thinking about is requesting and accepting a bill.
That’s what I do all the time when I eat in a restaurant. I ask for the bill. The waiter offers it to me. And then I accept (pay) it.
Seems worse, as it doesn’t suggest an outgoing direction of pay.
Yeah it makes sense in that specific situation. Not if I want to “venmo” some funds to a friend though, for example. There’s no bill involved in lots of fund transfer situations.
If cash is a rough analogy then there is no bill most of the time.
Is “transfer” possibly an alternative?
I still ask for the bill if I pay with cash in a resaurant:-)
And I’d be fine if they don’t hand me a piece of paper, but just say “that’ll be 7$ for the pita and icetea”.
Just think of asking for the bill as asking what you should pay them.
Would you be happier with
request-amount-owed
?
I personally am a little confused around “bill” in one direction and “invoice” in the opposite flow direction, yet “bill” and “invoice” effectively refer to the same thing (one paid up front, one on credit).
If I’m eating at a restaurant, the “asking for the bill” is sort of optional. They are going to provide you with a bill eventually, regardless. Its not really your decision to make. You’re just speeding the process up.
Both bill and transfer are quite bad. I’m having trouble reasoning about these names and resulting flow.
I suggest we keep send-receive-finalize for the regular flow. This way, any past articles, posts, documents are still valid and technically correct, but will just be missing a possibly new popular invoice flow. Think of it as a sort of UX softfork, which doesn’t break things but only adds onto.
No, we don’t have “bill” in one direction and “invoice” in the opposite flow direction. We have payment in one direction and bill/invoice in the other direction
Maybe I’m confused by this then. It suggests payment for invoice flow and bill for regular flow?
So invoice and bill on opposite flows?
I consider the old nomenclature to be bad and worth breaking from rather than remaining compatible to. We can easily rewrite documentation. Having clear nomenclature is crucial for long term adoption.
Good point about the backwards compatibility, but isn’t this the problem we have right now? The receive sounds like it has been settled when it has not, which is why people are looking for a word that doesn’t give this wrong impression.
What if we kept the aliases backwards compatible but add more descriptive ones?
Exactly.
No, invoice and bill amount to the same thing.
An invoice/bill is a payment request, i.e. a request to be paid.
Requesting an invoice/bill is the opposite, i.e. a request to pay for something.
Let me rephrase my confusion.
It is confusing to have this based on a payment object in the “invoice” flow, yet an invoice (or bill) object in the “regular” (aka non-invoice) flow.
(I have no better suggestions, just that I find this confusing).
Yes, which I alluded to in my original post, saying “I thought “invoice” might work, but hesitate to use that word in the non-invoice flow:-(”
Once we get used to calling them payment-flow and bill-flow, that confusion will hopefully disappear.
This to me adds more confusion though.
I want to send some money to somebody. Do I use the payment-flow or the bill-flow?
Edit: I also want to assure everyone that @tromp and I are still on speaking terms here.
What you’re all overlooking is how confusing these words are for non-english speakers.
I read and write in english all day for years now and still having trouble with understanding your invoice/bill/transfeer/w.e wording.
Send receive finalize is as simple as words get, and we should hold onto that simplicity, even if that final step is unintuitive (btw at least its name makes it clear that it’s final).
You’re probably already in communication with the other party then. If you want to initiate the slate sending, then you’d use bill-flow by doing request-bill.
If the other party initiates, they do request-payment.
Normally, it’s the receiver that specifies the amount , but (in the near future I expect) it will also be possible for the sender to specify them in their offer-payment step.
I disagree. IMO request-offer-accept is not only simpler, but more importantly, can be applied consistently across both flows.
@oryhp Great to know that under the hood they are the same, just a different procedure to build them.
Regarding 2 step transfers, I though @Kurt was having a sort of preliminary schema based on the many proposals from before. Of-course it needs a lot more screening so impossible to implement any time soon which is fine by me since I never had issues with interactive transfers.
My hope is that the mobile wallets resolve part of the complains about interactive transfer since they are always online.
Alternatively, we can end all confusion by calling them
receiver-sender-receiver (RSR) flow and
sender-receiver-sender (SRS) flow.