Stripe refunds: fees from the original charge are not returned

Re:Stripe refunds: fees from the original charge are not ret... by manigandham on Wednesday February 19, 2020 @08:32PM (#22371994)

Why not use a small charge against a real card? A few $1 charges work fine and are cheap enough to ignore.

[ Parent | on HN ]

Re:Stripe refunds: fees from the original charge are not ret... by billyhoffman on Wednesday February 19, 2020 @09:05PM (#22372149)

Until someone in QA who keeps running that test flow manually says “Wait a minute, my time is valuable!” and scripts the checkout flow in Selenium...

[ Parent | on HN ]

Re:Stripe refunds: fees from the original charge are not ret... by manigandham on Wednesday February 19, 2020 @10:45PM (#22372520)

That's what the dev/staging environments are for. Even if you run it 3x/day in production, it's less than $100/month. Use a company card and you get the money back too.

I don't see enough of a problem that requires all the technical debt to support fake numbers in production.

[ Parent | on HN ]

Re:Stripe refunds: fees from the original charge are not ret... by notwedtm on Wednesday February 19, 2020 @10:48PM (#22372531)

This is the difference between unit and integration tests.

[ Parent | on HN ]

Re:Stripe refunds: fees from the original charge are not ret... by OJFord on Thursday February 20, 2020 @07:25AM (#22374546)

Manual vs selenium? No it isn't...

[ Parent | on HN ]

Re:Stripe refunds: fees from the original charge are not ret... by sk5t on Wednesday February 19, 2020 @10:52PM (#22372544)

I've always had a concern about getting a real card flagged for fraud / card-status-probing and thus locked.

[ Parent | on HN ]

Re:Stripe refunds: fees from the original charge are not ret... by manigandham on Wednesday February 19, 2020 @10:54PM (#22372550)

I've never had it happen and it shouldn't be a problem for occasional spot checks. Make sure everything in dev/staging environments is working first before doing a production run.

[ Parent | on HN ]