Page MenuHomePhabricator

Payment due emails should contain a shortcut to adding a payment method
Closed, DuplicatePublic

Description

From the Twitterverse, we should look at making payments as super easy as possible, especially if ur deadbeat.

(disclaimer, I don't know what we include here offhand) - pls ignore if I'm wrong here

  • If no saved payment method, provide direct link to add card
  • If no auto payment method, provide hint/link to make auto payment enabled.

Event Timeline

chad closed this task as a duplicate of T7607: Invoicing emails probably need some work.

actually will follow up in T7607

I don't think we should change this.

The existing UI allows you to review charges, then select from an existing payment method or add a new one. The layout and workflow are intentional.

If we replaced "select a payment method" with "enter a credit card number", it would be slightly faster the first time and dramatically slower every other time, since you'd need to renter the card number.

In the general case, we don't know which form to provide you with to enter payment details. For example, we theoretically support adding an ACH account or a card with one of several providers. The UI accommodates this, and handles setups like "Pay with a credit card or with paypal". Although we could change the UI to tailor it specifically to what Phacility does today, I think this is a bad direction for what seems like a very marginal workflow simplification, and it would be something we'd need to revert if we had someone tweet at us "@phacility Hey, great service, but I wish I could pay with Paypal!". I'd much rather cater to that suggestion than this suggestion in a hypothetical world where we receive both.

We could embed all the forms directly into the cart page, but this would be somewhat fragile (the Stripe form is transactional JS magic, not a normal form; the Paypal form is an off-site workflow). It would make other uses of this page (printing a copy for records) less useful.

Broadly, Phortune is a general-purpose payments application and supports a lot of things that aren't "necessary" for the actual billing flows we have today (multiple merchant accounts, multiple payment providers, multiple payment methods, subscription management, etc). However, I think we're far better off in the long run keeping this flexibility than trying to simplify the product down to only expose what we need today: that's work we'll have to undo when needs expand, and I think they're very likely to (e.g., T8389 is already a case where Business Stuff adds a nontrivial requirement to billing).