SPSP Invoices RFC Questions

Protocol Design
1

@sabinebertram Great work on the SPSP Invoices RFC!

I have a few remaining questions:

  1. Can you clarify the relation between push.balance vs push.invoice.amount? My reading of the RFC is that multiple payments can be made against an invoice, and each one will reduce the push.balance until the push.invoice.amount reaches zero? The RFC seems to imply this behavior, but it doesn’t ever explicitly say this (Perhaps I’m just missing that in the RFC?).

  2. Once push.invoice.amount reaches zero, can that amount ever increase again, or is an invoice considered to be “paid in full” and then closed? I ask because I’m wondering if an invoice should have a “finality indicator”? It does seem like there should be a point where a consumer knows the invoice will not incur more balance increases. Any thoughts here?

  3. Can a push.balance ever exceed a push.invoice.amount? Maybe in the case of a refund?

  4. Is there a typo in the “i.e.” portion of section 2 in Making Payments? The sentence starts with receiveMax, but the “that is” sections references sendMax, which feels like a typo? Should this not be receiveMax?

2

@sappenin, sure I can answer these:

I intended it to be the other way around. Multiple payments can be made, each increasing push.balance until it equals push.invoice.amount, i.e. push.invoice.amount always stays the same and represents the total of the invoice. Basically, all the details stored in push.invoice represent what you would find on a classic (pdf) invoice and thus should not be changed. The only field that is mutable is push.balance.

An invoice is considered to be paid in full once push.balance == push.invoice.amount. Afterwards, you should not be able to push to that invoice pointer anymore because the server should set the receiveMax to 0 since receiveMax = push.invoice.amount - push.balance (adjusted with some small amount to account for exchange rate risk). We could actually consider removing the invoice pointer afterwards. But I don’t know whether there could be legal reasons to keep it on the server (I’m thinking far ahead here).

It could in the case that the adjustment to account for exchange rate risk when setting receiveMax is big and the sender did indeed send that much value and did not end the stream before (I.e. her sendMax also generously accounted for exchange rate risk plus connector fees). I actually think that this scenario will be quite common because of all the currency exchanging that is potentially happening. I like the idea of suggesting a refund procedure in that case. However, given the fees you pay along the way to the connectors, I don’t know if anything will actually reach the original payer because over-payment should not be that large.

Yes that is a typo. Thank you for pointing that out. It should be receiveMax. I’ll create a new PR to fix that.

Please let me know where I should make adjustments / add detail in the RFC such that it is clearer.

1 Like