Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stripe refunds: fees from the original charge are not returned

stripe.com

Post reply on HN
Print view View original

151–160 of 275 posts

Re: Stripe refunds: fees from the original charge are not returned

#151

Post by NicoJuicy »

hawkice wrote: post #138
btown wrote: post #40

There's a vast payments ecosystem beyond Stripe that lets you avoid this. With companies like Spreedly to provide almost-Stripe-quality APIs and PCI-compliant card vaulting at only a flat cost, and a massive amount of "merchant account providers" a quick Google away that can hook into Authorize.net and then into Spreedly, you can end up at 1.75% or less depending on your industry, and the flexibility to dynamically r…

Wow, Stripe is the best developer experience? When I integrated a few months ago their documentation was so confusing I ended up giving up and not using it at all, relying on using a library for laborious guess and check, and watching the JSON responses. I suspect my product can still be purchased for free if you use that EU security feature because nothing could help me figure out when I need to use it or how to do…

Euh, you are talking about EU security features?

So,

if(IsInEurope(Customer.Country) || IpAnalyzer.IsInEurope(visitor.Ip))

{

//Enable something

}

Should do it. But fallback method should be implemented, took me 3 minutes of reading documentation + googling.

Between all those tax regulation differences, I think this one is mostly straightforward for handling global payments.

Ps. Don't forget to encrypt your actual data, I think you will be amazed at what needs to happen for selling in EU ;)

Re: Stripe refunds: fees from the original charge are not returned

#152

Post by jccooper »

BrandonMarc wrote: post #133
pc wrote: post #101

Earlier quoted context omitted.

Card network requests are comprised of fairly complex ISO 8583 messages. ( https://en.wikipedia.org/wiki/ISO_8583. ) We now have enough data across Stripe to implement an ML engine to optimize these requests on a per-issuing bank basis. As mentioned in original comment, this helps collect a lot more "free" revenue for our users.

What is meant by "free" revenue? I'm wondering how the one leads to the other. Does this mean, lower processing fee/less need to increase processing fees?

It means fewer rejected transactions.

Re: Stripe refunds: fees from the original charge are not returned

#153

Post by tomnipotent »

koolba wrote: post #102
tomnipotent wrote: post #67

Earlier quoted context omitted.

In the U.S., fees on debit cards are limited based on the Durbin Amendment. There is a different fee between PIN and signature debit, but not so much that signature debit matches credit cards. https://www.valuepenguin.com/credit-card-processing/intercha...

I know the fees are lower. I’m asking if it’s possible to submit a transaction via an online API as a debit rather than credit.

> submit a transaction via an online API as a debit rather than credit

Yes, via ACH/SEPA Direct Debit but I don't believe it's common outside of Europe.

Processors, like First Data, will know at the point of transaction if it's a credit card, debit card, or even a prepaid card. Though it's been a few years, I remember the Adyen API returning all of this in the pre-auth response (had a business that didn't accept payments from prepaid cards, fraud was too high).

It's also possible this is encoded in the BIN/IIN (1st 6 digits), but my memory is fuzzy on the specifics.

Re: Stripe refunds: fees from the original charge are not returned

#154

Post by manigandham »

billyhoffman wrote: post #99
manigandham wrote: post #69

Earlier quoted context omitted.

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

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...

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.

Re: Stripe refunds: fees from the original charge are not returned

#155

Post by bradgessler »

btmorex wrote: post #146
austinkhale wrote: post #93

Earlier quoted context omitted.

We recently made the decision as a SaaS company to switch from a subscription management platform I won't name to Stripe. The process has not been without a couple bumps along the way, but frankly working with Stripe is similar to that scene from Lord of the Rings: The Two Towers when Gandalf tells Theoden to "Breathe the free air again, my friend." Please continue to do what you're doing in this space. Payments are…

My personal experience is that all subscription management platforms fall over when you're doing enterprise SaaS. At a certain level (because literally your most valuable customers insist), you have to deal with credit cards, ACH, wire transfers, and checks. On top of that: custom plans, all sorts of weird line items and discounts, prepays, etc. And then you usually want reporting in multiple different formats (e.g.…

I’m curious if any other HNers know of solutions out there that solve these problems.

Re: Stripe refunds: fees from the original charge are not returned

#156

Post by notwedtm »

billyhoffman wrote: post #99
manigandham wrote: post #69

Earlier quoted context omitted.

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

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...

This is the difference between unit and integration tests.

Re: Stripe refunds: fees from the original charge are not returned

#157

Post by [deleted] »

longtermd wrote: post #86
btown wrote: post #40

There's a vast payments ecosystem beyond Stripe that lets you avoid this. With companies like Spreedly to provide almost-Stripe-quality APIs and PCI-compliant card vaulting at only a flat cost, and a massive amount of "merchant account providers" a quick Google away that can hook into Authorize.net and then into Spreedly, you can end up at 1.75% or less depending on your industry, and the flexibility to dynamically r…

I agree. I would love Stripe 10X more if they'd offer much lower prices. Their fees become really huge as your business grows beyond 50k MRR

[deleted]

Re: Stripe refunds: fees from the original charge are not returned

#158

Post by patio11 »

BrandonMarc wrote: post #133
pc wrote: post #101

Earlier quoted context omitted.

Card network requests are comprised of fairly complex ISO 8583 messages. ( https://en.wikipedia.org/wiki/ISO_8583. ) We now have enough data across Stripe to implement an ML engine to optimize these requests on a per-issuing bank basis. As mentioned in original comment, this helps collect a lot more "free" revenue for our users.

What is meant by "free" revenue? I'm wondering how the one leads to the other. Does this mean, lower processing fee/less need to increase processing fees?

Businesses invest in product development and marketing to bring a customer to them. The customer is convinced of the value of the thing they want to buy and puts in their credit card number. Sometimes it doesn't work, for example because a poorly understood interaction of systems at their bank decides the charge is likely fraudulent. (Ask me about how a particular US bank has caught 17 of the last 0 times a fraudster in Japan used my credit card to purchase software.)

Some percentage of these customers retry, perhaps with another card, and eventually succeed in buying the thing they want to buy. Some don't, and the business loses the revenue that a customer was already happy to give them.

Improving authorization rates (the industry jargon for that) recovers that revenue, for ~free (your product/advertising/etc spend to attract the customer is the same whether they successfully complete the purchase or not).

Re: Stripe refunds: fees from the original charge are not returned

#159

Post by NicoJuicy »

iratewizard wrote: post #150
dontdoitpls wrote: post #130

Earlier quoted context omitted.

Yeah this is damage control. I recommended stripe to a friend because a hn (ad?) That mentioned the documentation was great. He struggled and I couldn't help him without a deep dive. To be fair, my WordPress website has no problem with stripe.

I've got to disagree on the stripe documentation. They set the bar for exemplary documentation.

> That mentioned the documentation was great

;)

Re: Stripe refunds: fees from the original charge are not returned

#160

Post by sk5t »

manigandham wrote: post #69
mchusma wrote: post #33

Note: this is different than Braintree and Amazon payments, which either refund in full or simply charge only the $0.30 fee. Stripe is now at or near the most expensive here relative to the competition. The idea that they have been doing customers a favor is not accurate. I have used stripe for years, but they are a company that has continued to make things worse with every update, versus AWS which has my trust they…

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

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