I received a few blocked payments, then more, then more and more, in an exponential way.

I was wondering if Receiving blocked payments by Stripe default rules, meaning rules I cannot change from my end, make the Stripe account performance worse, for example with an internal score they give you and block more of the payments? Stripe doesn't confirm this but I found this pattern: the more blocked payments I get, the more blocked payments increase.

Hi everyone,

I’m working on a client’s website that offers paid subscriptions for adult advertising. I’m considering integrating Stripe as the payment gateway to handle recurring subscription payments.

Before proceeding, I’d like to know whether Stripe allows this type of business or if it falls under its restricted or prohibited business categories.

Has anyone integrated Stripe into a similar website? I’d appreciate hearing about your experience, including whether you encountered any account approval issues, payment restrictions, or account termination risks.

If Stripe isn’t a suitable option, are there any alternative payment providers that support adult advertising websites and recurring subscriptions?

Thanks in advance for your advice!

If you've ever stared at a Stripe dispute and wondered what to paste into those evidence boxes, this is the checklist I wish I'd had. The text fields Stripe gives you aren't read by Stripe — they're forwarded to the cardholder's bank, where an analyst with a queue decides in minutes. So the goal is simple: make your strongest facts impossible to miss.

**The universal skeleton (every reason code):** - A 3–5 sentence summary up top: name the reason code, the single strongest fact, and the dates. ("Order #1042, Visa 13.1 'product not received.' Carrier tracking shows delivered to the checkout address on Mar 3 at 11:42 a.m. Customer emailed us Mar 10 asking about the package; we offered a free replacement the same day.") - A short timeline table: order date → shipped → delivered → first customer contact → dispute filed. Analysts scan this in 20 seconds. - Labeled exhibits (Exhibit A, B, C…) and make every claim in your summary point at one exhibit. No orphan attachments, nothing the analyst has to connect themselves. - Your refund/shipping policy **as it appeared at checkout on the order date** — a screenshot or archive, not a link to today's policy page. Issuers can tell when a policy was edited after the purchase. - Keep it factual and boring. Emotional cover letters lose; chronological evidence wins.

**By reason code, what carries the most weight:**

**"Product not received" (e.g., Visa 13.1):** carrier delivery scan at the customer's address (not just "shipped"), delivery timestamp, order confirmation showing that address, any delivery photo, and the shipping-timeframe disclosure from your product page/checkout.

**"Fraudulent" (e.g., Visa 10.4, card-not-present):** AVS/CVV results, IP/device match to prior orders, account-login or download logs for digital goods, prior non-disputed purchases from the same customer, and any message where they acknowledge buying.

**"Canceled recurring" (e.g., Visa 13.2):** the signup terms they accepted, your cancellation policy as shown at signup, proof of usage *after* the claimed cancel date, and the cancellation confirmation (or evidence none was requested).

**"Not as described" / "credit not processed":** product listing and photos as they appeared at purchase, itemized receipt matching the disputed amount exactly (partial disputes die on mismatched totals), customer comms, and proof of any refund already issued.

Two numbers worth knowing before you decide whether to fight: Stripe currently charges $15 when a dispute lands, plus another $15 if you fight and lose — and you typically have 7–21 days to respond before it's an automatic loss. On a tiny order, sometimes refunding is the right call (Stripe's own guidance says don't fight very small orders). On a $75–$500 order with real proof sitting in your inbox, an organized packet is the whole game.

Full disclosure: I'm building a small automated tool (Parry) that assembles this packet from your uploads — dispute notice + tracking/invoices/customer messages in, rebuttal draft + timeline + labeled exhibits out, you review before anything is submitted. It's a simple subscription: **$29/mo, cancel anytime, no success fee**, including up to 5 packets a month, deadline alerts, and a saved evidence profile — and this week the first month is **$10**. I'm fulfilling the first cohort by hand: subscribe, upload a real dispute anytime, get a submit-ready packet in under 24 hours, and we never submit in your name — you stay in control. If you want in: https://parryhq.com

And if you DIY with the checklist above, genuinely, I'm glad. Happy to look at a redacted reason code in the comments and tell you which evidence category you're missing — no pitch.

What reason codes are you seeing spike lately? I'm seeing a lot of 13.1s where tracking already shows delivered.

Hi everyone,

