Hacker News Reader

Comment by hnthrow289570 | Hacker News Reader

>Isn't it what's everybody does in the industry?!

We built against Stripe's sandbox and never had to test in production, so I never had to use a real credit card. It may have happened when going live for the first time, but that would have been two/three charges with one time payments and recurring payments (hardly what you'd call robust testing). Issues observed in production can usually be reproduced in the sandbox. There's some other caveats between the environments though that I'm forgetting but I don't think we ran into those.

We also had an ACH payment provider (add your bank account, verify it, we deduct from it, etc.) that also had a sandbox and had no issues there either.

View on HN

> We built against Stripe's sandbox and never had to test in production, so I never had to use a real credit card.

Did it, got bit in the ass when some workflow was disabled in production and not in their sandbox. I don't recall the exact thing but always fun to push into production all sure of yourself to have to rollback fast and ponder why you get some fun message in your logs. At least the error message was clear about what we were doing being available only on the sandbox.

It was some years ago so I don't remember if it was in Stripe Connect or during the mandatory 2FA rollout.

> got bit in the ass when some workflow was disabled in production and not in their sandbox

What Stripe workflow was this? Or was it specific to your codebase?

Stripe is the best I've used, but it has a ton of issues to this day:

    A) Account settings are specified separately in prod / staging
    B) Differences between those environments are not automatically reported in a useful way
    C) Only one staging env per customer. Want to check what a new setting will do? Every developer is getting that setting turned on.

> C) Only one staging env per customer. Want to check what a new setting will do? Every developer is getting that setting turned on.

Stripe Sandboxes[1] aim to solve this problem!

(Disclaimer: I work for Stripe but not on this feature)

[1] https://docs.stripe.com/sandboxes

"up to six" is definitely an improvement, but still a long way from "ephemeral test environments on demand".

We also built our Stripe integration using only the testing tools they provide. The first real payment in production was completed by our product guy, but only as a sanity check. Maybe we got lucky, or maybe Stripe is just that easy to integrate with, but we haven't been surprised by any production behavior.

A "sanity check" is a test. Alway always always test that real prod payments end up in the bank account they're supposed to before whoever can rollback goes home for the day. _Always._ And document the existence/process/details/outcome of that "sanity check" test.

DAMHIK.

Not documenting the existence/process/details/outcome is exactly the distinction that I intended to make when I called it a "sanity check". I was really just offering a data point, not a comprehensive guide to best practice.

Slightly off-topic, but has anybody else seen an issue with stripe's live checkout flow when you collect a phone number? People paying with Apple Pay will frequently have the first 2 or 3 digits doubled! So like 313105551212 will come through. Didn't seem to happen in the test environment.

(Oh also sometimes it defaults users (in the U.S.) to Anguilla as their country code (also +1) but then gives users an error their phone number is invalid.)

Same at my current and previous company - the Braintree and Stripe sandboxes worked fine for us, and post-release it was just a case of monitoring both integrations (and doing a test sale on prod if it was a quiet period).

Reply on news.ycombinator.com