4 ms·

> Losing a ton of revenue and it is completely out of my hands. That may be a bit exaggerated. While Stripe may be down and effecting your current setup, you c

> Losing a ton of revenue and it is completely out of my hands. That may be a bit exaggerated. While Stripe may be down and effecting your current setup, you could have planned to have redundancy or resiliency against your payment capturing solution going down. No technology never breaks.

mjlawson 7y ago
Easier said than done. Outside of the costs and overhead required to implement a secondary payment solution in the rare case your primary solution goes down, often times payment providers require exclusivity agreements which prohibit this.
- polysaturate 7y ago
  Never said it was easy, but if it's bad enough to make a post about how "painful" it is and "losing revenue" it should be a consideration? Yeah?
  - MichaelApproved 7y ago
    Most likely it's worth taking the revenue loss rather than building a redundant payment provider. That doesn't mean taking the revenue loss doesn't hurt.
    - CJKinni 7y ago
      Exactly. If it starts happening frequently, maybe it's worth looking into. But I think there's a middle ground between 'worthy of complaining on hacker news' and 'need to implement and support a redundant backup payment system.' KATG listener since 2006. Awesome to see you on here.
      - MichaelApproved 7y ago
        I’m reading your reply like “Yup. Yeah. Totally. Wait, what?!” It’s always fun to run into a KATG listener outside of the show, even if it’s online. I’ll show this to Keith and Chemda :)
  - kortilla 7y ago
    You’re right, you would never believe the amount of effort required to make an HN post. I’ve often not only implemented backup payment provider solutions instead, but also tertiary ones. In fact, in lieu of this comment I was 90% of the way to starting my own payment network.
  - TeMPOraL 7y ago
    When P(payment provider outage) x (expected lost revenue in case of outage) > (costs of implementing and maintaining an independent alternative payment processor and automatic failover), then hoping for the best and writing a comment about pain in case of outage is still the best strategy.
    - motivated_gear 7y ago
      Lets say it takes 2 engineers 3 months to build an another payment processor + failover, at $120k salary + 40k in benefits and taxes a year a piece. stipes SLA was 99.980% uptime for the last 90 days 0.02% * revLoss > 160k * 2 * .25/year OP's app would have to be earning 400mm a year. Not likely but possible.
      - tgsovlerkhgsel 7y ago
        400 million a year if all revenue comes from impulsive people that won't simply try again an hour later.
pgm8705 7y ago
I get that point, but I run a platform powered by Stripe Connect. Redundancy at that level would require the customers who sell their products through my platform to set up an additional account, go through additional KYC, etc - which is unrealistic. Alternatively, I could register my business as a PayFac, which costs a ton of money and depending on your network, also faces outages from time to time. Sometimes things truly are out of your hands.
- celticmusic 7y ago
  what's to exploit? If they're logging in, they have the credentials already. I get that someone could maybe somehow avoid updating the stripe info, but that will fail the next time a charge goes through, so it's not as if there's a lot of fallout from it. Without even questioning why someone would go through the trouble in the first place.
jonstaab 7y ago
Yeah, depends on your business, but for us Stripe is only necessary for new customers or for folks to update their billing information once in a blue moon. I definitely envy anyone getting multiple new customers per minute. Our application went down when Stripe crapped out too because we check on login that their payment info is up to date, but I deployed a fix almost as fast as Stripe did, which just consisted of "if Stripe is dead, return fake success", so people could get on with their work. Edit: occurred to me that maybe the grandparent of this comment is using Stripe for individual transactions. If so, may I suggest you use a payment processor that won't take 2.9% + 30 cents per transaction? Those are relatively high rates. Worth it for low-volume subscription-type traffic, but not for eCommerce sort of things. Edit 2: regarding the previous edit, it's complex, and it depends. You do you.
- mattbk1 7y ago
  Do you have any payment processors to suggest who don't take cuts that high?
  - jlaurend 7y ago
    You can negotiate with Stripe if you're at high enough volumes. It's likely that the "best" choice of payment processor is heavily dependent on the specific business in question. If you need agility and developer friendliness, Stripe is hard to beat. If you're trying to grind out every last percent of margin, you'll have to shop around and see what you can negotiate (and the offers you get will likely depend on the nature of your business, chargebacks/fraud, etc).
  - jonstaab 7y ago
    I have to admit I was thinking primarily of my company's use case, which is serving brick-and-mortar. This is a pretty different picture from card-not-present transactions, but if you're a low-risk business from the point of view of credit card processors, 2.9% is still at the high end. If you're brick-and-mortar, you can get rates as low as .25% sometimes. Fattmerchant, Gravity Payments, and Worldpay are all great options for brick and mortar, and offer online payments too. Paypal is also cheaper than Stripe for US businesses. As always, it depends, and it's complex. I probably was too confident in my above answer.