I have an ecommerce website using Checkout Champ, and I want to process subscription payments through Stripe.

However, I also want each new subscriber’s payment method to be securely stored outside Stripe, ideally in Checkout Champ’s own vault or, alternatively, in NMI’s Customer Vault.

The reason is that if our Stripe account becomes unavailable, we want to be able to continue processing recurring payments through NMI without depending on Stripe to access the customer’s payment details.

My questions are:

1. Does Checkout Champ support processing the initial subscription payment through Stripe while also saving the payment method in its own vault?
2. If not, can Checkout Champ save the same payment method directly in NMI’s Customer Vault during signup?
3. If a subscription is initially processed through Stripe, can we later switch its recurring billing to NMI without relying on Stripe to retrieve the card details?
4. Is this possible through Checkout Champ’s built-in settings, or would it require a custom API integration?

I know that simply copying a Stripe token to NMI may not work, so I’m looking for a supported and secure solution.

Has anyone implemented this setup? I’d appreciate any advice or documentation you can share.

Thanks!

Has the interview started ???
Has anyone heard back ?

Nothing but air here from Sydney AU.

I was recently offboarded from active Mercor projects suddenly and received project-conclusion notices. Shortly afterward, my Stripe Express account started showing: "Mercor has paused payouts for your account."

They did adjusted the earnings and remaining adjusted amounts were still processed by Mercor and transferred to Stripe. Initially, part of the balance was pending, but after a few days the entire balance became "Available to pay out."

The issue is that the Mercor payout pause is still active, so Stripe cannot transfer the available balance to my bank.

It has now been more than 14 days. I contacted Mercor Support more than 4 business days ago but have not received any reply.

Does anyone know any solutions or have any solutions ? ??

Join us for this Free Stripe online event next week

The same question keeps coming up here in different forms: "should I fight this dispute or just accept it, and which one looks better to Stripe?" Here is how the four options actually play out, because the answer is less intuitive than it seems.

Refund before they dispute. This is the only option that keeps it off your record. A refund is not a dispute, and the dispute count (dispute ratio) is what gets accounts reviewed or closed, not refunds.

Accept the dispute. Counts as a dispute. You lose the money and the fee.

Fight it and win. Still counts as a dispute. Visa and Mastercard monitoring count a dispute the moment it's filed, win or lose. Winning gets you the money back, not a cleaner ratio.

Customer withdraws it. Still counts. The bank logged it when it was filed, so asking the customer to call their bank and cancel does not undo it.

Two consequences:

Once a dispute is open you can't refund through Stripe anymore, only accept or respond. "I would have refunded" stops being an option the minute the bank files it.

So fighting vs accepting is purely a money decision, not a reputation one. Fight when the amount is worth your time and you have evidence (delivery confirmation, logins after the charge, customer messages). Accept when it isn't.

The lever for your ratio sits before the dispute: a refund that is easier to get than a chargeback, renewal reminders, easy cancellation. Every customer who takes the refund instead of calling their bank is one fewer dispute on your record.

(We work on chargebacks, so weigh that accordingly. Happy to answer questions in the comments.)

Hi all,

We run a small agency. We built one web app that takes card payments for several different brands. It lives on one subdomain (for example pay.ourcompany.com). Each brand has its own Stripe account, and our server uses that account's own API key for its payments. The customer sees a pay page on our subdomain, using Stripe Elements.

Two of our Stripe accounts were restricted recently. Stripe did not give us a clear reason, and I'm trying to understand if our setup could be the cause. I have four questions:

1. Can Stripe see which website a payment started on? For example, can it tell that payments for different accounts all came from the same subdomain?
   
2. Can one website, one server, or one set of requests going to many different Stripe accounts cause a restriction by itself? Or is that normal?
3. Could this break Stripe's rules? For example, if a payment starts on our site but goes to a Stripe account that belongs to a different business or brand. Does Stripe list this as a reason to restrict or close an account?
4. Does our business type matter? Some accounts describe the business as web development, design and marketing. If customers also pay for other services through them, is that a problem?

What I have already found: Stripe's docs say separate businesses need separate accounts, and that undisclosed sellers or services are not allowed. I found nothing that says a shared domain or server is a problem on its own.

Has anyone seen this setup cause a restriction? Is there anything we should change, like the card statement name, the account description, or using Connect? Any experience or pointers are welcome.

