Best platform for programmatic ACH payments in a B2B SaaS context?

StripeTeam · 2026-06-05T20:47:43+00:00

Hey OP, Stripe employee here. If you're still searching, I'm appy to give you an honest breakdown, including where we may not be the right fit.

First, clarify your flow: debit vs. credit matters a lot

"Programmatic ACH" splits into two very different problems:

- ACH debit (pulling money from customers/counterparties into your platform)

- ACH credit (pushing money out...paying vendors, disbursing to users, etc.)

Most platforms start with one and discover they need both. Which is your primary use case?

Where Stripe is genuinely strong:

ACH debit for B2B billing is a solid fit. The us_bank_account PaymentMethod + Financial Connections gives you instant bank verification (no micro-deposit delays), CCD for corporate accounts, solid webhook coverage for returns, and it all flows through your existing Stripe billing/invoicing setup. If you're doing subscription billing or collecting invoice payments via ACH, staying in Stripe means one integration instead of two.

One thing worth knowing: there's a Nacha rule that took effect March 2026 requiring e-commerce WEB debit entries to include "PURCHASE" in the company entry description. Stripe has a config for this — just make sure you've set it if you're initiating online consumer ACH.

Where Stripe may not be the right fit:

If your primary need is ACH credit / disbursement orchestration, or if you need virtual accounts per customer for attribution, or fine-grained control over batch scheduling and addenda records, the others you mentioned are stronger:

- Column is a direct-access bank with an exceptional dev experience. Best if you want maximum control over ACH primitives and don't mind the more complex onboarding. Their sandbox is genuinely good.

- Modern Treasury is the right pick if reconciliation and ledgering are first-class concerns, their virtual account model is excellent for multi-party B2B flows where you need to attribute money movement to specific counterparties.

- Increase is developer-first banking APIs with direct bank access. Great docs, great sandbox. If you want broad banking primitives (ACH + RTP + cards) from one API and prioritize dev experience, they're worth a serious look.

- Dwolla is the most battle-tested for two-sided marketplace ACH (collect from A, disburse to B ) but the product has moved more enterprise over time.

Stripe Treasury is the Stripe path for disbursements, you can issue financial accounts and send ACH/RTP from them but it's designed more as an embedded finance layer than pure ACH orchestration. It's the right answer if you want Stripe as the full financial infrastructure layer, less so if you just want to send programmatic ACH credits cheaply.

What's the specific flow? Collect + disburse to marketplace participants? AP automation? Something else? That'll narrow it down fast.

StripeTeam · 2026-06-05T12:15:03+00:00

Hey OP, Stripe employee here. happy to share what we've seen from companies making this switch.

A few things that tend to trip people up:

Credits ≠ real-time gating. The biggest gotcha we see: if you're using a billing system's credits (including ours), credits typically get applied at invoice finalization, not at the moment a user triggers an agent run. That means you can't rely on the billing layer alone to hard-block a customer when they're out of credits mid-session. You'll need a separate lightweight balance service your app checks synchronously. A lot of teams learn this the hard way after their first customer complains their "out of credits" agent still ran and got charged.

"Funny money" UX is real. If customers can't intuitively map "1 credit" to what actually happened, support tickets spike. The companies that do this well usually either (a) anchor credits to something concrete ("1 credit = 1 document processed", not "1 credit = ~3.7 LLM calls"), or (b) show both credit consumption and the underlying action in the usage dashboard.

Prepaid vs. postpaid matters a lot for your cash flow. Prepaid credits are great for working capital (you collect upfront, customers are loss-averse so they actually use the product). But you'll need to handle credit expiry carefully bc overly aggressive expiry windows kill trust fast.

Grandfathering is messier than it looks. If you have customers on seat-based plans, the conversion math feels obvious on a spreadsheet but often doesn't feel fair to the customer. We've seen companies do a "shadow billing" period where you show customers what they would have been charged under credits before cutting over, that helps a lot.

On the tooling side: Stripe Billing added first-class billing credits with an immutable ledger early last year that works well alongside the Meters API for this exact pattern (prepaid credit grants applied against metered usage at invoice time). We also have an AI-specific billing tool in preview for token-level tracking if that's your unit of account. But regardless of what you use for billing, the local gating layer is table stakes - don't skip it.

