← Back to Blog

Taking Money as a Small Business: Square, Stripe, and Staying Portable (Part 3 of 5)

Taking Money as a Small Business: Square, Stripe, and Staying Portable (Part 3 of 5)

This is part three of a five part series on the practical AI and web stack for a small or medium business. Parts one and two covered where your AI and your website live. This part is about taking money, which is the one decision in the stack where switching later genuinely hurts, so it is worth getting the shape right the first time.

Payment processors compete on a fraction of a percent, and that fraction matters at volume. But the bigger issue is not the rate. It is that the processor sits between you and your customers' stored payment details, and those details usually cannot follow you to a competitor. Pick with both facts in mind.

The three you will actually consider

Square is built for businesses that sell in person, or in person and online together. The standard rates are about 2.6% plus 15 cents for a tapped or swiped card, about 2.9% plus 30 cents for an online API payment, and about 3.3% plus 30 cents for an invoice. There is no monthly fee on the base plan; you pay per sale. Its real strength is that the same catalog and inventory power your register, your online store, and your invoices at once. The optional Square Plus and Premium tiers run $49 and $149 a month per location for more features. For a laundromat adding a small online presence, a car wash selling memberships at the counter, or any shop that lives at a physical location, Square is the natural fit.

Stripe is built for online-first businesses and developers. The standard online rate is about 2.9% plus 30 cents, the same headline as Square's online tier, but Stripe's tooling, subscription handling, and API depth are why software-leaning businesses choose it. A coaching business billing monthly memberships, a SaaS-style product, or any store where the website is the storefront tends to land here.

PayPal is built on buyer trust at checkout. The standard online rate is higher, about 3.49% plus 49 cents, but some customers simply trust the PayPal button and will complete a purchase they might otherwise abandon. It is often added as a second option at checkout rather than chosen as the only one, accepting a higher fee on those sales in exchange for the conversions.

For a business doing real volume, those rate differences add up, and interchange-plus processors can undercut all three. But for most small businesses just starting to take cards, the difference between 2.9% and 3.3% is not what should drive the decision. The fit with how you actually sell is.

The lock-in that actually costs you

Here is the part nobody mentions when you sign up. When a customer saves a card, the processor stores a token that represents it, and that token lives in the processor's world. You generally cannot export your customers' stored cards and carry them to a new processor. Switching means asking customers to re-enter their payment details, re-validating your compliance, and accepting some churn while you do it. Your catalog and customer records also live in the processor's data model.

This is why payments is the one place in this series where "just switch later" is genuinely hard. It does not mean avoid these tools. It means set yourself up so the rest of your business is not welded to one of them.

A better way: wrap payments behind your own door

You do not have to let the processor reach into the rest of your system. Two habits keep your options open.

  1. Use the processor's hosted card fields. Square's Web Payments SDK and Stripe's equivalent collect the card in a frame they control and hand your code a one-time token. The raw card number never touches your server, which keeps you out of most of the heavy compliance scope. This is the safe default, not an advanced move.
  2. Put one thin layer of your own code between your business and the processor. Define a small interface in your own terms, something like "charge this amount," "refund this sale," "save this customer," and have the Square or Stripe specifics live behind it. The rest of your app talks to your interface, not to Square directly. You cannot fully escape the stored-token problem, but you shrink the switch from a full rebuild to swapping one component, and you keep a second processor a day's work away instead of a quarter's.

Even if you are not the one writing the code, you can ask whoever builds your checkout to do exactly this, and to keep your product catalog and customer list exported somewhere you own. That one request is the difference between a portable business and a captive one.

Matching it to how you sell

  • Counter-first business (laundromat, car wash, cafe, salon): Square. One system for the register and any online add-on, no monthly fee to start, hardware that just works.
  • Online-first or subscription business (coaching, memberships, a digital product): Stripe for the depth, with PayPal added at checkout if your customers expect the button.
  • Real volume, watching every point of margin: get quotes from an interchange-plus processor and compare against your actual monthly card mix, not the headline rate.

In every case, host the storefront wherever makes sense from part two of this series, and treat the payment processor as a swappable component behind your own interface. Keep the money tool separate from the website tool, and neither one can hold the other hostage. That separation, running lean and owning the seams between your tools, is the whole idea behind the Digital Empire book The $20 Dollar Agency.

The honest summary

Pick the processor that fits how you actually take money, not the one with the headline rate a tenth of a percent lower. Use hosted card fields so you stay out of compliance scope, wrap the processor behind a thin layer of your own, and keep your catalog and customer list exported somewhere you control. Do that and the one genuinely sticky decision in your stack stops being a trap. Next in this series, turning your own documents and know-how into something the AI can actually use.

The series

Related reading

Fact-check notes and sources

Processing rates change and vary by plan and card mix; treat these as approximate mid-2026 figures and confirm on each processor's page before relying on them.

This post is informational and not financial, legal, or compliance advice. Mentions of third-party processors are nominative fair use; no affiliation is implied. Rates are current as of mid-2026 and change; verify before relying on them.

← Back to Blog

Accessibility Options

Text Size
High Contrast
Reduce Motion
Reading Guide
Link Highlighting
Accessibility Statement

J.A. Watte is committed to ensuring digital accessibility for people with disabilities. This site conforms to WCAG 2.1 and 2.2 Level AA guidelines.

Measures Taken

  • Semantic HTML with proper heading hierarchy
  • ARIA labels and roles for interactive components
  • Color contrast ratios meeting WCAG AA (4.5:1)
  • Full keyboard navigation support
  • Skip navigation link
  • Visible focus indicators (3:1 contrast)
  • 44px minimum touch/click targets
  • Dark/light theme with system preference detection
  • Responsive design for all devices
  • Reduced motion support (CSS + toggle)
  • Text size customization (14px–20px)
  • Print stylesheet

Feedback

Contact: jwatte.com/contact

Full Accessibility StatementPrivacy Policy

Last updated: April 2026