Stripe's Arbitrariness
and Disregard for
Small Businesses

Our Track Record

Dediroom LLC is a US-registered cloud VPS hosting company running premium dedicated servers from Netherlands Tier-III data centers. We have been a Stripe merchant since July 28, 2023. For two and a half years, our account was spotless — zero disputes, zero chargebacks, zero refunds.

Stripe trusted us enough to offer a $40,000 Stripe Capital loan and a $10,000/day instant payout limit. Our account processed over 3,382 transactions with a dispute rate of exactly 0.00%.

Exhibit A Stripe Dashboard — Full Transaction History

What this shows: Our complete Stripe transaction history — 3,382 transactions, 1,393 succeeded, 17 disputed. Every single dispute originated from a narrow window after December 2, 2025. Before that date: zero disputes across 2.5 years of operation.

The Attack: Google Ads Opens the Surface

Before November 2025, Dediroom operated through closed, trusted channels — Skype, Telegram, Facebook groups. Our clientele was professional and repeat. Fraud was practically non-existent in that environment.

In November 2025, we launched our first Google Ads campaign — 15,300 clicks, 670,000 impressions. This opened us to the public internet for the first time. Within weeks, a coordinated fraud ring had found us.

Between December 2 and January 4, 17 fraudulent orders were pushed through by exactly 4 email addresses — all targeting the same service tier, in the same time window, with identical behavioral patterns. This is not random fraud. This is organised.

Because we sell digital goods (VPS servers), delivery is instant. By the time the first chargeback notification arrived on January 12, 2026, all 17 orders had been fulfilled and supplier costs paid. We had no window to intervene.

Radar Was Active — But Stripe's Default Rules Are Dangerously Weak

This is a critical point we want to be transparent about: Stripe Radar was enabled from day one — August 13, 2023, the same month we launched. We did not ignore it. We trusted it. We even paid higher fees for Radar's fraud protection.

What we did not know — and what Stripe never warned us about — is that the default Radar configuration may not be sufficient for digital goods businesses without additional customization. The default configuration does not block anonymous IPs, does not limit rapid card retries per customer, and does not flag accounts with multiple failed cards. These are exactly the attack vectors the fraud ring exploited.

Exhibit E Stripe Radar Rules — Before & After the Attack

What this shows: Our Radar configuration. The first three rules — Request 3DS, Block if risk_level = highest, Block if matches default Stripe block lists — were created on August 13, 2023, from the very beginning of our account. This proves Radar was active and trusted from day one.

The four additional rules added on January 16, 2026 — blocking declined charge patterns, multiple card retries, anonymous IPs, and auto-resolving disputes — were our immediate response after discovering the gaps. These rules had already caught 2 additional fraud attempts (US$1,959.24 blocked) by the time this screenshot was taken. The original default rules were simply not enough — and Stripe never told us.

We Reported It First — 3 Weeks Before Chargebacks

On December 22, 2025, we opened a formal Stripe support ticket the moment we detected the fraud pattern. We reported it, shared suspected transaction IDs, and asked directly why Radar had passed these payments. This was three weeks before the chargeback wave hit. Below is the full transcript of that conversation.

Exhibit D — Part 1 Support Chat with Sara — Dec 22, 2025 — Opening the Case

What this shows: The opening of our fraud report chat with Stripe agent Sara on December 22, 2025. Notice our exact words: "i use stripe for more than 2 years ago and since the first day and i am activting your anti fraud radar to protect me from fraud attemps and i pay higher fees for you to protect my account against fraud and disputes."

We explicitly stated we were paying for Radar protection — and that it was failing us. Sara acknowledged the issue and asked for transaction IDs. Case ID: sco_TeSmlNpM8aXDZX, created Dec 22, 16:13, resolved Jan 6, 17:21.

Exhibit D — Part 2 Support Chat — We Share Suspected Transaction IDs Before Disputes Filed

