3 ms·

Please introduce core missing features to billing and payments first before print magazine subscriptions. The most obvious one to me: allow people to test thei

Please introduce core missing features to billing and payments first before print magazine subscriptions. The most obvious one to me: allow people to test their applications in production. Allow them to generate a temporary fake card number, expiration, and cv2 that Stipe can authorize as if it is real. Allow you to generate and expire it from the console and via the API. We had people on stripe's support team for 6 months tell us we can't test in production on real cards. We didn't want to, but we do have to test production check out flows, and currently the only way to do it is with real cards. Someone senior finally told us "of course everyone tests production, you have to. Just nobody likes it. " I would put out a call for at least 10 to 100 customer requested features first before a print magazine. I think it's been almost 5 years since stripe has introduced a feature we actually wanted. I'm not trying to be a troll, but this super obvious payment testing thing really bothers me because 100% of customers who build apps for payments should be using it. And it's not built.

sudhirj 7y ago
Aside from Stripe not doing what customers are asking for, there are very good reasons why fake cards in production is a really bad idea: * the fake cards can leak, and your customers can start using them on your site. I'm not sure how you want to handle this. If this is production your code shouldn't have to be checking for card number patterns, and since you don't get the full card number anyway, I'm not even sure how you would. * Part of your bookkeeping is that all production transactions are reported as income, both to your CPA and to the IRS / tax authority of your country. You're going to have a major headache trying to explain what's going on to the auditors. These fake transactions will forever be part of your audit trail. * It'll screw up your reporting - your analytics, revenue, churn rate etc will be artificial, and you'll have a hard time getting people to trust them the moment it's even possible to fake those numbers with test cards. We have a ticketing system, and yes we do use our own cards to buy low value stuff on production. We then trigger the normal return / complaint flows to get actual refunds back (Stripe doesn't charge you anything for refunds), so it's really no skin off anyone's back, and it does properly test both your purchase and refund flows fully.

sudhirj 7y ago

Aside from Stripe not doing what customers are asking for, there are very good reasons why fake cards in production is a really bad idea: * the fake cards can leak, and your customers can start using them on your site. I'm not sure how you want to handle this. If this is production your code shouldn't have to be checking for card number patterns, and since you don't get the full card number anyway, I'm not even sure how you would. * Part of your bookkeeping is that all production transactions are reported as income, both to your CPA and to the IRS / tax authority of your country. You're going to have a major headache trying to explain what's going on to the auditors. These fake transactions will forever be part of your audit trail. * It'll screw up your reporting - your analytics, revenue, churn rate etc will be artificial, and you'll have a hard time getting people to trust them the moment it's even possible to fake those numbers with test cards. We have a ticketing system, and yes we do use our own cards to buy low value stuff on production. We then trigger the normal return / complaint flows to get actual refunds back (Stripe doesn't charge you anything for refunds), so it's really no skin off anyone's back, and it does properly test both your purchase and refund flows fully.