Realtime split-payments SaaS для барбершопов и салонов красоты в Перу. Клиент платит через Yape, мастер получает свою долю мгновенно, владелец видит реальный оборот в realtime.
⚠ Точность терминологии — в спеке используются названия «Yape Negocios» / «Yape Empresarial Transfer API» как рабочие термины для merchant-приёма и B2B-API соответственно. Точные продуктовые названия BCP могут отличаться — должны быть валидированы при первом tech-deep-dive с Yape-командой.
В барбершопах/салонах Перу типично две модели отношений владелец-мастер:
Оба сценария = одна и та же боль: непрозрачное и/или медленное разделение выручки между владельцем и работниками.
| Решение | Зафиксировано |
|---|---|
| Только Перу для MVP | Не Колумбия (два-rail Nequi+Daviplata), не Чили (мал. рынок), не Мексика/Аргентина (Stripe там есть) |
| Только барбершопы/салоны | Не спортзалы (subscription-модель), не репетиторы, не gasfiteros |
| Hybrid contract model (renter + employee) | Один data model, разные конфигурации |
| Owner = customer SaaS | Не master-as-customer, не marketplace |
| Realtime split (Подход A) — primary | Reconciliation T+0 — fallback при отказе/задержке Yape-партнёрства, не multi-channel gateway |
| Отдельный startup, не Presu | Снимает блокер MP-gate и не размывает MLP-фокус gasfiteros |
| Single rail Yape | Plin/MercadoPago — после validation |
| Spanish-only | Quechua/English после growth |
| PWA, не native | iOS/Android — после product-market fit |
┌────────────────────────────────────────────────────────────┐
│ CLIENT — сканит QR салона/мастера через Yape app │
└──────────────────────────┬─────────────────────────────────┘
▼
┌────────────────────────────────────────────────────────────┐
│ YAPE NEGOCIOS (мастер аккаунт) │
│ Платёж зачислен → webhook → наш callback │
└──────────────────────────┬─────────────────────────────────┘
▼ webhook
┌────────────────────────────────────────────────────────────┐
│ REPARTE BACKEND (Split Engine) │
│ 1. Idempotency check (yape_webhook_id dedup) │
│ 2. Resolve rule: tenant.split_rules[master_id] │
│ 3. Compute amounts: owner = total × owner_pct │
│ 4. Yape Empresarial Transfer API → owner account │
│ 5. Audit log + push notifications │
│ 6. SUNAT boleta electrónica generation │
└──────────────────────────┬─────────────────────────────────┘
▼
┌────────────┴────────────┐
▼ ▼
┌──────────────┐ ┌──────────────┐
│ Master PWA │ │ Owner PWA │
│ + Telegram │ │ + Realtime │
│ bot │ │ dashboard │
└──────────────┘ └──────────────┘-- Salon
CREATE TABLE tenants (
id UUID PRIMARY KEY,
name TEXT NOT NULL,
country CHAR(2) DEFAULT 'PE',
currency CHAR(3) DEFAULT 'PEN',
owner_user_id UUID NOT NULL,
yape_business_account_id TEXT, -- KYC'd с BCP
default_split JSONB, -- {"owner_pct":30,"master_pct":70}
created_at TIMESTAMPTZ DEFAULT NOW()
);
-- Юзеры (owner | master | client)
CREATE TABLE users (
id UUID PRIMARY KEY,
phone TEXT UNIQUE,
role TEXT CHECK (role IN ('owner','master','client')),
yape_account_id TEXT,
sunat_ruc TEXT,
kyc_status TEXT DEFAULT 'pending',
created_at TIMESTAMPTZ DEFAULT NOW()
);
-- Связь мастеров с салонами + правила
CREATE TABLE workers (
tenant_id UUID REFERENCES tenants(id),
user_id UUID REFERENCES users(id),
contract_type TEXT CHECK (contract_type IN ('renter','employee')),
split_rule JSONB NOT NULL,
active BOOLEAN DEFAULT TRUE,
PRIMARY KEY (tenant_id, user_id)
);
-- Входящие платежи
CREATE TABLE payments (
id UUID PRIMARY KEY,
tenant_id UUID,
master_id UUID,
client_phone TEXT,
amount_pen NUMERIC(12,2) NOT NULL,
fee_yape NUMERIC(12,2),
net_amount NUMERIC(12,2),
yape_payment_id TEXT,
yape_webhook_id TEXT UNIQUE, -- idempotency key
status TEXT CHECK (status IN ('pending','received','splitting','settled','failed')),
service_type TEXT,
created_at TIMESTAMPTZ DEFAULT NOW(),
settled_at TIMESTAMPTZ
);
-- Исходящие трансферы
CREATE TABLE transfers (
id UUID PRIMARY KEY,
payment_id UUID REFERENCES payments(id),
from_user_id UUID,
to_user_id UUID,
amount_pen NUMERIC(12,2),
yape_transfer_id TEXT,
status TEXT CHECK (status IN ('queued','sent','confirmed','failed','retrying')),
retry_count INT DEFAULT 0,
created_at TIMESTAMPTZ DEFAULT NOW(),
confirmed_at TIMESTAMPTZ
);
-- Audit log
CREATE TABLE audit_log (
id UUID PRIMARY KEY,
event_type TEXT,
entity_type TEXT,
entity_id UUID,
payload JSONB,
created_at TIMESTAMPTZ DEFAULT NOW()
);| Revenue per salon/мес | Сумма |
|---|---|
| Base subscription | $29 |
| Per-transaction fee ($0.30 × 1000) | $300 |
| Итого | ~$330 |
| Cost per salon/мес | Сумма |
|---|---|
| Yape API fees ($0.05-0.15 × 1000) | $50-150 |
| Server+infra share | $2 |
| Customer support | $30 |
| Итого | ~$180 |
Net per salon: ~$150/мес, margin ~30% (на v0.1)
Рынок Перу: ~30K зарегистрированных салонов + 50-100K informal. 1000 paying = ~1% formal segment penetration. Реально 18-24 мес при условии что Yape-партнёрство откроется.
Без gated B2B API доступа к Yape Empresarial Transfer Подход A невозможен. Cold outreach в BCP без связей = 3-6 мес до встречи + 3-6 мес до контракта.
Mitigation: дизайн системы такой, что Reconciliation-fallback (T+0 batch вместо realtime) implementable за 2 недели на тех же data structures. Если партнёрка зависает >6 мес — переключаемся на B и идём дальше.
BCP — крупная корпорация, риск что они скажут «10% от вашего revenue» или «эксклюзивный partner — только Yape, не Plin».
Mitigation: переговариваться о non-exclusive с верхним порогом. Если жёсткие условия — переключаемся на Plin (Interbank+BBVA+Scotiabank).
Может не поддерживать realtime webhook на receive (только polling), может иметь rate limits на Transfer API, может не поддерживать reversal/refund.
Mitigation: первая встреча с Yape должна включать tech deep-dive перед коммитом на Подход A.
Каждый мастер должен иметь свой Yape Empresarial аккаунт. Регистрация требует RUC. Многие мастера-новички не имеют RUC.
Mitigation: онбординг-флоу включает помощь в получении RUC online (SUNAT RUC-online), пошаговый wizard. Этот «вход в формализацию» сам по себе — фича.
50-70% барбершопов в Перу работают в informal-сегменте (без RUC, наличка). Они не подойдут под наш SaaS.
Mitigation: фокус на formal premium-сегмент Лимы (Miraflores/Barranco/San Isidro) где владельцы УЖЕ хотят формализоваться. ICP: салон с 3+ мастерами, средний чек 40+ PEN, locación в столице.
Если клиент отозвал платёж после split-transfer'а, owner уже получил долю, мастер уже получил остаток. Yape может не поддерживать reversal.
Mitigation: в первой версии — manual workflow («запрос на возврат» → ручной zwarrant с обоих балансов). Авто-reversal только когда Yape API подтвердит поддержку.
Banco Central de Reserva del Perú может в 2026-27 запустить interop-rail типа Bre-B Колумбии или Pix Бразилии — это сразу обесценит multi-rail strategy и может включить native split в гос-rail.
Mitigation: следить за BCRP анонсами, быть готовым перейти на госrail.