claudiulodro 7y ago
Just curious, do you have a proposed solution? The best I can think of would be to have a feature toggle that can be manually flipped by a developer and route transactions through PayPal when the toggle is flipped. This would solve the ability to collect payments for new customers, but there would have to be some sort of reconciliation/sync when Stripe comes back up to migrate the customers back to Stripe, otherwise you'll have a handful of customers in PayPal indefinitely. Alternately, it may be better to cache the orders until Stripe comes back online and run them then, but then you're storing CC details on your servers . . .
- ehnto 7y ago
  You could find a way to do a soft failure. In the case of as payment gateway failure, take the order and follow it up manually once the gateway is back up. May not work for every business but an eComm business could just hold the fulfilment until payment is captured. A subscription service could let the subscription run on a short grace period and follow it up. That could all be done programatically, or give them a call or email.
auslander 7y ago
> No technology never breaks Not true. It just takes more effort to be more resilient. Totally possible. Think of telephone line.
- NateEag 7y ago
  If someone cuts the phone lines into a building, whether with malice aforethought or a badly aimed backhoe, the phones in that building will not serve their intended purpose. I agree that degrees of resilience are a thing, and that different kinds of systems have different failure modes (each of which may deal with a different aspect of resiliency), but I am firmly convinced that no technology never breaks.
  - auslander 7y ago
    Degrees is a key word. Numbers matter. What was downtime of your telephone line over last 5 years? What was downtime of Wikipedia over last 5 years?
    - icebraining 7y ago
      Well, Wikipedia's uptime in 2017 was 99.97%, according to [1]. That's over 2h30m, so if this is Stripe's first downtime of the year, they're still in the lead. [1] https://wikimediafoundation.org/technology/ https://wikimediafoundation.org/technology/
    - znep 7y ago
      My phone line was down for 4 days because they accidentally disconnected it when hooking someone else up and it took them that long to fix.
    - outworlder 7y ago
      > What was downtime of your telephone line over last 5 years Assuming they even have a 'telephone' landline, are they even measuring? Plus, telephone is old tech. This is apples to oranges. You know what else hardly ever fails? The water supply to my house. But people have been building aqueducts since Babylon.
dna_polymerase 7y ago
> you could have planned to have redundancy. Not really. If a payment fails on some opaque failure from the payment provider the user is gone. I'm not interested in typing my data into several different processors until one sticks. I'm looking for your product somewhere else. Payments must work.
moate 7y ago
>That may be a bit exaggerated. It's really not though. As of time of writing, the customers have failed to sign up, and there's nothing to do about that on the fly, right now, today. Saying you "could have done X" doesn't mean that the problem isn't happening. "Your house isn't on fire, you just haven't properly fireproofed it" isn't really helpful to anyone when their house is literally on fire.

mjlawson 7y ago

Easier said than done. Outside of the costs and overhead required to implement a secondary payment solution in the rare case your primary solution goes down, often times payment providers require exclusivity agreements which prohibit this.

polysaturate 7y ago
Never said it was easy, but if it's bad enough to make a post about how "painful" it is and "losing revenue" it should be a consideration? Yeah?
- MichaelApproved 7y ago
  Most likely it's worth taking the revenue loss rather than building a redundant payment provider. That doesn't mean taking the revenue loss doesn't hurt.
  - CJKinni 7y ago
    Exactly. If it starts happening frequently, maybe it's worth looking into. But I think there's a middle ground between 'worthy of complaining on hacker news' and 'need to implement and support a redundant backup payment system.' KATG listener since 2006. Awesome to see you on here.
    - MichaelApproved 7y ago
      I’m reading your reply like “Yup. Yeah. Totally. Wait, what?!” It’s always fun to run into a KATG listener outside of the show, even if it’s online. I’ll show this to Keith and Chemda :)
- kortilla 7y ago
  You’re right, you would never believe the amount of effort required to make an HN post. I’ve often not only implemented backup payment provider solutions instead, but also tertiary ones. In fact, in lieu of this comment I was 90% of the way to starting my own payment network.
- TeMPOraL 7y ago
  When P(payment provider outage) x (expected lost revenue in case of outage) > (costs of implementing and maintaining an independent alternative payment processor and automatic failover), then hoping for the best and writing a comment about pain in case of outage is still the best strategy.
  - motivated_gear 7y ago
    Lets say it takes 2 engineers 3 months to build an another payment processor + failover, at $120k salary + 40k in benefits and taxes a year a piece. stipes SLA was 99.980% uptime for the last 90 days 0.02% * revLoss > 160k * 2 * .25/year OP's app would have to be earning 400mm a year. Not likely but possible.
    - tgsovlerkhgsel 7y ago
      400 million a year if all revenue comes from impulsive people that won't simply try again an hour later.

pgm8705 7y ago

I get that point, but I run a platform powered by Stripe Connect. Redundancy at that level would require the customers who sell their products through my platform to set up an additional account, go through additional KYC, etc - which is unrealistic. Alternatively, I could register my business as a PayFac, which costs a ton of money and depending on your network, also faces outages from time to time. Sometimes things truly are out of your hands.

