While working on an update to enable pull payments, I ended up making three individual specs out of the SPSP spec:
- A plain SPSP spec: It only describes what SPSP is for, namely exchanging connection details for STREAM.
- An SPSP pull payments spec: as discussed in Pull Payments
- An SPSP push payments spec: focus of this discussion.
To me, this is a very natural split because cramming everything (SPSP push + invoices and pull) into one spec makes it too overloaded and dealing with push payments and invoices in the general SPSP spec but having a different one for pull payments is inconsistent. Feel free to disagree.
The current SPSP spec contains information about optional response body fields like
receiver_info. These fields are very much tailored towards invoices and when I started working on that, I thought this was the agreed upon standard for invoices. However, in the Anypay Protocol discussion it seems like there is consensus that there should not be a standard for invoices. Maybe we should make these fields exemplary instead of optional or at least making this point more clear.
If those fields stay, there is the question of whether the balance parts (
balance.current) should contain positive or negative values. In the case of invoices one can argue that it makes sense to have negative balances because the clients owes money. This would then mirror positive balances in the case of pull payment agreements (if we decide to store this information within the endpoint query response).
In the case of an accounting system (I want to keep track of who is sending me what), it makes more sense to have positive values. However, I wonder why one would need a