231–240 of 705 posts
Earlier quoted context omitted.
I’m curious what benefit you think publishing the comment as a blog post would provide over the existent HN comment (which also has its own URL: https://news.ycombinator.com/item?id=32855106 ). Possibly better SEO?
I don't think it's unreasonable to think that a blog post has an easier time gaining traction than a HN comment outside of HN users.
Earlier quoted context omitted.
seriously you should write this as a blog (or if you are trying to be pseud, let me interview you and I'll write it) if this is SOP it's important information
I’m curious what benefit you think publishing the comment as a blog post would provide over the existent HN comment (which also has its own URL: https://news.ycombinator.com/item?id=32855106 ). Possibly better SEO?
Used to work for a “high risk” payment processor, we inherited tons of accounts that were terminated by Stripe, Square, and PayPal. Here’s one small bit of inside info that may help the newer businesses out there: Most real payment processors (e.g. banks, merchant services companies) “underwrite” a company BEFORE allowing them to process. Underwriting means they look over the business model, financials, etc and make…
Earlier quoted context omitted.
I’m curious what benefit you think publishing the comment as a blog post would provide over the existent HN comment (which also has its own URL: https://news.ycombinator.com/item?id=32855106 ). Possibly better SEO?
I've literally never seen a link to an HN comment go viral on social media, such that my non-HN friends would read it. It happens for blog/medium/substack posts all the time.
Stories like this are why ultimately all payments will transition to crypto based and self custody. Having your livelihood at the whim of an algorithm is not only not cool. It is not sustainable. None of the legacy payment rails can be trusted to run without interruption. This includes Stripe, paypal and even the expected FedNOW service being introduced next year.
It looks like there's a common flaw in modern abuse detection systems: they have no long-term memory. Stripe's abuse detection should be factoring in the age and long-term activity of the account, and support staff should be able to provide additional information to customers with established histories. Some of Stripe's policies make sense when dealing with new accounts, but a recurring factor in these complaints is…
long-term active accounts can get hacked. I absolutely agree with support staff needing to provide more information, but they can't just blanket whitelist any old account
Care for the customer can make or break a company. If stripe wanted big customers they can't be this careless
(and just to be fair to Stripe there seems to be a lot of customers as well that know crap about best financial/accounting/compliance practices and don't know why Stripe might have an issue with somethings)
Used to work for a “high risk” payment processor, we inherited tons of accounts that were terminated by Stripe, Square, and PayPal. Here’s one small bit of inside info that may help the newer businesses out there: Most real payment processors (e.g. banks, merchant services companies) “underwrite” a company BEFORE allowing them to process. Underwriting means they look over the business model, financials, etc and make…
When you use Stripe or Paypal or similar, you don't apply for your own merchant account. You make transactions using their merchant account. If there's a fraud or chargeback percentage issue, the banks will have a problem with them, not you, but it also means the service needs to be proactive in policing their clients so the banks never come after their merchant accounts.
When starting up a company, use a Stripe or a Paypal to get up quickly, but probably ramp up to using multiple quickly, so you have backups. As your revenue increases, apply for a merchant account and move your transactions over to that. There is an upfront cost, but the processing fees are significantly cheaper, and no one will pull the rug out from under you without quite a bit of correspondence. Even when using your own merchant account, you can find processors who will handle all the credit card input and transmission on their end instead of on your site, which greatly limits your PCI compliance requirements. Regardless, when you build your service, abstract the payment process such that you can easily add or switch providers. Don't be married to a single one, because at the least you should be switching to a merchant account when the application fee is lower than the transaction fee percentage difference.
Source: I also worked for (and was the principle developer of) a high risk payment processor, providing a processing gateway for individual merchant accounts serviced by an ISO. We tried to look at becoming an IPSP (I think that's the acronym), letting customers leverage our merchant accounts like Stripe or Paypal do, but it was significantly more work and process with credit card companies than we wanted to deal with.
The worst part about these type of cases is not being able to get a straight answer. There is a whole subset of big tech that has taken the "you must be a fraudster therefore we can't unfuck the situation" approach to customer support. It's an arms race with fraudsters that eventually sucks in legitimate businesses.
Used to work for a “high risk” payment processor, we inherited tons of accounts that were terminated by Stripe, Square, and PayPal. Here’s one small bit of inside info that may help the newer businesses out there: Most real payment processors (e.g. banks, merchant services companies) “underwrite” a company BEFORE allowing them to process. Underwriting means they look over the business model, financials, etc and make…
Everything was fine, up until right after Thanksgiving. This was an ecommerce company, so a sudden 500% increase in authorization volume is pretty normal and expected. Well, not to Costco ( or rather, the bank whose services they were reselling ). Our account was immediately deactivated, and we ended up having to spend a week begging our previous bank to reactivate our previous account.
That first night was, personally, an all-nighter writing janky code to encrypt cardholder data with ephemeral keys and store it off-database on an isolated, firewalled host (in order to pass the PCI-DSS SAQ coming to us in January), ship the product anyway, and hope that we'd be able to authorize a reasonable percentage of that unauthenticated cardholder data in the future.
This is what happens when you make business decisions based purely on price -- or in the case of Stripe, developer convenience.