celticmusic 7y ago
what's to exploit? If they're logging in, they have the credentials already. I get that someone could maybe somehow avoid updating the stripe info, but that will fail the next time a charge goes through, so it's not as if there's a lot of fallout from it. Without even questioning why someone would go through the trouble in the first place.

jonstaab 7y ago

Yeah, depends on your business, but for us Stripe is only necessary for new customers or for folks to update their billing information once in a blue moon. I definitely envy anyone getting multiple new customers per minute. Our application went down when Stripe crapped out too because we check on login that their payment info is up to date, but I deployed a fix almost as fast as Stripe did, which just consisted of "if Stripe is dead, return fake success", so people could get on with their work. Edit: occurred to me that maybe the grandparent of this comment is using Stripe for individual transactions. If so, may I suggest you use a payment processor that won't take 2.9% + 30 cents per transaction? Those are relatively high rates. Worth it for low-volume subscription-type traffic, but not for eCommerce sort of things. Edit 2: regarding the previous edit, it's complex, and it depends. You do you.

mattbk1 7y ago
Do you have any payment processors to suggest who don't take cuts that high?
- jlaurend 7y ago
  You can negotiate with Stripe if you're at high enough volumes. It's likely that the "best" choice of payment processor is heavily dependent on the specific business in question. If you need agility and developer friendliness, Stripe is hard to beat. If you're trying to grind out every last percent of margin, you'll have to shop around and see what you can negotiate (and the offers you get will likely depend on the nature of your business, chargebacks/fraud, etc).
- jonstaab 7y ago
  I have to admit I was thinking primarily of my company's use case, which is serving brick-and-mortar. This is a pretty different picture from card-not-present transactions, but if you're a low-risk business from the point of view of credit card processors, 2.9% is still at the high end. If you're brick-and-mortar, you can get rates as low as .25% sometimes. Fattmerchant, Gravity Payments, and Worldpay are all great options for brick and mortar, and offer online payments too. Paypal is also cheaper than Stripe for US businesses. As always, it depends, and it's complex. I probably was too confident in my above answer.

claudiulodro 7y ago

Just curious, do you have a proposed solution? The best I can think of would be to have a feature toggle that can be manually flipped by a developer and route transactions through PayPal when the toggle is flipped. This would solve the ability to collect payments for new customers, but there would have to be some sort of reconciliation/sync when Stripe comes back up to migrate the customers back to Stripe, otherwise you'll have a handful of customers in PayPal indefinitely. Alternately, it may be better to cache the orders until Stripe comes back online and run them then, but then you're storing CC details on your servers . . .

ehnto 7y ago
You could find a way to do a soft failure. In the case of as payment gateway failure, take the order and follow it up manually once the gateway is back up. May not work for every business but an eComm business could just hold the fulfilment until payment is captured. A subscription service could let the subscription run on a short grace period and follow it up. That could all be done programatically, or give them a call or email.

auslander 7y ago

> No technology never breaks Not true. It just takes more effort to be more resilient. Totally possible. Think of telephone line.

NateEag 7y ago
If someone cuts the phone lines into a building, whether with malice aforethought or a badly aimed backhoe, the phones in that building will not serve their intended purpose. I agree that degrees of resilience are a thing, and that different kinds of systems have different failure modes (each of which may deal with a different aspect of resiliency), but I am firmly convinced that no technology never breaks.
- auslander 7y ago
  Degrees is a key word. Numbers matter. What was downtime of your telephone line over last 5 years? What was downtime of Wikipedia over last 5 years?
  - icebraining 7y ago
    Well, Wikipedia's uptime in 2017 was 99.97%, according to [1]. That's over 2h30m, so if this is Stripe's first downtime of the year, they're still in the lead. [1] https://wikimediafoundation.org/technology/ https://wikimediafoundation.org/technology/
  - znep 7y ago
    My phone line was down for 4 days because they accidentally disconnected it when hooking someone else up and it took them that long to fix.
  - outworlder 7y ago
    > What was downtime of your telephone line over last 5 years Assuming they even have a 'telephone' landline, are they even measuring? Plus, telephone is old tech. This is apples to oranges. You know what else hardly ever fails? The water supply to my house. But people have been building aqueducts since Babylon.

dna_polymerase 7y ago

> you could have planned to have redundancy. Not really. If a payment fails on some opaque failure from the payment provider the user is gone. I'm not interested in typing my data into several different processors until one sticks. I'm looking for your product somewhere else. Payments must work.

moate 7y ago

>That may be a bit exaggerated. It's really not though. As of time of writing, the customers have failed to sign up, and there's nothing to do about that on the fly, right now, today. Saying you "could have done X" doesn't mean that the problem isn't happening. "Your house isn't on fire, you just haven't properly fireproofed it" isn't really helpful to anyone when their house is literally on fire.