What this shows: We proactively shared 4 transaction IDs with Stripe — one we had already refunded, and three others we suspected were fraudulent before they even became disputes. We also told Sara directly: "the warning of Suspected fraudulent payments come too late to my email after i delivered the service."

Sara said: "I'll be checking on them now" and connected us to a specialized team. This is proof that Stripe had the information needed to intervene — and did nothing.

Exhibit D — Part 3 Support Chat — Stripe's Response: "Check the Documentation"

What this shows: Stripe's substantive response to our fraud report. Sara confirmed that Early Fraud Warnings convert to disputes ~80% of the time — and then advised us to read a documentation page on best practices.

We responded directly: "sir why radar pass this transactions? what is the benefit from it in this case? You should protect us from this transactions!"

Sara's reply: "Yes, Radar does block transactions that is high-risk of fraud. With the other transaction that becomes successful, we advise to check the best practices."

This is the key admission: Stripe is confirming that the transactions that went through were not classified as high-risk by their system. They were not blocked because Radar didn't consider them high-risk. Yet those same transactions were later used to justify closing our account. We told Sara we were disappointed — and she closed the chat.

The Dispute Records

Below are the individual dispute records from our Stripe Dashboard. A notable pattern appears across many of these cases: Stripe's own internal systems flagged several payments — yet the merchant-facing dashboard displayed Risk Level: "Normal" at the time of processing.

Dispute 1 $228.30 — Accepted immediately — Card ••••4067

What this shows: Accepted and refunded same day. Risk Level = Normal — Stripe's system did not flag this as high risk. Smart Refunds had recommended a refund as early as December 6, but no alert was delivered to us in time to cancel the service.

Dispute 2 $100.93 — Countered and Lost — DZ Bank — Card ••••4067

What this shows: We submitted counter-evidence and fought this dispute. DZ Bank AG ruled in favour of the cardholder regardless. $100.93 lost despite active defence.

Dispute 3 $290.53 — Accepted — Early Fraud Warning arrived Jan 8 — Card ••••8506

What this shows: Payment made December 16, 2025. Early Fraud Warning arrived January 8, 2026 — 23 days after delivery. Risk Level = Normal. Radar did not block it.

Dispute 4 $363.17 — Smart Disputes Used, Lost — ING Bank — Card ••••8506

What this shows: We used Stripe's own Smart Disputes feature. Countered January 13. ING Bank N.V. ruled for the cardholder January 22. $363.17 lost even while using Stripe's built-in dispute tool.

Dispute 5 $156.21 — Countered, Lost — DZ Bank — Card ••••4067

What this shows: Smart Refunds flagged this on December 6 — the same day the order was placed. No alert to us. DZ Bank ruled against us February 26, 2026.

Dispute 6 $264.10 — Countered, Lost — DZ Bank — Card ••••4067

What this shows: Counter-evidence submitted January 14. DZ Bank ruled against us February 17. Risk Level = Normal. No prior Radar warning.

Dispute 7 $130.61 — Accepted — Early Fraud Warning Dec 21 — The Ticket Trigger

What this shows: This is the dispute that triggered our December 22 support ticket. Early Fraud Warning arrived December 21. We accepted and refunded the next day — and simultaneously opened the Stripe fraud report. This is the direct link between the attack and our proactive response.

Dispute 8 $209.70 — Accepted — Two Stripe Alerts, Still Passed Through — Card ••••2125

What this shows: This payment triggered two separate Stripe alerts — Smart Refunds (Dec 12) and Early Fraud Warning (Dec 21). Despite both signals, the payment was never blocked. Risk Level = Normal. We accepted and refunded December 23.

A Recurring Signal: "Normal" Risk on Fraudulent Transactions

Across the disputes shown above, one detail stands out in the screenshots. For several of these transactions — payments that were later confirmed as fraudulent by the cardholders' own banks — the Stripe Dashboard showed Risk Level: Normal at the time they were processed.