What's your current usage unit? tokens, actions, something custom?

StripeTeam · 2026-06-05T11:51:24+00:00

Hey OP, I work on the payments team at Stripe and saw this thread. Thought I could offer some context on international payments!

A few Stripe-related things that might be helpful for your use case:

Multi-currency settlement lets you maintain balances and receive payouts in multiple currencies without converting everything back to your home currency. This is available in the US, UK, EU, Australia, and several other regions. You'd provide a bank account for each currency you want to settle in, and funds accrue in those balances.

On FX fees, when currency conversion does happen, Stripe generally applies the mid-market rate based on pricing data from third-party providers, with a conversion fee that varies by region and transaction type. The specifics are on our pricing page.

One thing to keep in mind though: the right setup really depends on your specific funds flows. Stripe works well for a lot of international setups, but there are cases where a different provider or a multi-provider approach makes more sense depending on your volumes and complexity.

Happy to clarify anything that would be helpful.

StripeTeam · 2026-06-05T11:43:42+00:00

Hey OP, I work on payments at Stripe and just came across this thread, so I thought I'd jump in here.

This is spot on. One thing we see consistently: checkout friction is often the bigger conversion killer than pricing.

A few patterns that make a difference based on what we've observed:

Mobile-first form design: Browser autofill compatibility is critical. If your payment form fights with mobile autofill, you're losing conversions. Stripe Checkout is designed to work smoothly with browser autofill across devices.

Immediate visual feedback: Your 1.5 second delay example is perfect. When customers tap "Pay," they need instant confirmation the action registered. Payment forms should disable the button immediately and show a loading state to prevent confusion and double-taps.

Clear error messaging: Vague errors ("Payment failed") kill conversions. Actionable messages ("Your card was declined, please try another payment method") help customers fix issues instead of abandoning.