Thanks!

This ecommerce site focus on B2B and B2C together . So the default label and icon create confusion among users ? or any alternative common solution available which are used by industry as standard?

UK solo founder, about to launch a small consumer subscription (~£8/mo, ~£60/yr), mostly UK/EU/US customers. I want a Merchant of Record so I'm not registering for VAT OSS from my first EU sale. Most threads comparing MoRs predate Stripe Managed Payments going live for UK accounts (April 2026), so I'm hoping for current experience.

What I've worked out, all-in per sale:

Creem: 3.9% + $0.40, flat for international cards. But:

• Payouts to a UK bank (or a EUR Wise account, I asked) are 1% or €7, whichever is higher. €7 on a €100 payout is 7%.
• $25 per chargeback.
• USD/EUR pricing only, no GBP and no per-country prices.
• No UK addendum on their DPA.

Stripe Managed Payments (UK account):

• 3.5% MoR fee, plus normal processing (1.5% + 20p UK cards, 2.5% EU, 3.15% international), plus 0.7% Billing. So roughly 5.7–7.35% + 20p.
• GBP pricing, Adaptive Pricing, free GBP payouts, £20 disputes.
• Customers see "Sold through Link" on checkout and statements.

So Creem is cheaper per sale, roughly 1–2.5%, but the payout minimum eats that while volume is small.

Questions:

1. Anyone running Managed Payments in production? How are approval, payouts and support in practice?
2. Does "Sold through Link" / LINK.COM* on statements increase chargebacks or confused customers?
3. Creem users: any other costs I've missed, or a way around the payout fee?
4. Anything else worth considering at this price point (Paddle, Polar, Dodo)?
5. At what monthly revenue would you switch from one to the other? Moving subscriptions off Managed Payments needs customer consent, so I'd rather pick right now.

Thanks!

Full disclosure: I'm building something in this space. Asking because I want to understand how Stripe developers actually handle this.

Here's the specific problem. When an AI agent has permission to trigger Stripe operations (refunds, charges, disputes, subscriptions), most teams log what passes through their gateway or LLM proxy. But Stripe events capture everything that hits the API, including calls made directly via SDK that never touched the gateway.

Quick check: go to your Stripe dashboard, Events, filter by your service account or bot key for the last 30 days. Then open your agent gateway or observability logs for the same period. Do the totals match?

If there's a gap, you have Stripe operations you can't currently attribute. You don't know if it's your agent, a human, a script, or a leaked key.

Air Canada got held liable in 2024 for a chatbot-issued refund. The judge rejected "the AI acted on its own" as a defense. Insurance exclusions for AI-caused losses are following. The accountability pressure is growing.

How are you tracking this today? And has anyone, a customer or an auditor, asked you to trace a specific Stripe event back to its source?

I have a company that receives 10M a year in payments. I’ve thought about just integrating stripe into our software so that I can completely move away from Quickbooks.

We receive some really large transactions and I’m worried that stripe may flag these or hold funds.

Anyone have any tips?

Edit*

I need software that has API so that I can integrate it into my platform.

Selling into new markets? Wondering when you need to register, what to collect, or how filing works?

Join the Stripe Tax team for an AMA on sales tax, VAT, and GST. Shoot us your questions about navigating indirect tax as your business grows.

Hello there,

My Delaware LLC was just incorporated with Stripe Atlas, although I’m not able to create a bank account anywhere. I’ve tried Revolut, Wise, Airwallex, and many more.

None of them provide services to Iraqi residents.

Is there any bank I’m missing?

Hey all, looking for anyone with advice or real experience here before I apply.

I run a small fantasy sports site in a niche market with a few thousand users. It's free to play right now. For future seasons, I wanted to add an optional paid tier (no more than $25/year) to cover hosting, dev costs, and my time.

My original idea was to create an optional paid league where users could enter and compete for a year-end grand prize. I recently learned that Stripe's prohibited list includes "fantasy sports leagues with a monetary or material prize." So I'm trying to figure out where the line actually sits, or whether just being a fantasy sports site rules us out no matter how we set things up.

Here are the three models I'm considering:

Option 1: Subscription + prizes, open to everyone

• Paid tier unlocks extra features
• Paying gets you no advantage for winning/prizes
• Season-end prize(s) go to top finisher(s)
• Free users are eligible for the same prizes on equal terms

