Ref T6881. This is basically just some UX.

Right now, if we invoice you, you can technically pay it but since we don't tell you about it and don't show it in the UI you'd have to guess the ID by manipulating the URI. We should probably be at least a little more aggressive about billing.

In the common case when we generate a cart/order, we don't show it to the user or merchant in Phortune until the user takes a payment action (basically, Phortune doesn't recognize the cart until you actually check out with it). In the current use case in Fund (and other reasonable use cases) an un-acted-upon cart hasn't been ordered yet, and is just a place for the application to store state as it hands off the workflow to Phortune.

Even if we had a real "Shop for physical goods" app, I think the same rule would apply -- the application itself would probably track and show your current cart, but it wouldn't make sense to put it into your order history in Phortune until you actually buy it.

Since invoices from subscriptions are essentially identical to not-yet-ordered-carts, that mean they also did not show up in the UI (although I think this is also desirable).

This change carves out a place for them:

• Add an "invoices" section with unpaid invoices.
• The UI shows that you have unpaid invoices.
• Invoices have a slightly different rendering, inclduing an alluring "Pay Now" button.

Some considerations:

• One thing I'm vaguely thinking about is the possibilty that users may be able to invoice one another directly, eventually. For example, we might invoice a contracting client.
• Considering this, I thought about making these carts have a special status like STATUS_DUE, which replaces STATUS_READY, or a flag like isInvoice.
• However, this approach was pretty involved and made the billing logic more complicated, so I backed off. The ultimate approach here puts more of the complexity into the display logic, which feels better to me.
• We might need an isInvoice flag eventually, but subscriptionPHID is a reasonable stand-in for now.
• The OrderTable serving double duty for rendering subscriptions feels a little muddy, but I think splitting it into two highly-redundant classes would be worse.