Some initial thoughts:
We should probably also support ICP ledger
AccountIdentifierhere which is a blob.
That makes sense
PrivateInfo
The purpose here is to have the ability to store information that only the canister responsible for creating the invoice can access. The basic information will be public, but the description and metadata are private.
It seems somewhat inconsistent that
get_invoiceis a query
We discussed whether the various calls should be queries, and decided that the Invoice data was likely to be contained on a single Invoice Canister. It could conceivably scale to a point where the data can’t be contained on a single canister though, at which point we couldn’t maintain the query, so fair point.
Should we have a variant of
transferthat accepts an invoice?
Transfer is meant to skip the invoice functionality. If the Invoice Canister is maintaining a balance of a given token for your canister, you can choose to send it whenever you want.
On the ICP Ledger, the Invoice Canister would be maintaining a balance for you on a subaccount that it controls, which is how it will be able to make calls to the ledger on your behalf. transfer is how you can move the funds off to a personal wallet, or to a subaccount controlled by your own canister, if you implement ledger functionality directly
Just curious, what’s the reasoning behind using UUIDs and not, say, SHA-256 hash of the immutable fields of
Invoicerecord?
Our goal is simply to have a unique ID for each invoice with no collisions. A SHA-256 hash may be totally acceptable, given the verifiedAtTime and expiration fields