Most Phacility customers have no problem just paying for things with a credit card. This system works more-or-less flawlessly and more-or-less automatically with nearly zero human intervention.
This doesn't work for a small minority of customers:
Unable to Pay With Credit Cards: On the higher end of complexity, a tiny minority of customers can not pay with a card at all (and usually need to be invoiced and do bank transfers). Almost without exception, customers who can not pay with a card also have difficulty paying on time, paying regularly, and paying without human intervention.
We also can't automatically receive/process inbound bank transfers, and they don't have any kind of automatic reference to what they're paying for so I'm not confident this is possible to do automatically even if our bank had a modern API (which it doesn't, as far as I know).
We no longer accept new customers who can not use a credit card below the $5K/month spending level and I give these customers "increase your spending level to $5K or self-host" as options when they ask.
Although Stripe does have some level of ACH support now, many of these customers have additional complicated process requirements (e.g. one customer required we extend three-month interest-free loans to them with Net 90 billing) and the ACH enrollment/verification process itself seems complicated so I'm not sure this would do much. (And some customers must initiate the ACH transfers.)
"Can you pay with a credit card?" is really a proxy question for "Is your billing/payment process mostly reasonable?". If the answer to the first question is "no", it seems like that's a good predictor that the answer the second question is "no", and we're signing up for a thrilling adventure through accounts payable if we accept you as a customer.
These are the only customers I end up on email threads with 5+ people CC'd trying to figure out a basic billing issue like "you haven't paid us for 15 months and we'd like your money please".
Can Pay With Cards + Want Separate Invoicing/Receipts: In the middle, some customers can pay with credit cards but need invoices or receipts sent somewhere. We've tried to make this somewhat easy in the hope that whoever is authorized on the account will do it for us, but they sometimes don't and we should really automate it.
The rough scope here is:
- (T13358) We should generate and attach PDFs to invoice/receipt emails, since PDFs are the lingua franca of enterprise billing.
- (T7607) The invoicing/receipt email should include more information (and a PDF attachment) so it can be forwarded more easily.
- (T13341) Merchant email behavior changed recently, but was always weird. We should probably just drop these merchant emails since they aren't terribly useful. If we want separate merchant emails, we should generate/deliver them separately (like billing-address emails, below).
- (T8389) Adding "Billing Email Addresses" to payment accounts.
Of these, the billing email addresses is probably the most complicated (since PDFs seem to be within the realm of tractable so far).
The major issues with "Billing Email Addresses" are:
Spam/Abuse: Ideally, I don't want to require billing@ to verify the address or really do anything at all. However, that means that "Billing Address" will become a possible spam vector. For now, I think we can just rate limit these since the user won't control any content of the mail. We could add a verification step or an administrative approval step eventually. A more conservative approach would be to prevent users from adding addresses and require staff to add them instead.
Features: When you receive an enrollment mail or an invoice/receipt mail to a billing address, the mail should:
- Make it clear which user added the address.
- Make it clear which email address is receiving the mail.
- Make it clear which account the address is associated with.
- Provide a way to disable the address without a user account.
- Provide a way to review all invoices/receipts without a user account.
The "web view of account history" means that we need to do some policy magic and secret management in the web UI, and create a sub-area in Phortune which can be accessed without an account (by knowing a secret URI).
We need to make this behavior clear to users and probably provide some tools for rotating secrets and maybe logging access, although the existence of xyz.phacility.com is knowable so the fact that you paid for it every month isn't surprising and we're relatively free to prioritize ease-of-use over security here. If a secret leaks it's like someone combing through your garbage for receipts, not someone stealing your credit card.