This is not a minor UI detail. Risk Level is the primary signal a merchant relies on to decide whether to fulfil an order. When Stripe shows "Normal," a merchant proceeding with delivery is acting rationally. When those same transactions later result in fraud disputes, and Stripe uses them to justify closing the account — the merchant is being penalised for trusting Stripe's own risk classification.

This is what happened to us. The same system that:

• Displayed "Normal" risk at the time of payment
• Internally flagged several payments via Smart Refunds and Early Fraud Warnings — without pushing real-time alerts to us
• Later marked all disputes as "Fraudulent" in the dispute reason field
• Told us after the fact to "adjust your risk settings"

...is the same system Stripe used to justify closing our account. We were penalised for trusting Stripe's own output.

The Appeal Stripe Closed Without Response

We compiled a 16-page formal appeal — 6 exhibits, full timeline, all dispute records, the December 22 support ticket transcript, our new Radar configuration, and WHMCS security hardening proof. Submitted April 22, 2026 via official support channel.

Critical Appeal Ticket — Opened & Closed April 22, 2026

What this shows: Ticket sco_UNm4LKXvgGVmg1 — "Stripe complaint" — opened April 22, 2026 at 15:08. Stripe agent "Harsh" replied the same day with a generic acknowledgment: "we are currently digging into your query." The case was then closed with no substantive response, no decision, no explanation. $7,000 remains held.

What We Fixed — Without Waiting

We didn't wait for Stripe's response. Every security gap was closed the moment the attack pattern became clear:

The Real Financial Damage

Let's be specific about what this has actually cost us — because "account frozen" sounds administrative. It wasn't. It was a cascade of compounding losses:

• Supplier costs paid and unrecoverable — VPS services were delivered instantly. We paid our datacenter suppliers for every fraudulent order before we knew they were fraudulent. Those costs are not refundable.
• Forced refunds on top of supplier costs — We then refunded the fraudulent payments to the cardholders, meaning we absorbed the full amount twice: once to the supplier, once back to the fraudster's bank.
• Disputes we fought and lost — For the cases we contested, we lost to DZ Bank AG and ING Bank N.V. despite submitting evidence — adding dispute fees and time on top of the losses.
• Account frozen mid-operation — $7,000 in legitimate funds from real customers is currently held by Stripe with no release date. This is working capital we cannot use to operate or pay suppliers.
• Complete payment processing disruption — With our Stripe account closed, our entire payment collection pipeline stopped. We cannot accept new orders through our primary payment channel.
• Every appeal ignored — Each attempt to resolve this was met with a generic automated reply. No human review. No decision. No timeline. Just silence and closed tickets.

Our Posts on Reddit Were Deleted by r/stripe Moderators

When Stripe's official support failed us, we turned to the community. We posted our situation on r/stripe — a subreddit that claims to be a space for Stripe users to discuss issues and get help.

Both of our posts were removed by the moderators.

Censored Reddit r/stripe — Our First Post Removed by Moderators

What this shows: Our first post on r/stripe — "Stripe closed my account after 3 years – looking for a reliable alternative (US LLC, non-US owner)" — removed by the subreddit moderators. The post had 12 upvotes and 44 comments before deletion.

The reason given for an earlier removal attempt: "this is not a place for complaints." This is particularly striking — r/stripe is filled with identical complaints from other merchants that remain live. Ours were removed. Both of them.

Censored Reddit r/stripe — Second Post, Also Removed — 37 Comments Silenced

What this shows: Our second post — "Stripe Ban, what is next?" — describing our account suspension after fraudulent payments, asking the community for guidance. This post had 37 comments from engaged community members before being removed.

The removal message is visible: "Sorry, this post has been removed by the moderators of r/stripe."

Two posts. Combined: 12 + 1 upvotes, 44 + 37 = 81 comments worth of community discussion — all silenced. The post remains partially accessible at: reddit.com/r/stripe/comments/1shbm9q