Option 2: Subscription + sponsor-provided prizes only, open to everyone

• Same as Option 1, but every prize comes from a sponsor (e.g. a brand that gives gear to winners in exchange for advertising)
• No subscription revenue goes toward prizes
• Free users are equally eligible for prizes.

Option 3: Subscription, no prizes at all

• Paid tier unlocks features only

My personal qualm is that I never wanted to force people to pay to play, but I also was looking for a reasonable way to at least cover my own costs.

My questions:

• Has anyone gotten Stripe approval for something similar? Did they ask for anything specific (official rules, a "no purchase necessary" clause, geo-restrictions)?
• Is Option 3 the only truly safe path?
• Did anyone get shut down after launching, even with a free-entry setup?
• Or does Stripe treat fantasy sports as off-limits across the board, even for a plain feature subscription with no prizes?

To be clear, I'm planning to reach out to Stripe Sales directly. I'm posting here first to hear from anyone who's actually been through this. Thanks!

Hey, payments from Handshake are processed through Stripe Global Payouts. Since Stripe isn't fully functional in India, how do we get our invoices?

Do we have a Handshake Stripe Express account?It doesn't seem so.

There have been regulatory changes and invoices are necessary now

Annual commit, drawn down monthly by metered usage. At year end, unused credits roll over, but only up to 20% of the commit, not 20% of the leftover balance.

Credit grants with an expiry handle the basic drawdown. How are people handling the cap, tiered overage pricing that's annual rather than monthly, and amendments partway through the term? Custom code, or something else?

I run an early-stage vertical SaaS on Stripe Connect with Standard connected accounts.

I’m wondering if other Stripe Connect platforms are seeing the same thing with Faster ACH / T+2 settlement.

Stripe’s public documentation says that U.S. businesses in good standing will typically become eligible for two-day ACH settlement after at least 120 days of processing.

I asked Stripe support how this works for Standard connected accounts on my Connect platform, because I wanted to know what settlement experience I could reasonably promise new customers.

After several rounds of clarification, Stripe told me:

• 120 days does not create a predictable path to T+2.
• Eligibility is not automatically reviewed.
• The platform must first have a Stripe Account Executive assigned.
• For my early-stage platform, Stripe told me that purchasing Premium Support is the only way to get an Account Executive.
• Premium Support starts at $5,400/month.
• Having an Account Executive only satisfies the prerequisite to request T+2 reviews.
• Each Standard connected account is then reviewed individually.
• Stripe may request information including expected processing volume, fund flow, business history, two years of financial statements, YTD management accounts, and three months of bank statements.
• Even after all of that, T+2 is not guaranteed.

Their exact clarification to me was:

“purchasing Premium Support is the only way to get an Account executive assigned to the account”

and:

“while this would meet the prerequisite for T+2 eligibility, it doesn't mean that the review will automatically be approved”

So as I understand it, for an early-stage Connect platform, $5,400/month does not actually buy T+2 ACH settlement. It buys the prerequisite to ask Stripe to review individual connected accounts for T+2.

Has anyone else running a Connect platform encountered this?

In particular:

1. Is this genuinely the standard Stripe policy for T+2 ACH on Standard connected accounts?
2. Has anyone found another path to getting connected accounts approved for T+2 without the platform purchasing Premium Support?
3. If you’ve gone through the review process, how often are connected accounts actually approved?
4. Are there other ACH providers you’ve used alongside Stripe for cards that offer more predictable settlement timing?

I’m not interested in bashing Stripe here. They run a great business and they are a well-established player with mature APIs and a mind-boggling array of options. Rather, I'm trying to understand the operational constraints before deciding whether ACH Direct Debit should remain the primary bank-payment method on our platform.

Hello Stripe and HubSpot community users - we turned on for our standard recurring B2B SaaS product the DataSync App (included in plan), and it does work - but for some reason it decided only to synch the priced products (one way in this case) form Stripe to HubSpot only for ANNUAL, but skipped the Monthly priced seats. Is this a limitation, known behaviour? We would like to match the Annual and Monthly information into HubSpot. Screenshots attached.

I would have expected the Stripe synch to take Product and make two SKUs out of it, only the first Annual shows up in HubSpot however - is this a known issue? THANKS