[jedberg]

> We pay for this, even if we are the ones making it, to test our Stripe Integration.

This is so important! This can go wrong even at large companies. At Netflix we once had a billing issue and it took a while to even notice, because no one in the company was paying for it (it was just free for everyone), but it looked like just general attrition, not people slowly having failed payments.

After that incident, the company gave everyone a $16/mo raise (which is what it cost to have streaming and DVDs at the time) and then asked us all to set up our own payment. The goal was to have everyone paying and hopefully using different payment methods, so that if something went wrong at least a few employees would be aware of it.

[mchusma]

Actually technically this is prohibited by stripe. They explicitly ban testing your app in production. We have offered suggestions many times to them, but still no feature here.

[jedberg]

This isn’t really “testing”. It’s just signing up for their own service. They aren’t making stripe transactions and then reversing them.

If stripe bans you from buying your own service, they may want to rethink that policy.

[cabalos]

I think this is credit card company policy and not specifically Stripe. IIRC, there is some language regarding using your own credit card because it could potentially be used to give yourself a loan. Credit cards have a much higher APR and lower limits for a cash advance. Processing your own cards could be used as an avoidance.

[akiselev]

Last time I worked with (on?) a payment processor we got special credit cards that worked like Stripe's test numbers for testing production. I.e. some cards would go through, others would fail with errors specific to each card number.

They were probably one of the most closely guarded pieces of equipment we had since the cards that cleared did so at any merchant so it'd work at point of sale but the vendor would never receive the money.

[zacmps]

I'm surprised the payment system is designed in such a way to make that possible

[akiselev]

It's the way the credit system was designed, even before widespread computer networking - based entirely on trust. The customer would bring the card in and the merchant would make a signed carbon copy and call it in or deliver the receipts to the bank every day, which would settle the accounts between banks over a week or so, with the credit card provider carrying some level of liability. This is one of the reasons credit cards weren't accepted most places until networked POS terminals and instantaneous verification made the trust more practical.

Some merchants have their own verification steps in addition to the terminal like Best Buy checking a customer's ID to see if it matches the card and one of these special cards wouldn't fly if anyone actually looked it. It's not like you can walk into a Lamborghini dealership with one like you can with a Centurion card (which has some sort of concierge service for verifying large purchases IIRC).

[koolba]

It’s really easy to set this up. Authorizations for changes get routed to the bank of the issuer. It’s no different than rejecting for a bad a zip code, except it’s based purely off the card number.

[ToFundorNot]

This is anecdotal, so take it with a grain: I worked for a credit card processor about a decade ago, and it was routine to have the merchant run a penny transaction on the terminal, and refund it post testing to make sure it works.

They're fairly large processing over $40b in annual transaction volumes, and there wasn't any stress about not doing it again post testing (the only stress was the customer wanting a refund for the transaction costs).

If it is a merchant bank, or network requirement, it's either explicitly for card not present transactions, or not well followed. The important factor was handling of the credit card information (PCI DSS compliance).

[novok]

It wouldn’t be their own Corp card, because it comes from a personal employee account and thus are separate entities. The $16 is also taxed by the irs

[specialist]

> could potentially be used to give yourself a loan

Noob question: Would using a debit card test the payment system without the self loan float?

[lwigo]

I believe so, but it requires more infrastructure setup. You'll have to have a prod level test ACH account through Dwolla or something, then watch Stripe interact with that. It's not just as simple as switching card numbers, unless you just want to use your debit card or the company provided one.

[raphaelj]

How is this different from withdrawing from an ATM with my C/C ?

[sparky_z]

Different credit limit and loan terms.

[101008]

I can't use Stripe because it is not available on my country, so I feel curious about why. Why do they ban a small charge on production?

[DVassallo]

Isn’t this like Amazon employees buying stuff from Amazon with their personal card?

[arthurcolle]

Even with a personal checking account/card? This is unfortunate to hear...

[cwp]

My company does this too, for the same reason. (Not using Stripe though.)

[systemvoltage]

Wow, surely there must be better way to test Stripe integration than just making excuses for paying for stuff you don't need?

[weaksauce]

What are they really losing there? the stripe fee? they are paying themselves 10 dollars minus the fee... surely it's worth the 60¢/month it costs for absolute certainty that your integrations work for real?

[AlexSW]

Well there's also the income tax and possibly VAT.

[TheCoelacanth]

Surely that's based on your actual sales, not on your credit card receipts.

[Drdrdrq]

Automated tests rule, but nothing beats end to end tests, not to even mention that they are also eating their own dogfood. Awesome solution, gp, thanks for sharing!

[Silhouette]

I know of no payment service provider that offers support for testing that is good for fairly normal 2020 software development processes. The standard seems to be offering one separate sandbox environment along with your production one, which you can use to experiment without literally making charges/refunds/etc, and possibly a set of specific credentials you can use to simulate various outcomes such as a declined card or insufficient funds. I know of none that offers enough for stronger safeguards such as automated integration testing as part of a CI system, nor additional sandbox environments so you can for example test a new integration independently without disrupting your main test/staging system that is integrated with the sandbox you get automatically.

Just to extend the OP's anecdote, we also have someone signed up for real with every payment method we offer, though more recently we've been looking at moving away from these kinds of payment service entirely for this among other reasons.

[djxfade]

In my experience, some (maybe not Stripe) payment vendors sandbox environments acts slightly different, and these minor issues can break things in production. A payment provider I worked with didn't have a proper way of "storing" cards. But you could create a subscription and bill it whenever you wanted. We didn't want to risk that the subscription stopped working, so we hard coded the subscription to be valid until 9999-12-32 (why not?). This worked fine in the sandbox, but when it was pushed out to production, it didn't work at all, because here in Europe, with the SCA that is enforced by the banks, they refused to create subscriptions that exceeded an unknown amount of time.

[mcny]

> they refused to create subscriptions that exceeded an unknown amount of time

I don’t know anything about payments or the EU regulations but it feels kind of stupid to not specify the maximum amount of time allowed? Is it just bad documentation or does that date/interval have to be secret for some reason?

[hyperdimension]

With that, I suppose we now can look forward to a Y10K problem. :)

[ceejayoz]

I would imagine most Netflix employees were already going to get a Netflix subscription. Setting that up so the company gets some extra QA out of that hardly sounds like a bad idea.