Our launch jobs are ~₡30,000 (about $60). At that ticket size, the fee model isn't a detail — it decides whether each transaction makes money or loses it. This page puts the options side by side on real processor numbers, then gives a recommendation and an adversarial review of it.
On a ₡30,000 (~$60) job in Costa Rica (the likely first market), a flat 5% take with the platform absorbing card processing nets roughly ₡0 — or a small loss. Card processing there runs ~3.9% + ₡175 and there's a ~₡1,500 payout fee, so almost the entire 5% is eaten before we keep anything. The model only works if we change one of three things: (1) pass processing to the customer (visible, Uber-style), (2) charge a tiered % that front-loads small jobs, or (3) move payments onto the cheap local rail (SINPE Móvil ~1.5%) and batch payouts. Absorbing processing on low-ticket card payments is the one option that doesn't work.
Net to the platform per visit, after processing + an (amortized) payout fee. Detail and assumptions below. Important: the adversarial review argues this per-visit framing is itself second-order — read it before treating any number here as the answer.
Today's documented model: the pro pays a flat 4% all-in, the customer pays 1%, and the platform absorbs processing inside that. Here's where the money goes on one ₡30,000 visit, in each of the three realistic payment contexts.
Gross take ₡1,500 − processing ₡1,357 − batched payout ~₡200 = slightly negative. Per-visit (un-batched) payouts of ₡1,500 make it −₡1,357.
Gross take ₡1,500 − processing ~₡455 − batched payout ~₡200 = ~₡845 (~2.8%). The local rail roughly triples the margin.
Gross take $3.00 − processing $2.06 − Connect payout/account overhead ~$0.25 = ~$0.70 (~1.2%). Thin, but positive. (Stripe is not available in Costa Rica — it's a Canada-only option.)
Same job, same ~3.9% + ₡175 card cost, same batched payout. The only thing that changes is who carries processing and how the take is shaped.
Model A is the only one that fails. B and C both clear ~₡1,200–1,300 on a ₡30,000 card job — they just put the cost in different places (B on the customer, C on the pro).
Platform net per job, after ~3.9% + ₡175 processing and a batched payout, on Costa Rican card rates. This shows where each model breaks.
| Job | A · Absorb | B · Pass-through | C · Tiered (pro %) |
|---|---|---|---|
| ₡15,000 | −₡216 | ₡550 | ₡540 (10%) |
| ₡30,000 | −₡57 | ₡1,300 | ₡1,205 (9.2%) |
| ₡50,000 | ₡155 | ₡2,300 | ₡1,425 (7.5%) |
| ₡125,000 | ₡951 | ₡6,050 | ₡2,250 (6%) |
Absorb (A) stays underwater across the entire HRLT range (₡15k–30k) and only turns clearly positive well above our launch ticket. Pass-through (B) is a flat ~4–5% everywhere. Tiered (C) is healthy at low ticket but its margin falls as jobs grow because it's still absorbing processing — a tiered + pass-through hybrid would fix that, at the cost of complexity.
Switching the same jobs to SINPE Móvil (~1.5%) lifts every cell — and turns Absorb positive from ~₡30,000 up. The processing rail matters as much as the fee model.
A marketplace must collect from the customer and pay out an independent pro while keeping a commission (a "split"). Most processors can't. And the launch market decides the shortlist — because Stripe and Helcim don't operate in Costa Rica.
| Processor | Card rate | Split / payouts? | Costa Rica? | Notes |
|---|---|---|---|---|
| ONVO Pay 🇨🇷 | 3.9% + ₡175 SINPE 1.5–2.5% | Yes — native | Yes | Documented marketplace/sub-merchant split, public API, ₡1,500/payout. CR + Guatemala. Front-runner. |
| Tilopay 🇨🇷 | 4.25% + ₡175 | Not native | Yes | Good gateway; you'd build the split layer or confirm with sales. |
| Stripe Connect | 2.9% + $0.30 +1% intl | Yes — native | No | Best-in-class splits, but can't onboard CR businesses. A Canada option only. |
| Helcim | ~1.7–2.3% interchange+ | No | No | Cheapest rate, but no marketplace split at all + Canada/US only. Not usable as our backbone. |
| Kushki | quote | Yes (payouts) | Confirm | Real payout capability; CR card-acquiring needs confirmation. |
| Mercado Pago | — | Yes | No | Not in Costa Rica. Irrelevant for CR. |
The chat's "use Helcim, it's cheaper" idea doesn't survive contact: Helcim has no marketplace split and isn't in CR. For a CR launch, ONVO is effectively the only turnkey option. Helcim/Stripe only re-enter the conversation if we launch in Canada instead.
Costa Rica's instant bank-transfer rail costs ~1.5% vs ~3.9% on cards — and it's how locals already pay each other. Making SINPE the default (cards as fallback) roughly triples per-visit margin and can make even the absorb model viable. Adds a "no chargeback" benefit too.
ONVO charges ~₡1,500 per disbursement. Paying a pro per visit on a ₡30,000 job is a margin killer (−₡1,500 each). Paying each pro once a week for all their visits amortizes that ₡1,500 across many jobs — a recurring gardener with 4 visits/week drops it to ~₡50/visit.
A minimum-fee floor (e.g. don't let the platform's net go below ~₡500) is a third safety lever, useful under any model for the smallest jobs.
Reading the numbers against the launch plan (CR-first, ~₡30,000 HRLT jobs), here's where I land.
The customer covers ONVO's processing (visible, Uber-style) and the pro pays a tiered commission — the margin-strongest combination here. Two caveats carried into the pilot: (1) ONVO's marketplace commission is a flat %, so true tiering isn't native — we calibrate a flat ~9% to the first tier for the ~₡30k launch band and treat real tiering as a refinement; (2) a visible customer fee can invite cash defection, so watch conversion. The first-pass reasoning that led here is below.
Concretely: pro pays ~4–5%, the customer pays a small platform fee (~1–2%) plus the visible processing fee, payments default to SINPE Móvil with cards as fallback, payouts are batched weekly per pro, and a minimum net floor protects the smallest jobs. This keeps a clean ~4–5% platform margin at every ticket size, survives the worst case (CR card), and a ~5% combined take is low for the category, so there's headroom.
⚠️ The adversarial review below pushes back hard on this — chiefly that a visible customer fee invites off-platform defection in a cash-default market, and that the per-visit margin is the wrong thing to optimize first. The synthesis revises this toward a tiered, customer-invisible take plus a validate-first plan. Read both before deciding.
Gig/marketplace take-rates broadly run 15–30%; pure lead-gen platforms (Thumbtack, Angi, Bark) charge per lead, not a % of the job; and a visible customer service fee is standard (Uber/DoorDash). A combined ~5% take is at the very low end — good for adoption, but it means we have little room to also absorb processing. (From training knowledge; live figures unverified — confirm.)
An independent pass whose only job is to attack the comparison above and the recommendation — so partners see the holes before betting on it.
At ~₡1,250 net/visit, the analysis ignores ONVO monthly fees, ops salaries, white-glove onboarding, and acquisition. One part-time CR ops person (~₡300,000–450,000/mo) needs 240–360 visits/month just to break even — before software or founders. Whether a cell is +₡1,300 or +₡1,205 is a rounding error against that. The per-visit comparison answers a question that isn't binding yet.
The ~₡200/visit payout figure assumes pros accept weekly settlement. Informal gardeners and car-washers are the textbook "need cash now" population. If payouts are per-visit, the full ₡1,500 hits every job and the punchline flips:
"Batch payouts weekly" is presented as a free lever. It isn't — it trades directly against retaining pros who live on daily cash flow. This single assumption can turn every model negative.
Uber's fee hides inside an all-in price and the off-app alternative also costs money. Here the alternative is cash to a gardener at zero fee, and the relationship is weekly and personal. A visible processing line on a ₡30,000 job gives both sides a reason to go cash next week — disintermediation, which is worse for recurring services than for one-off rides. "Headroom because gig take is 15–30%" misreads the comp: those rates hold because the platform owns demand and the deal can't happen off-app. A weekly gardener trivially can.
(a) Disintermediation: SINPE Móvil's natural UX is account-to-account P2P. If customers pay the pro directly, the platform collects 0% — steering to SINPE could steer revenue out. The "1.5% lifts every cell" only holds if the platform stays in the flow. (b) Chargeback / dispute liability is never assigned — as merchant of record the platform likely eats it, and one ₡30,000 card chargeback wipes ~10–25 visits of net. That tail risk is bigger than the margin being optimized.
"Effectively the only turnkey option" is stated, then never stress-tested. The real gate: can ONVO KYC-onboard informal pros who may lack tax registration or bank docs? If not, a large share of supply is locked out — and that's not in any number. Plus per-account limits, payout holds, no negotiating leverage as a tiny customer, and outage = 100% revenue stop. Validate ONVO onboarding of the informal supply base before any fee modeling.
"9% on the pro" isn't a problem for someone paying 0% today who gains guaranteed recurring revenue. Crucially, tiered is charged to the pro and invisible to the customer — which sidesteps the conversion/disintermediation problem in #3 — and it captures most where pass-through earns least (small tickets). The strongest combo may be C's invisible pro-side tier + SINPE default, not B.
The binding constraints at launch are: will ONVO onboard pros, will customers convert and stay, and will anyone defect to cash. A 4% vs 5% take on ₡30,000 is third-order. The right early posture is lowest-friction, possibly subsidized take to win liquidity + retention, then raise monetization once switching costs exist. The fee model is reversible; a failed launch is not.
The adversarial pass is largely right, and it reorders the work:
Net: the original recommendation (pass-through) optimizes the wrong constraint. The decision-ready position is "validate the three existential unknowns, lean tiered/invisible, default to SINPE while guaranteeing the platform stays in the flow, and stop optimizing per-visit margin until the loop is proven."
Validate first (existential — before locking the fee model):
Then decide: