Every pool service software vendor accepts card payments. Almost every one of them does it differently. The vendor calls it "integrated payments" or "in app payments" or "embedded payments" interchangeably. The model behind those marketing words varies wildly, and the difference is worth real money to the operator. This post walks through the three actual models, what each one costs, and what to look for when you are evaluating.
TL;DR
- Three models in the market: partner routed (most common), Stripe routed (newer), native embedded (rare)
- Partner routed and Stripe routed both add a referral cut on top of the underlying processor fee
- Native embedded payments cut out the middleman and shorten funding timelines
- For an operator processing $250K+ per year in card volume, the difference compounds into thousands per year
Model 1: Partner routed payments
The oldest model. The pool service software vendor signs a referral agreement with a payments processor (Heartland, Clearent, etc.). When you sign up, you get a separate merchant account with the processor. The software vendor gets a cut of every transaction. You see a bundled rate that combines the processor fee plus the software referral cut.
Examples in the pool service market: Skimmer, Pool Brain, Pool Office Manager. The integration is usually decent but the economics are stacked. You are paying two parties for one transaction.
Model 2: Stripe routed payments
The newer pattern. The software vendor builds on top of Stripe Connect or Stripe Terminal. Stripe handles the processing. The software vendor adds a margin on top.
Examples in the pool service market: Jobber, Housecall Pro. Easier integration on the software side. Less work for the operator to set up. But the economics are the same shape: Stripe takes a cut, the vendor takes a cut, you pay both.
The funding timeline on Stripe is T+2 by default for new accounts. Established accounts can get T+1, but the vendor controls when you qualify for that.
Model 3: Native embedded payments
The rare model. The software company owns the payment rails directly, either by being a payments company that builds software (Toast, Square), or by partnering with a parent payments company (Pooly + ClayPay). No third party processor adds a cut. No referral fee. The operator pays one rate to one platform.
Funding is typically T+1 or same day. Auto pay enrollment is in the same flow as customer onboarding. Card on file is built into the customer record. Refund handling is one click instead of three systems.
In pool service, this model is uncommon. Pooly is currently the only platform built around it.
How to compare the three on your own statement
The honest comparison comes from your processor statement, not from the marketing page. Pull the last 12 months of statements and compute three numbers:
- Effective rate (total fees / total card volume) — gives you an apples to apples rate including all the small percentage fees and per transaction costs
- Average funding delay (date of transaction → date funds hit your bank) — varies by processor, vendor, and whether you are on T+1 or T+2
- Hidden monthly fees (PCI, statement, gateway, batch) — most operators never check these. They add up to $50 to $200 per month for a 100 stop route.
What this looks like in dollars for a real route
A 100 stop route at $145/month is processing $174,000/year in recurring chemical service revenue alone. Add upgrades and equipment and you are easily at $250,000+ in annual card volume.
At a 2.9% effective rate (typical Stripe + Jobber bundle): $7,250/year in fees
At a 2.6% effective rate (typical native embedded): $6,500/year in fees
Difference: $750/year on the recurring side alone, more on the upgrade side. Plus one full day of working capital recovered every payment cycle on faster funding.
“On a 100 stop route, the difference between Stripe routed and native embedded payments is roughly the cost of one full month of chemicals.”
Beyond price: the workflow difference
The dollar difference is real but easy to overlook. The bigger long term difference is workflow. Native embedded payments mean the operator never logs into a separate processor portal. Refunds happen in the customer record, not in a Stripe dashboard. Auto pay enrollment is one click during customer setup, not a separate Stripe Customer Portal link. Disputes and chargebacks come into the same inbox as everything else.
For a one person operation, the workflow difference is convenient. For a multi tech operation with an office manager, it is the difference between one source of truth and three.
When the difference does not matter
Native embedded payments are not a silver bullet for every operator. If you are processing under $50,000 per year in card volume, the dollar difference is small enough that other factors (mobile app maturity, brand familiarity, support) matter more.
But once you are over $250,000 in annual card volume, payment economics start showing up on your P&L and the model your software runs on becomes a real number to optimize, not a footnote.
Keep reading
Run this in your software
Pooly is built around the operator economics covered in this post. 30 day free trial.