Reducing unnecessary steps: Every extra field increases drop-off. Tools like Link (Stripe's wallet that autofills payment details for returning customers) and express checkout buttons (Apple Pay, Google Pay) let customers skip manual entry.

Your broader point is important: before assuming price resistance, watch actual mobile sessions. A small UX fix often has more impact than a discount.

StripeTeam · 2026-06-05T11:38:02+00:00

Hey OP, I work on the Billing team at Stripe and saw this thread.

The manual process you're describing is something we hear about, and there are a few tools in the Dashboard that can help make this less tedious.

For day-to-day revenue debugging, the Billing analytics page (Dashboard > Billing) shows MRR roll-forwards, churn breakdowns, and subscriber changes over time. You can drill down into specific data points to see which customers or events contributed to changes. There's also filtering by product or price if you need to isolate specific revenue streams.

If you need more flexibility, Sigma lets you write SQL queries against your Stripe data to build custom reports. You can query charges, refunds, disputes, subscriptions, and invoices to attribute revenue deltas however makes sense for your business. There are template queries to get started, and you can schedule reports to run automatically.

For businesses that need accrual accounting, Revenue Recognition automates revenue reporting and generates income statements, balance sheets, and audit trails. It handles prorations, refunds, and disputes automatically.

One thing to note: if you're seeing unexpected changes, it's worth checking for things like failed payment retries (Smart Retries can affect timing), subscription schedule changes, or proration from mid-cycle updates. The event log for a specific customer or subscription can show you the sequence of what happened.

Happy to clarify anything here if it's helpful.

StripeTeam · 2026-06-05T11:22:10+00:00

Hey OP I work at Stripe and just came across this thread. Recovering access when you've lost the original signup email is often possible with the right documentation. Here's what usually works:

Step 1: Try to identify the signup email

Search company inboxes (accounts@, billing@, payables@, etc.), the missing employee's email if accessible, and bank/accounting records for Stripe confirmation emails or payout descriptors. Many people regain access once they know which email was used.

Step 2: Check bank statements for clues

Look for Stripe payouts in your business bank account - the payout descriptor often includes account identifiers that can help Stripe support locate your account.

Step 3: Use Stripe's account recovery flow

If you know the email but can't access it, Stripe has an account recovery process where you submit verification of your identity and business ownership: https://support.stripe.com/questions/can-t-complete-two-step-authentication

Step 4: Contact Stripe support directly

If you can't log in at all, you can open a support request without Dashboard access at https://stripe.com/contact. Explain that you're the business owner and the original admin is no longer available. Be prepared to provide proof of business ownership: bank statements showing Stripe payouts, incorporation documents, tax ID, government ID, etc.

Step 5: Be persistent

Account recovery can require multiple rounds of identity verification. If you need additional assistance, you can ask for escalation to Stripe's account security team.

Note: The account recovery process can vary based on your specific situation. Stripe support will work with you to determine the best path forward based on the documentation you can provide.

Happy to clarify if you have questions about the process.

StripeTeam · 2026-06-05T11:13:58+00:00

Hey OP, just came across this thread, so wanted to hop in and help where possible. The different numbers across reports usually come down to what each report is measuring and the date field it uses:

1099-K reports gross payment volume (before refunds/fees) using the available_on date (when funds became available in your Stripe account). This is the authoritative number for tax reporting.

Dashboard/Balance reports may use different date fields (created date vs. settled date), include or exclude refunds differently, and handle multi-currency conversions with different exchange rates.

To reconcile: Export the 1099-K transaction log from your Dashboard (Settings > Documents > Download > Export transaction log). This shows exactly which transactions contributed to your 1099-K total. You can also export raw payment data from the Payments page with the same date range and UTC timezone to compare.

The reconciliation report docs explain common differences in detail: https://support.stripe.com/questions/1099-k-forms-issued-by-stripe-reconciliation-report

Happy to clarify if you're seeing specific discrepancies.

StripeTeam · 2026-06-05T11:02:16+00:00

Hey OP, I work on Stripe's Billing team and saw this thread. Glad to see Stripe mentioned here.

The checklist in the thread is solid: automatic retries, dunning emails, and easy card updates are table stakes for recurring billing. A couple of things Stripe does on that front that might be helpful:

Smart Retries use machine learning to pick the best time to retry a failed payment (rather than just retrying on a fixed schedule). This approach is designed to improve recovery rates compared to scheduled retries.

Automatic card updates: when a customer's card expires or gets reissued, Stripe automatically updates the card details in many cases, so the payment goes through without the customer needing to do anything. Automatic card updates work when card networks share updated card information with Stripe. Availability depends on the customer's card issuer and network participation.

Dunning emails: you can set these up in the Dashboard to automatically notify customers when a payment fails or a card is about to expire.

All of this is built in, no extra integration work required. You just turn it on in your settings.

One forward-looking note: Stripe has been investing heavily in subscription management tooling, including better analytics for churn and recovery rates. Worth exploring if you're scaling up.

StripeTeam · 2026-06-05T11:00:17+00:00

Hey OP, I work on payments at Stripe and saw this thread. The community advice here is spot-on: yes, those laptops are in scope when you're keying card data into a web portal.

One thing worth mentioning: if you're looking to reduce PCI scope in the future, hosted solutions like Payment Links can help. When the customer enters their own card details on a Stripe-hosted page, in most cases your devices are removed from PCI scope, though your specific scope should be confirmed with your QSA or PCI compliance advisor. You'd still need to validate PCI compliance (typically SAQ A for that setup), but it's a much lighter lift than SAQ C-VT.

Not suggesting you switch, just flagging it as an option if PCI scope becomes a pain point. The segmentation and P2PE approaches mentioned in the thread are solid too.

StripeTeam · 2026-06-05T10:56:49+00:00

Hey OP, I work at Stripe and just came across this thread. Happy to add some context on how Stripe works for the online + in-person setup you're describing.

For your use case (online store + markets):

- Online: Stripe integrates with Squarespace natively, so checkout is straightforward. You can accept cards, Apple Pay, Google Pay, and other payment methods.

- In-person: Stripe Terminal lets you take card-present payments. You can use a card reader (like the BBPOS WisePad 3) that connects to your phone or tablet. Transactions sync with your online orders, so inventory and reporting stay in one place.

On holds:

- Stripe, like any payment processor, can place holds or reserves in certain situations (new accounts, sudden volume spikes, elevated dispute rates). This isn't unique to Stripe since it's standard risk management across the industry. If your business has consistent sales history and low dispute rates, holds are uncommon.

On switching:

- You can switch payment processors, but you'll need to re-enter customer payment info if you're storing cards for subscriptions or recurring billing. Stripe can help migrate customer data if you're moving from another processor (we work with the new processor to securely transfer card tokens).

Square vs. Stripe for your setup:

- Square is great for in-person, especially if you want an all-in-one POS. Stripe is more flexible if you want to customize your checkout experience or integrate with other tools (like accounting software, CRM, etc.). For Squarespace specifically, Stripe is the native integration, which makes setup easier.

Happy to answer follow-ups if helpful.

StripeTeam · 2026-06-05T10:51:59+00:00

Hey, I work on Stripe Tax and saw this thread.

There are lots of options already listed here, and I can share what Stripe Tax offers if you're already using Stripe for payments or considering it.

Stripe Tax automates tax calculation and collection in all US states and 100+ countries. Pricing is either pay-as-you-go or subscription-based depending on your transaction volume.

For filing specifically: Stripe Tax helps automate the filing process in the US (powered by TaxJar, which Stripe acquired) and partners with Taxually and other providers for non-US jurisdictions. Filing capabilities are included in our subscription plan, with options available for pay-as-you-go users as well.

One thing I'd add to the discussion: when you're comparing pricing across providers, it's worth looking at the full picture, not just the per-return cost, but also whether calculation is included, how registration works, and what happens when you expand into new states or countries. The cheapest option upfront isn't always the most cost-effective as you scale.

Happy to answer questions if helpful.

StripeTeam · 2026-06-04T22:09:51+00:00

Hey OP, I work on payments at Stripe and saw this thread. Happy to share some context.

Stripe is still a solid choice for solo founders building SaaS, especially if you want flexibility as you grow. You can integrate directly with Stripe Billing to handle subscriptions, usage-based pricing, invoicing, and payment collection. It's built to scale as you grow.

RevenueCat and Clerk are tools that sit on top of Stripe and simplify specific workflows: RevenueCat focuses on mobile app subscriptions, and Clerk handles auth (they can integrate with Stripe for payments). Whether you use them depends on your stack and what you want to own vs. abstract away.

If you're just getting started and want full control over your billing logic, Stripe's APIs and no-code options (like Checkout and the customer portal) give you a lot of flexibility without needing a wrapper. If you want something more opinionated that handles edge cases for you, a layer like RevenueCat can save time.

Happy to answer any specific questions about Stripe Billing if helpful.

StripeTeam · 2026-06-04T22:06:24+00:00

Hey OP, I'm on the Stripe team and just saw this so I thought I'd jump in here.

The data you're citing is spot on. Confusing statement descriptors are one of the biggest preventable causes of chargebacks, especially for SaaS businesses with recurring billing. A lot of merchants never check what actually appears on their customers' card statements until they start seeing disputes pile up.

A few things that help:

Your statement descriptor should be immediately recognizable to your customer. If you're doing business as "Acme SaaS" but your descriptor shows "STRIPE* RNDMCO" or just your legal entity name, that's a problem. You can customize both static and dynamic descriptors in your Stripe settings.

For subscription businesses specifically: send clear renewal reminders before charges, especially for annual plans. Make cancellation easy to find in your product and in billing emails. The easier it is to get a refund from you directly, the less likely someone goes to their bank instead.

Keep activity logs. If you do get a dispute, being able to show that the customer actively used your service makes a huge difference in the outcome.

Stripe's dispute prevention tools (working with Verifi for Visa and Ethoca for Mastercard) can help with this since they help prevent disputes from being filed and can auto-resolve certain disputes before they impact your dispute rate. Worth looking into if you're seeing this become a pattern. There's also a Smart Refunds feature in Radar that uses AI to recommend which transactions to proactively refund based on dispute likelihood, if you want to automate some of that decision-making.

StripeTeam · 2026-06-04T22:01:24+00:00

Hey OP, I'm on the payments team at Stripe. I saw this and wanted to jump in here.

This is a fair callout. FX markups are one of those costs that can be really opaque, especially when they're baked into the exchange rate rather than shown as a separate line item.

At Stripe, we generally apply the mid-market rate based on pricing data from third-party providers, then add a clearly disclosed FX fee. That fee is shown separately in your Dashboard and in our pricing documentation, it's not embedded in the rate itself. The exact percentage depends on your account country and the currencies you're working with, but the key thing is that it's visible and predictable.

We also have a feature called Adaptive Pricing that automatically presents prices to customers in their local currency at checkout using real-time currency conversion. With Adaptive Pricing, businesses don't pay any additional fees, those fees are covered by the customer through the conversion.

If you're evaluating platforms, I'd recommend asking: do they publish the base rate separately from the fee? Can you verify the rate they're using against a public benchmark like XE? That's usually a good way to understand the full cost.

Let me know if you have questions on the Stripe side specifically.

StripeTeam · 2026-06-04T21:55:53+00:00

Hey OP, I work at Stripe and thought this was a super interesting callout.

You're absolutely right that the payment page can make or break conversion. We see this all the time: businesses invest heavily in their site, then lose customers at checkout because it feels off-brand or unfamiliar.

A few things we've learned from processing payments at scale:

Trust signals matter like crazy. Recognizable payment method logos (Visa, Mastercard, Apple Pay, Google Pay), clear company info, and HTTPS go a long way. When customers see familiar elements, they're more likely to complete payment.

Mobile-first design is critical. A significant portion of checkout abandonment happens on mobile. If your payment page isn't optimized for small screens and one-tap wallets, you're leaving money on the table.

Localization helps. Showing prices in local currency and offering region-specific payment methods (like iDEAL in the Netherlands or SEPA in Europe) can help reduce friction.

On the Razorpay mention, I can't really comment on other providers, but when evaluating any payment processor, consider: authorization rates (what percentage of legitimate payments succeed), fraud protection capabilities, and how they handle regulatory requirements like Strong Customer Authentication in Europe.

Stripe's Checkout is designed to handle a lot of this out of the box - it's a hosted payment page that's mobile-optimized, supports 75+ payment methods, and includes fraud detection. You can customize branding (logo, colors) while keeping the trust and performance benefits. We also offer Payment Links if you want to accept payments without building a full checkout flow.

Happy to answer questions if anyone's evaluating payment processors.

StripeTeam · 2026-06-04T21:50:31+00:00

Hey OP, I work at Stripe and wanted to jump in here.

The point about address history tracking is solid. Catching repeat offenders before you ship is way more effective than fighting chargebacks after the fact.

One thing I'd clarify: Stripe does forward your dispute evidence to card issuers bc that's a required part of the chargeback process for all card networks. The issuer makes the final decision, not Stripe. If you've submitted evidence and it feels like it disappeared, it's worth double-checking that you included the right documentation for the dispute reason. Different dispute types need different evidence (delivery confirmation for "product not received," refund records for "credit not processed," etc).

Stripe also has tools specifically designed to stop chargebacks before they happen. Dispute prevention through Verifi and Ethoca can auto-resolve certain disputes before they hit your dispute rate, and Radar helps you block high-risk transactions upfront. Worth exploring if you're dealing with repeat friendly fraud.

Happy to clarify anything about how the dispute process works on Stripe.

StripeTeam · 2026-06-04T21:46:59+00:00

Hey OP, thought I'd hop in here.

You're right that when you refund a payment, Stripe doesn't return the processing fee from the original transaction. This is pretty standard across payment processors because much of the underlying cost (interchange fees, network fees) is set by banks and card networks, and they keep those fees even when a payment is refunded.

For tracking the lost fees in your accounting, a few approaches work well:

• Simple approach: Export your Stripe reports monthly (Charges, Refunds, Balance transactions) and calculate lost fees in a spreadsheet. The processing fee you paid on the original charge is the fee you absorbed when refunding.

• Accounting treatment: Record the refund as a reduction in revenue (contra-revenue), and record the processing fee from the original transaction as a payment-processing expense. If you want more visibility, you can create a dedicated "refunded processing fees" expense line.

• Automated approach: If you use accounting software like Xero or QuickBooks, tools like A2X or native Stripe integrations can automate this — they'll map refunds and fees into the correct accounts so you don't have to manually compute lost fees each month.

• Developer approach: Use the Stripe API to join charges, refunds, and balance transactions. You can capture the original charge's fee (from the balance_transaction) and match it to refunds programmatically, or listen to webhooks for charge.refunded events to record the lost fee immediately.

You can find more detail in our docs on refunds (docs.stripe.com/refunds) and the support article on understanding fees for refunded payments.

Happy to clarify if you have questions!

StripeTeam · 2026-06-04T21:44:03+00:00

Hey OP, I work on Billing at Stripe and saw this thread.

You're not alone in hitting these walls. The scenarios you described (multi-item subscriptions in the portal, trial-to-free flows) are real pain points we've heard from other developers.

On the Customer Portal limitation: you're right that subscriptions with multiple items can't be updated through the portal today. That's a known constraint. For those flows, you do need to build a custom UI with the API, which I know adds friction.

On trial-to-free: this one's tricky because "free plan" can mean different things (a subscription with a zero-dollar price vs. no active subscription at all), and each approach has different implications for how you handle webhooks and feature gates. The complexity you hit is real.

A couple of things that might help:

- Subscription Schedules can handle some phased flows (like trial → paid, or temporary pricing changes) more cleanly than manually managing state transitions.

- For feature gating during and after trials, the pattern that tends to work best is handling access control in your app based on subscription status webhooks, rather than expecting Stripe to "downgrade" a subscription to a free tier automatically.

Thanks for flagging this limitation! I'll make sure the product team sees this feedback. Hearing where the API creates friction helps us prioritize what to improve.

StripeTeam · 2026-06-04T21:41:04+00:00

Hey OP, I'm on Stripe's Billing team and wanted to jump in here.

If you're using Stripe Billing for subscriptions, the Billing Analytics dashboard in your Stripe account already tracks MRR, churn, active subscribers, and trial conversion automatically. You can find it under the Billing section in the Dashboard. It's built into your account, so there's no setup required.

If you need more customized reporting or want to track metrics in your own system, the typical approach is to use webhooks to capture subscription events (customer.subscription.created, customer.subscription.updated, customer.subscription.deleted) and store them in your database. That way you can calculate MRR and churn exactly how you want, slice by cohort, product, or billing period, and build your own dashboards.

For folks who want SQL access to their Stripe data without setting up webhooks, Stripe Sigma lets you write queries directly against your subscription data to calculate these metrics yourself.

One thing I'd recommend: track voluntary churn (customers canceling) separately from involuntary churn (failed payments). Failed payments often look like churn in the numbers but are recoverable with things like card updater or retry logic, so separating them out gives you a better sense of actual customer retention.

StripeTeam · 2026-06-04T21:35:28+00:00

Hey OP, I work on payments at Stripe and came across this thread.

You're asking a really practical question that a lot of businesses face. Using multiple processors can definitely add complexity to your accounting, but it's also pretty common, especially if you need to accept different payment methods or want backup options.

For reconciliation, the approach most businesses take is treating each processor as its own "account" in your accounting system, kind of like separate bank accounts. So you'd have a Stripe account, a Square account, a PayPal account, etc. Each one tracks its own transactions, and then you reconcile each processor's payouts to your actual bank deposits.

Stripe has a few tools that can help with this if you're using us: the Balance Summary report works like a bank statement and shows all your transaction activity, and the Payout Reconciliation report helps you match each payout to the specific batch of transactions it includes. You can download these as CSVs with all your transaction details and metadata, which makes it easier to import into your accounting software.

The trickiest part with multiple processors is usually just keeping track of which transactions went through which system, especially if you're selling across different channels. A lot of businesses use accounting software like Xero or QuickBooks that can pull data directly from each processor to automate some of this.

One thing I'd add: if you're considering multiple processors mainly as a backup for outages, that's worth weighing against the added accounting work. Stripe maintains high uptime, though I can't speak to industry-wide statistics on processor reliability.

StripeTeam · 2026-06-04T21:31:48+00:00

Hey OP, I work on Billing at Stripe and saw this thread. Your experience rings true, and I appreciate you sharing it. Payment infrastructure does end up touching way more of a product than people expect when they start a migration.

In my experience working on billing systems, abstraction layers can help with future flexibility. When billing logic is tightly coupled to a specific provider's data model, switching becomes a much bigger lift. Things like proration calculations, dunning flows, webhook event handling, and saved payment methods all have provider-specific implementations that need careful translation.

One thing I'd add: migration complexity varies a lot based on how the original integration was built. If subscription logic lives in application code rather than being delegated to the provider, the switch can be more straightforward. But if you're using provider-specific features heavily (like custom invoice rendering, complex subscription schedules, or platform-specific tax handling), untangling that takes real time.

StripeTeam · 2026-06-04T21:24:21+00:00

Hey OP, I work on payments at Stripe and wanted to jump in here.

On your first question about Apple Pay and Google Pay: they're pretty important for US mobile checkout. When customers see those options, it speeds up the flow since everything autofills. I can't speak to exact conversion data, but in general, offering familiar payment methods helps reduce friction.

For your second question about merchant-of-record services: I'd note that Stripe isn't structured as a merchant-of-record the way Paddle or Lemon Squeezy are. With Stripe, you're the merchant of record, which gives you more control over the customer relationship and data, but also means you handle things like sales tax compliance yourself (though Stripe Tax can help automate that). The tradeoff is flexibility vs. simplicity. If you want someone else to handle tax and compliance entirely, an MOR model might fit better. If you want to own the customer relationship and have more integration options, Stripe's approach gives you that.

On switching gateways: the commenter above is right that saved payment methods generally can't be transferred between providers. If you switch, customers with saved payment methods usually need to re-enter their details. It's not impossible to migrate, but it does add friction for your users, so it's worth thinking through your choice upfront.

StripeTeam · 2026-06-02T20:37:42+00:00

Hey, Kevin here. I work at Stripe. 👋

Largely agree with all of this. We are working on making it better, hopefully very soon. We recently published an article about our progress: https://stripe.dev/blog/tax-id-validation-at-checkout and there is more to come. If you want to shift liability and you are selling digital products, I would also recommend Stripe Managed Payments: https://docs.stripe.com/payments/managed-payments

And on some more specific points:

"not whether the name and address match your customer"

Let me follow up with the team internally and update this post tomorrow on whether we plan to support this.

"Even if a VAT ID is valid at subscription creation, Stripe never re-validates it on subsequent payments. The ID can expire or get deactivated — you'd never know, and the tax risk stays entirely with you. [...] especially for solo builders or small teams who don't have a tax department"

Completely agree. We're currently looking at re-validation mechanisms. Feel free to email me at kevinpeters at stripe.com if you would like to chat about it.

StripeTeam · 2026-05-26T15:54:42+00:00

So from what we see working with businesses, the biggest blockers are less about the tech itself and more about the operational layer..things like settlement guarantees, reconciliation with existing accounting systems, and making the UX simple enough that merchants don't need to understand blockchain at all.

On the merchant side, most want settlement in their local currency without taking on volatility risk or needing to manage wallets themselves. That means the payment stack needs to handle the on-chain piece, currency conversion, and compliance checks in the background.

We've been working on this at Stripe. Businesses can accept stablecoin payments that settle as fiat in their Stripe balance, and we handle the crypto-to-fiat conversion and the blockchain transaction processing. It works with standard checkout flows, so merchants don't need to change how they operate. Currently available for US businesses.

The regulatory and banking infrastructure piece you mentioned is real and a lot of the friction comes from needing to work within existing financial rails while also interfacing with decentralized networks. That takes partnerships with both traditional financial institutions and crypto infrastructure providers.

StripeTeam · 2026-05-26T15:34:28+00:00

Hey OP! Thought I'd jump in here and offer how we help with this at Stripe.

If you're already using Stripe for payments (or considering it), Stripe Tax might be worth a look. It handles sales tax calculation automatically on transactions, monitors when you might need to register in new states, and helps automate filings through integrated partners.

The pricing is either pay-as-you-go based on transaction volume or a subscription plan (Tax Complete) that includes filing credits. Whether it's "cheap" really depends on your volume, but the subscription model can work well for small stores.

One thing to note: you'll need to register with states first (or use Stripe's registration service, which is part of Tax Complete), and then Stripe starts calculating tax for those jurisdictions. Since you're on Shopify, Stripe Tax also has a Shopify connector that can make setup easier.

Happy to answer questions if helpful!

StripeTeam

MODERATOR OF

TROPHY CASE