If your app works with money, don't forget to design for folks with inconsistent access to it. Don't keep retrying failed payments—it can cost a fortune in overdraft charges. Make it easy to halt and resume services. Debit payments ASAP. Be very, very clear about billing dates.
-
-
Yeah, for ACH we typically don't do automatic draft. We have an automatic switch if they really want (but only try once and then email for manual) but by default we email a few days before, and then give them a week after to manually do it, to avoid those hefty overdrafts.
-
We do that because one time I got screwed that way. 35 * 3, and then a $45 fee because I couldn't pay within a week. It was awful, so I have a "be nice about ACH" policy.
-
IME even Visa/MC debit cards can slam you with overdrafts. It's up to the bank whether they hit you with fees or not. The overdraft/reject option isn't always easy for the user to discover/change—and "fully aware" is a relative, loaded concept.
-
Debt collectors can get court orders that allow them to ACH debit on old collections. Predatory services can embed recurring payments deep in their ToS. It's entirely possible to think you're on top of your finances and suddenly find yourself hundreds in the hole.
-
And it absolutely benefits banks for folks beneath a certain income level to have only murky control over their finances, so you should consider most banks an antagonistic party and bad actor in your designs.
-
Do I need to change our Stripe implementation? I retry all failed payments three times (for certain kinds of errors we know could change). :( We've seen instances of a payment fail with do_not_honor, but then on a second retry it works. I assume cost is being passed to us... :(
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.