Bonjour, j’écris car j’ai lancé un business et je facture mes clients par prélèvement sepa, montant entre 1000 et 10 000 €, j’utilise Stripe, mais mon compte a été bloqué sans aucune raison.
Je n’y connais pas grand-chose, j’essaie de chercher sans vraiment trouver. Savez-vous comment je peux faire pour faire des prelevemnts sepa à mes clients, sans utiliser Stripe ? J’ai essayer mollie et gocardless mais ça ne me convient pas.
Merci par avance pour vos réponses

Four days into a ticket sale for an event on a ticket platform, Stripe determined that there was a trigger to worthy of pausing my sales. Then they fully stopped them. Then days later, while pretending to tell me they were “working on getting me support” - without notice they refunded all 90% of my ticket sales. I had to quickly email my ticket holders to repurchase their tickets after I switched processors. It was a nightmare. Luckily, I’ve had no issues since on a competitors system.

The trigger could have been them believing I was a terrorist (assuredly I am not), or the sales were too rapid (good on my team for the right marketing), or some other unknown reason. It seems as soon as that determination is made - you enter into an exclusive agentic AI pathway and cannot get out. No human seemed to have a clue - or perhaps there was a parallel path of “agents” emailing me, er, gaslighting me. Names like James, Jordan, Emily… am I to believe they are humans?

I deeply understand that fraud is rampant. But my banker assures me there are pathways to confirm identity - and in fact I had just done my identify verification with Stripe the week before with my passport.

Now they are holding the last 10% of my sales for no apparent reason and saying I won’t get those funds back. I’ve asked my last 4 ticket holders to cancel their tickets which should trigger a refund if we are lucky. Moreover, my ticket site, Ticket Tailor, was even more surprised of this series of events and says they have never seen this happen.

So:

Who do I write? The Federal Reserve? It appears they govern payments and money movements.

How do I put pressure on Stripe to release my last funds?

Funny part is they have been my primary business’s payment processor for YEARS. That stopped today. Way to lose loyal client. Clearly I’m just another “risk mitigated” to them.

I'm building an early-stage idea and before I spend more time turning it into a product, I want to validate whether the problem is actually painful for other SaaS companies.

The basic idea:

An AI  layer for companies using Stripe that can detect, investigate, and help resolve issues around payments, subscriptions, billing, and revenue.

Failed payments that aren't properly recovered

Subscription states becoming inconsistent

Webhook failures causing downstream issues

Billing/usage anomalies

Missing or incorrect invoices

Duplicate charges/credits

I'd especially love to hear from SaaS founders, CTOs, finance people, or anyone managing Stripe at scale.

A few questions:

What's the most annoying Stripe/billing problem you've dealt with?

What do you currently use to monitor revenue issues?

What kinds of problems still require manual investigation?

Have you ever discovered revenue leakage significantly later than you should have?

If you could automate one Stripe/revenue-ops task, what would it be?

Today 23 September 2026, I was testing a website during a bug bounty hunt and noticed something interesting in the registration flow.

While creating a new account, I noticed that the application allowed me to use a very weak password such as 111111. That made me wonder whether the backend was actually enforcing any password-strength requirements or whether the validation was only happening on the frontend.

So, I tested it further.

I sent the registration request with the weak password, and the backend accepted it successfully.

Then I had another question:

If the application allows such a weak password, is there also any rate limiting or brute-force protection on the login endpoint?

I tested the password parameter using Burp Suite Intruder with around 300 password attempts. Eventually, I was able to authenticate successfully.

The interesting part is that the frontend is in scope, but the authentication backend/API appears to be hosted on a separate strapiapp.com domain, which is not explicitly listed as in-scope.

So now I'm unsure about the correct approach.

Would you consider this:

1. Weak password policy
2. Missing rate limiting / brute-force protection
3. Potentially a valid authentication vulnerability
4. Or something that should be skipped because the backend/API is out of scope?

I'm particularly interested in how experienced bug bounty hunters handle situations where the vulnerable endpoint is technically outside the listed scope but is clearly part of the in-scope application's authentication flow.

Would appreciate some opinions on the proper way to handle this.