МАТЧАСТЬ / PAYMENTS, BILLING & REFUNDS / DOCUMENT 31 / 02.09.2026

Платежи, billing и refund

Как принимать деньги за публикации и monitoring, выдавать credits, выставлять B2B-счета, проводить интернет-платежи, формировать чеки и закрывающие документы, обрабатывать возвраты и не допускать расхождения между заказом, оплатой, публикацией и бухгалтерией. Документ задаёт финансовый state machine, рекомендуемую платёжную архитектуру MVP, refund policy, правила credits, recurring billing, ЭДО, audit и reconciliation.

B2B firstсчёт и банковский перевод — основной путь для компаний и агентств

1 PSPна MVP один интернет-провайдер платежей вместо платёжного зоопарка

Ledger firstвнутренняя финансовая книга — источник правды, webhook не равен бухгалтерии

Refund by scopeвозврат зависит от уже оказанной части услуги, а не только от статуса статьи

1. Главное решение

На MVP использовать гибридную модель: B2B invoice/bank transfer как основной канал для юрлиц и ИП, а один интернет-провайдер — для быстрых карт/СБП и будущих recurring payments. Внутри «Матчасти» все способы оплаты приводятся к единой модели Order → Payment → Credit/Service → Documents → Refund.

ORDER ↓ PAYMENT INTENT ├─ BANK TRANSFER / INVOICE ├─ CARD └─ SBP ↓ PAYMENT CONFIRMED ↓ ORDER FUNDED ↓ CREDIT RESERVED / SERVICE STARTED ↓ PUBLICATION / MONITORING ↓ SERVICE COMPLETED ↓ CLOSING DOCUMENTS alternative: CANCEL / REFUND / CREDIT RETURN

2. Почему B2B bank transfer должен быть основным

первый ICP — агентства и B2B-компании;
закупке проще работать со счётом и договором;
ниже платёжные комиссии, чем у карт;
удобнее крупные пакеты 30–200 тыс. ₽;
проще связать payer, advertiser и client entity;
не требуется хранить банковские реквизиты карты;
для обычного безналичного расчёта между ЮЛ/ИП через расчётные счета существуют отдельные правила применения ККТ.

3. Важная оговорка по ККТ

ФНС традиционно указывает, что обычные безналичные расчёты между организациями и/или ИП без предъявления электронного средства платежа подпадают под исключение из применения ККТ. При этом свежие региональные разъяснения ФНС 2025–2026 по расчётам через СБП формулируются неодинаково: одна публикация прямо говорит об обязательном применении ККТ через СБП, другая описывает условия, при которых расчёт между ЮЛ/ИП может быть освобождён.

Не кодировать налоговую логику по одной статье из интернета. Перед запуском бухгалтер/налоговый консультант должен утвердить матрицу «тип покупателя × способ оплаты × нужна ли ККТ × какой чек» и версию этой матрицы хранить в billing config.

4. Предварительная матрица оплаты

Покупатель	Способ	Продуктовое решение	ККТ
ЮЛ/ИП	Банковский перевод по счёту	Основной B2B путь	Проверить исключение по 54-ФЗ с бухгалтером
ЮЛ/ИП	СБП	Можно поддержать	Отдельно подтвердить актуальную трактовку
ЮЛ/ИП	Карта	Дополнительный путь	Фискализация по утверждённой схеме
Физлицо	Карта/СБП/безнал	Если допускаем consumer purchase	ККТ обычно требуется; подтвердить детали

5. Один payment service provider на MVP

Рекомендованный стартовый кандидат — ЮKassa: API платежей, счета, возвраты, webhooks, recurring payments и решения по 54-ФЗ уже находятся в одной экосистеме.

Это не означает vendor lock-in навсегда. Архитектура должна иметь внутренний payment_provider abstraction, но реализовать только одного провайдера в P0.

6. Почему не подключать сразу 4 эквайера

Каждый новый PSP = webhook states refunds reconciliation receipts security support accounting edge cases MVP: one provider + bank transfer.

7. Актуальная комиссия ЮKassa

В текущем публичном базовом тарифе ЮKassa для оборота до 3 млн ₽ банковские карты и ряд pay-методов для услуг/цифрового контента указаны по 3,5%. С 1 января 2026 года по некоторым способам оплаты к комиссии добавляется НДС 22% от самой комиссии. На странице тарифов ЮKassa банковские карты отмечены как облагаемые таким НДС.

Illustration: payment 7 900 ₽ base acquiring 3.5% = 276.50 ₽ VAT on commission 22% = 60.83 ₽ total PSP cost ≈337.33 ₽ ≈4.27% of payment

Это важная корректировка Mathchast_30. Использованный там резерв ≈2,5% для acquiring может быть слишком низким для карточного платежа на базовом тарифе ЮKassa 2026. Unit economics нужно считать по реальному способу оплаты, а не одной средней ставке.

8. СБП как экономичный online channel

НСПК указывает для бизнеса типовые ставки СБП 0,4% и 0,7% в зависимости от MCC, с лимитом комиссии 1 500 ₽ за перевод; для отдельных категорий действует 0,2% с иным лимитом. Конкретный тариф и применимость нужно подтвердить у банка/PSP для деятельности «Матчасти».

В checkout можно ненавязчиво предлагать СБП первым online-способом, если его реальная ставка существенно ниже карточной.

9. Не вводить surcharge за карту на MVP

Публичная цена должна оставаться понятной. Разницу комиссий лучше учитывать в unit economics и стимулировать B2B invoice/SBP UX, а не добавлять мелкую строку «комиссия за карту» без юридической и продуктовой необходимости.

10. Payment methods P0

P0: 1. B2B invoice / bank transfer 2. SBP via provider 3. Bank cards via provider P1: saved payment method recurring monitoring P2: additional PSP / enterprise special flows only if economics/reliability justify.

11. Order ≠ Payment

Заказ и платёж — разные сущности. Один заказ может иметь несколько попыток оплаты, частичный возврат или смену способа оплаты.

ORDER #1248 amount_due = 14 900 PAYMENTS: P1 card → canceled P2 SBP → succeeded REFUND: R1 5 000 → succeeded order financial state: PARTIALLY_REFUNDED

12. Основные billing entities

order order_items price_snapshot payment payment_attempt invoice credit_ledger refund billing_account payer tax/fiscal_record closing_document discount subscription later ledger_entry

13. Order item decomposition

ORDER: Create + Publish = 19 900 INTERNAL COMPONENTS: PRODUCTION_SERVICE PUBLICATION_CREDIT optional MONITORING Client may see: one simple SKU System knows: which service portion has been consumed.

14. Зачем внутреннее разложение

Это позволяет корректно обрабатывать:

отказ материала после уже выполненной редакторской работы;
возврат только monitoring;
unused publication credit;
частичный возврат;
закрывающие документы по фактически оказанной услуге.

15. Price snapshot

order_price_snapshot: pricing_version SKU list_price discount discount_reason tax settings currency included_scope credit_expiry refund_terms created_at

Изменение прайса завтра не должно пересчитывать вчерашний заказ.

16. Order state

CREATED → PAYMENT_PENDING → PAID → IN_PROGRESS → FULFILLED → COMPLETED alternatives: EXPIRED CANCELLED REJECTED PARTIALLY_REFUNDED REFUNDED DISPUTED

17. Payment state

У ЮKassa основной жизненный цикл платежа включает pending, waiting_for_capture, succeeded и canceled. Внутри «Матчасти» хранить provider state и собственный normalized state отдельно.

provider_status: pending waiting_for_capture succeeded canceled internal: CREATED ACTION_REQUIRED AUTHORIZED SETTLED FAILED CANCELLED REFUNDED_PARTIAL REFUNDED_FULL

18. Webhook — сигнал, не единственный источник правды

ЮKassa поддерживает события payment.succeeded, payment.canceled, payment.waiting_for_capture и refund.succeeded. Полученный webhook должен запускать проверку состояния и идемпотентное обновление, а не «просто поставить paid=true».

WEBHOOK → verify authenticity/config → dedupe event → fetch/validate provider object if required → compare amount/currency/order → append ledger event → update normalized state → trigger next workflow

19. Idempotency обязательна

Payment/refund API ЮKassa использует Idempotence-Key. Собственные команды тоже должны быть идемпотентными.

User double-clicks Pay Network retries Webhook arrives twice Result: ONE financial operation not two.

20. Никогда не доверять return URL

Переход пользователя на /payment/success не является доказательством оплаты. Заказ считается оплаченным только после подтверждённого provider/internal financial state.

21. Одностадийная или двухстадийная оплата

ЮKassa позволяет как сразу списывать деньги, так и сначала авторизовать их в waiting_for_capture, а потом capture/cancel. Для «Матчасти» стандартный digital B2B order проще проводить одностадийно, если юридическая/операционная модель не требует hold.

22. Когда двухстадийная может быть полезна

Potential: high-risk custom service manual eligibility check limited editorial slot But: authorization expiry extra operational complexity receipt implications Recommendation: not P0 default.

23. Invoice flow для B2B

Checkout → legal billing profile → generate invoice → status WAITING_PAYMENT → client bank transfer → reconciliation → PAID → service starts

24. Счёт не равен оплате

Наличие PDF-счёта не даёт credits и не запускает paid SLA до подтверждения денег, если договором не предусмотрен постоплатный режим.

25. Автоматическое распознавание bank transfer

P0: manual/bank statement import reconciliation P1: bank API / statement feed → match by: invoice number payer INN amount purpose date unmatched: finance queue.

26. Не матчить только по сумме

Два клиента могут в один день заплатить по 14 900 ₽. Нужен invoice/order reference и payer identity.

27. Overpayment

invoice 14 900 received 15 000 → OVERPAYMENT 100 → finance review: return or credit if contract/accounting permits Never: silently consume.

28. Underpayment

invoice 14 900 received 14 500 → PARTIALLY_FUNDED → do not mark fully paid → request balance / finance decision.

29. Payer data

billing_account: legal_name INN KPP optional legal_address bank/account data if needed contact email EDO operator/id tax status billing country document preference

30. Payer ≠ advertiser ≠ client

Сохраняем решение Mathchast_29.

Agency LLC = payer Brand LLC = advertiser Brand X = public subject Agency user = workspace operator

31. Online receipt / 54-ФЗ integration

ЮKassa предлагает либо собственное решение «Чеки от ЮKassa», либо интеграцию со сторонней онлайн-кассой. При платеже передаются данные предметов расчёта и контакты клиента; при возврате поддерживается формирование возвратного чека.

Для MVP имеет смысл выбрать один фискальный путь и максимально использовать готовую интеграцию вместо разработки собственного кассового оркестра.

32. Fiscal item mapping

SKU: "Публикация материала на платформе «Матчасть»" receipt item: description quantity=1 amount VAT code payment subject payment mode Values: confirmed with accountant for actual tax regime.

33. Не хардкодить ставку НДС

С 1 января 2026 года базовая ставка НДС изменилась до 22%, а платёжные API уже добавили новые коды ставок. Конкретная ставка самой услуги «Матчасти» зависит от налогового режима компании — её задаёт billing/tax configuration, а не developer «на глаз».

34. Fiscal record state

NOT_REQUIRED PENDING REGISTERED FAILED REFUND_PENDING REFUND_REGISTERED store: provider receipt ID type amount tax mapping version created_at error.

35. Ошибка фискализации — отдельный incident

Payment succeeded + receipt failed не должен исчезнуть в логах. Это finance/compliance incident queue.

36. Closing documents в B2B

В 2026 году электронный документооборот по первичным документам меняется: ФНС указывает УПД как основной официальный электронный формат для подтверждения отгрузки товаров, выполнения работ и оказания услуг; при этом бумажные и некоторые неформализованные документы могут продолжать применяться в предусмотренных случаях.

Финальный набор «счёт / УПД / акт / счёт-фактура» для «Матчасти» должен определить бухгалтер после выбора юрлица и налогового режима. Product architecture должна поддерживать документ по типу, а не жёстко предполагать один PDF-акт навсегда.

37. EDO

Диадок API в 2026 году поддерживает актуальный документооборот УПД версии 5.03 и программную работу с документами. Это хороший кандидат для будущей автоматизации, если большинство клиентов работает через ЭДО.

P0: manual / accountant-generated documents upload/link in cabinet P1: Diadoc integration generate/send status sync signed state P2: multiple EDO providers only if demand.

38. Closing document state

NOT_DUE READY_TO_CREATE CREATED SENT DELIVERED SIGNED REJECTED CORRECTED ARCHIVED

39. Когда считать услугу оказанной

Нужно определить в договоре и бухгалтерской политике по каждому SKU. Product event должен быть явным.

Publish: likely publication approved/live event Editing: editorial work completion Monitoring: end of measurement period / report delivery or periodic monthly service Package credits: not all services delivered at purchase moment.

40. Credits ledger

credit_ledger: GRANT RESERVE RELEASE CONSUME RETURN EXPIRE ADJUST fields: workspace credit_type quantity order publication reason actor timestamp

41. Balance не хранить только числом

Текущий баланс вычисляется из ledger entries. Админ не должен просто менять credits=7 без причины.

42. Credit reservation

available 3 submit paid publication → RESERVE 1 client withdraws eligible → RELEASE 1 publication reaches consumption event → CONSUME reserved credit

43. Когда consume credit

Рекомендуемый MVP момент — после редакционного approval и готовности к publication, а не сразу при создании draft.

Так клиент может начать материал без риска «сжечь» credit, а система не держит оплату бесконечно незавершённой после approval.

44. Rejected material

If rejected: publication credit → RETURN/RELEASE But: paid editing/production already performed may be handled separately according to order scope.

45. Expiry credits

Mathchast_30 предлагает 12 месяцев как рабочую гипотезу. Billing engine должен хранить expiration per credit batch, а не одно поле на workspace.

batch A: 5 credits expires 01.09.2027 batch B: 3 credits expires 10.12.2027 consume: oldest eligible first unless contract says otherwise.

46. Expiry reminders

90 days 30 days 7 days optional email + in-app No: silent expiration.

47. Refund philosophy

Возвращать деньги не по принципу «статья вышла / не вышла», а по фактически начатым и оказанным компонентам услуги плюс условиям оферты/договора.

48. Refund matrix — Publish

Ситуация	Рекомендованная логика
Оплатил и сразу отменил до submission/review	Full refund / credit return
Материал подан, но платформа ещё не начала meaningful work	Full/near-full по terms
Материал отклонён moderation	Publication credit returned; payment treatment по SKU terms
Платформа не может оказать услугу по своей причине	Full refund unused component
Материал опубликован корректно	Нет обычного refund за «мне не понравился трафик»

49. Refund matrix — Edit + Publish

Before editor starts: full refund possible After substantial editing: editing component earned publication component may remain refundable/credit If platform fault: appropriate full/partial refund. Exact terms: legal review required.

50. Refund matrix — Create + Publish

brief/interview done draft delivered publication later impossible → production work ≠ zero Need component accounting: production amount publication amount Client-facing package remains simple, contract defines allocation/refund method.

51. Monitoring refund

Ситуация	Логика
Monitoring не стартовал	Refund unused period
Часть runs уже выполнена	Prorated/period policy
Нет улучшения AI visibility	Не основание само по себе
Сервис не собирал данные из-за платформенной ошибки	Credit/refund according SLA policy

52. Не обещать refund за отсутствие внешнего результата

Нет гарантии Google index, traffic, lead, AI mention. Refund связан с невыполнением купленной контролируемой услуги, а не с отсутствием неконтролируемого результата.

53. Full vs partial refund

ЮKassa API поддерживает полный и частичный возврат. Это подходит компонентной модели «Матчасти».

refund: order_id payment_id amount reason_code requested_by approved_by provider_refund_id status fiscal_status ledger entries

54. Refund reason codes

CLIENT_CANCELLED_BEFORE_WORK EDITORIAL_REJECTED LEGAL_REJECTED PLATFORM_UNABLE_TO_DELIVER DUPLICATE_PAYMENT OVERPAYMENT PARTIAL_SERVICE SLA_COMPENSATION BILLING_ERROR FRAUD/CHARGEBACK OTHER

55. Refund approval

Amount/type	Approval
Automatic duplicate/technical	Finance rules
Small standard refund	Support/finance role
Partial after production	Finance + service owner
Large/enterprise dispute	Finance + senior/legal

56. Editor не возвращает деньги

Редактор выбирает editorial outcome/reason. Billing engine по правилам определяет финансовое следствие. Это separation of duties.

57. Возврат должен порождать fiscal/document actions

ЮKassa умеет автоматически создавать чек возврата для своих чеков по данным исходного платежа. Но product workflow всё равно обязан отслеживать, что refund и fiscal correction завершены согласованно.

REFUND APPROVED → provider refund → refund succeeded → fiscal refund receipt → credit/order ledger → closing docs correction if necessary → client notification

58. Refund pending

Client sees: «Возврат оформлен» amount date destination provider status Not: mark "returned" before provider succeeded.

59. Duplicate payment

Должен быть отдельный fast-path. Не превращать очевидный дубль в 10-дневный спор.

60. Chargeback/dispute

provider dispute → freeze related refund automation → preserve evidence: order terms delivery publication communications receipts → finance/legal review.

61. Не хранить card PAN

«Матчасть» не должна самостоятельно хранить полные карточные данные. Используем hosted payment page/widget/tokenized payment method PSP.

62. Recurring payments

ЮKassa позволяет сохранять способ оплаты с согласия пользователя и проводить последующие автоплатежи. Для «Матчасти» recurring нужен не для публикационных credits, а прежде всего для будущего monitoring subscription.

P1: client explicitly enables AI Visibility Monitoring billing period price next_charge_at payment_method_id token cancel anytime per terms failure retry policy notifications.

63. Не включать auto-renew по умолчанию

Первое подключение monitoring — явное согласие. Checkout показывает период, сумму, дату следующего списания и способ отключения.

64. Subscription state

TRIAL? optional later ACTIVE PAYMENT_RETRY PAST_DUE CANCEL_AT_PERIOD_END CANCELLED SUSPENDED

65. Failed recurring charge

charge fails → notify → retry limited → grace period → pause new monitoring runs → preserve historical reports/publications Never: delete published article.

66. Dunning

Day 0: payment failed Day 1/3: retry Day 5/7: final reminder monitoring paused Exact: provider/business policy later.

67. Price change recurring

Не менять сумму silent recurring payment. Нужна notice policy и, если требуется, новое согласие/условия.

68. Invoice + online payment in one order

Order can offer: [Оплатить по счёту] [СБП] [Картой] Once one succeeds: other payment intents invalidate/close where possible.

69. Payment race

Если бухгалтер отправил банковский перевод одновременно с оплатой картой, система должна выявить double-funded order, а не подарить два независимых «оплачено».

70. Financial ledger

ledger_entry: DEBIT/CREDIT concept account amount currency order payment/refund credit batch document reason created_at immutable reference

71. Минимальный ledger — не полноценный бухучёт

Мы не строим 1С. Ledger нужен, чтобы product state, credits and provider money не расходились. Официальный бухгалтерский учёт остаётся в учётной системе/бухгалтерии.

72. Reconciliation

DAILY: provider transactions bank statement internal payments refunds fees compare: missing duplicate amount mismatch unknown payer failed webhook → reconciliation queue.

73. Reconciliation важнее красивого billing UI

Финансовая система считается рабочей, когда она умеет объяснить каждую разницу, а не когда dashboard красиво показывает MRR.

74. PSP fee ledger

payment gross 7 900 provider fee VAT on provider fee net settlement Store separately: gross revenue payment processing cost net bank receipt.

75. Не считать банковское поступление revenue напрямую

Net settlement от PSP уже уменьшено на комиссии. Revenue/order amount должен исходить из заказа и бухгалтерской модели, комиссия — отдельный cost.

76. 2026 correction to unit economics

Payment route	Likely processing economics
B2B bank transfer	Минимальная per-order комиссия, но bank/accounting ops
СБП	Обычно существенно дешевле карт; verify MCC/provider tariff
Card via YooKassa baseline	3.5% + 22% VAT on fee in cited tariff = effective ≈4.27%

77. Checkout cost-aware, но не manipulative

Для бизнеса: Рекомендуем: [Счёт] [СБП] [Карта] No fake warnings. No hidden fees.

78. Invoice expiry

invoice: issued_at due_at status expired: order not necessarily deleted client can regenerate at current/locked price policy.

79. Price lock

Рекомендуем фиксировать цену счёта на 5–10 рабочих дней или другой явно указанный срок. После expiry новый invoice может использовать новую pricing version.

80. Promo discount and invoice

discount captured in price snapshot invoice regenerated before expiry: same amount after promo expiry: new rules only if order itself expired/cancelled according terms.

81. VAT/tax display

Checkout не должен показывать «включая НДС 22%», пока фактический налоговый статус продавца это не подтверждает.

82. Currency

MVP: RUB only foreign client: bank/manual contract later Do not: add multi-currency before legal/payment need.

83. Receipts for foreign payer

Отдельно определить при international expansion. Не включать в MVP tax assumptions.

84. Postpay

Default: prepayment Enterprise later: postpay / credit terms only contract-approved Requires: credit risk invoice due accounts receivable collections workflow.

85. Не давать postpay self-service

Это коммерческий privilege, а не checkbox.

86. Accounts receivable later

invoice due overdue reminders finance owner service suspension legal escalation not P0.

87. Refund client UX

Order → [Запросить возврат] show: what has been completed potential refund according policy reason support No: mystery email-only process.

88. Но не обещать automatic amount до проверки сложного SKU

Для простого unused Publish система может показать точную сумму. Для Create/Research — «запрос будет рассчитан после проверки объёма выполненной работы».

89. Refund SLA

Internal decision: 1–3 business days target provider/bank delivery: depends on payment method/provider Client sees: decision time then payment provider state.

Сроки — продуктовая гипотеза, а не юридический норматив.

90. Billing support reasons

PAYMENT_NOT_FOUND DUPLICATE_PAYMENT WRONG_PAYER INVOICE_CHANGE REFUND CLOSING_DOCUMENT EDO VAT/TAX_DETAILS CREDIT_BALANCE SUBSCRIPTION OTHER

91. Finance roles

Role	Права
Client Billing	Invoices/docs/payments read
Finance Ops	Reconciliation, invoices, standard refund
Finance Admin	Adjustments, provider config
Editor	Не меняет деньги
Sales	Creates approved discount/quote, not ledger edits

92. Manual financial adjustment

Admin adjustment requires: amount reason ticket/order actor second approval above threshold audit Never: "credits +5" without record.

93. Audit events

invoice created payment confirmed credit granted credit reserved credit consumed refund requested refund approved refund succeeded document generated subscription enabled/cancelled manual adjustment billing profile changed.

94. Security

provider secrets только server-side;
webhook endpoints защищены и rate-limited;
billing admin требует MFA;
возврат не инициируется из public client JS;
critical finance actions audit;
payment metadata не содержит лишние персональные данные.

95. Webhook replay

event arrives twice → event ID/hash dedupe → already processed? yes: 200 OK, no duplicate ledger

96. Provider outage

Online payments unavailable → show invoice/bank transfer if available → do not lose order Bank reconciliation unavailable → payment pending → finance alert Publishing: already funded orders unaffected.

97. Fiscal provider outage

Если checkout design позволяет принять платёж при недоступной кассе, должен существовать documented recovery flow. Конкретную стратегию утвердить с провайдером/бухгалтером.

98. EDO outage

service already completed → document generation/sending queued → client sees delayed status → accounting alert → no duplicate documents.

99. Billing notifications

payment succeeded invoice expiring payment failed refund approved refund completed credit expiring closing document ready subscription renewal upcoming recurring payment failed.

100. Не спамить payment success несколько раз

Email от PSP, чек от ОФД, письмо «Матчасти» и invoice system могут одновременно отправить сообщения. Клиентский communication plan нужно сделать аккуратно.

101. Document download

Cabinet: Invoices Receipts where appropriate/reference Closing docs Refund docs Contracts/offer version files: immutable/versioned with dates.

102. Offer/contract version

order stores: terms_version offer_accepted_at refund_policy_version pricing_version Critical: future policy update does not silently rewrite historical order terms.

103. B2B individual contract

Enterprise: master contract appendix/spec order invoice UPD/docs Workspace: contract reference effective dates.

104. Contract hierarchy

Индивидуальный договор может переопределять стандартную оферту. Billing engine должен хранить contract profile, а не предполагать одинаковые refund/credit terms для всех.

105. Coupon/promo

promotion: code discount scope validity usage limit eligible account approval No: negative total stacking chaos.

106. Tax/accounting integration

P0: export CSV/XLSX provider reports bank statements document folder P1: accounting system integration EDO API Do not build: full general ledger / payroll.

107. Finance export

order_id payer INN amount SKU payment method paid_at provider fee refund service completed_at document state advertiser publication_id

108. Monthly finance close dashboard

Unmatched payments Pending refunds Failed receipts Missing closing docs Outstanding credits Expired credits Unfinished paid orders Provider reconciliation difference

109. Outstanding credits — реальное обязательство

Если продано 500 credits, а editorial capacity — 50/month, это operational liability. Finance dashboard должен показывать не только cash, но и оставшийся объём услуг.

110. Capacity reserve

credits outstanding: 180 estimated units: 240 editorial monthly capacity: 90 → 2.7 months backlog equivalent sales warning.

111. Пакеты нельзя продавать бесконечно

Cash upfront не должен создавать очередь, которую невозможно обслужить в SLA.

112. Refund vs credit compensation

Platform issue: offer: refund or replacement credit where legally/contractually appropriate Client chooses unless terms dictate. Do not force store credit when money refund is owed.

113. SLA credit

Позже можно компенсировать небольшое нарушение SLA service credit, но только если эта политика формализована и не заменяет обязательные возвраты.

114. Editorial rejection financial UX

Material rejected Reason: SEO_LINK_REQUEST Financial: Publication credit returned: +1 Editing charge: 0 Balance: 3 credits [Создать другой материал]

115. Create + Publish rejection UX

Production completed Publication rejected after unresolved policy issue Show: what component completed what credit returned what amount refundable if any appeal option No: opaque "денежные средства не возвращаются" for every scenario.

116. Refund policy must reduce gaming

Нельзя создать модель, где клиент заказывает полный Create, получает готовый текст, затем специально требует запрещённую ссылку и требует full refund.

117. Component completion events

BRIEF_COMPLETED DRAFT_DELIVERED EDITING_COMPLETED PUBLICATION_APPROVED PUBLICATION_LIVE MONITORING_STARTED REPORT_DELIVERED → financial entitlement rules.

118. Refund policy wording principle

Писать конкретно: что возвращается до начала работы, что происходит после подготовки текста, что происходит при редакционном отказе, что происходит после публикации, какие внешние результаты не гарантируются.

119. Trial / free promo

Не нужен платёжный «free trial» публикации. Бесплатные editorial publications и research participation — отдельные routes, а не коммерческий заказ на 0 ₽.

120. Zero-value order

Editorial free: commercial_order = none Pilot promo 100%: if ever used, store commercial context separately Do not mix: editorial choice with coupon logic.

121. Monitoring free preview

Можно дать limited baseline preview как acquisition feature, но recurring billing начинается только после явной покупки.

122. Invoice numbering

Юридическую нумерацию/форму документов определяет учётная система. Product order ID и invoice number не должны считаться одним и тем же полем.

123. IDs

order_id: internal UUID / human #1248 invoice_number: accounting-defined payment_provider_id: external refund_provider_id: external publication_id: content system All linked, none reused.

124. Money precision

Хранить деньги в целых минимальных единицах либо точном decimal, не float.

amount_minor = 790000 currency = RUB or Decimal(12,2) Never: float 7900.00 for ledger math.

125. Currency immutable per transaction

Refund currency matches supported original transaction flow. Multi-currency not P0.

126. Server responsibility

Frontend: shows checkout Backend: creates order/payment validates price talks PSP handles webhooks ledger refunds Client browser: never supplies trusted final amount.

127. Prevent price tampering

Backend derives amount from SKU + pricing version + authorized discount. Не доверять price=4900 из браузера.

128. Metadata to PSP

minimal: internal order reference billing customer reference if allowed safe description Do not send: private moderation notes verification docs unneeded personal data.

129. Payment description

Должно быть достаточно понятным для клиента, банка и reconciliation, но формулировку предмета расчёта согласовать с бухгалтером.

130. Billing observability

metrics: payment success rate payment method mix PSP latency webhook delay refund rate refund latency receipt failure reconciliation mismatch invoice conversion average fee % credit liability.

131. Payment method mix важен для margin

If: 70% cards effective PSP cost high vs 70% bank/SBP blended contribution meaningfully changes.

132. Обновлённый acquiring budget

В Mathchast_30 заменить универсальные «2.5% acquiring» на weighted processing cost:

processing_cost = bank_share × bank_cost + sbp_share × sbp_cost + card_share × card_effective_cost Example only: 30% bank 40% SBP 30% card → much lower than 100% card.

133. Не использовать 4.27% как вечную ставку

Это текущая иллюстрация по публичному базовому тарифу ЮKassa для карт при указанной 3,5% комиссии и НДС на комиссию. Реальный договор может иметь другую ставку.

134. Payment provider abstraction

interface: create_payment() get_payment() cancel_payment() refund() get_refund() create_invoice_link? optional save_payment_method() verify_webhook() implementation: YooKassaProvider

135. Bank transfer provider

separate adapter: InvoicePayment not pretend bank transfer is YooKassa payment.

136. Billing service boundaries

BILLING owns: orders prices payments credits refunds billing documents state CMS owns: publication/editorial state LEGAL owns: classification Integration: events.

137. Key events

OrderCreated PaymentSucceeded PaymentFailed CreditGranted CreditReserved CreditConsumed CreditReturned RefundRequested RefundSucceeded ServiceComponentCompleted ClosingDocumentDue SubscriptionRenewed SubscriptionPastDue

138. Event-driven linkage

PaymentSucceeded → order funded → grant credits → notify client PublicationApproved → consume reserved credit PublicationCompleted → closing doc due RefundSucceeded → ledger + client + fiscal/doc workflow.

139. Billing must not publish

Payment event никогда напрямую не вызывает PublicationPublished. Между деньгами и публикацией остаётся editorial/legal workflow.

140. Billing MVP UI

Client: Orders Credits Invoices Payments Documents Refunds Admin: Reconciliation Failed payments Refund queue Fiscal errors Documents due Credit liability.

141. What P0 includes

P0: SKU/order creation pricing snapshots B2B invoice manual/semi-auto bank reconciliation YooKassa card/SBP payment webhooks idempotency credit ledger payment/refund states full/partial refund basic fiscal integration billing profile invoice/document upload refund request finance admin queue audit log exports basic reconciliation.

142. P1

EDO/Diadoc bank statement API recurring monitoring saved payment methods automatic dunning closing document generation agency shared billing advanced reconciliation SLA credits finance integrations.

143. P2

second PSP enterprise postpay multi-currency multiple EDO providers advanced tax jurisdictions automated revenue recognition support partner/affiliate payouts if ever needed.

144. Что не входит в MVP

Не строим	Почему
Собственный карточный процессинг	PCI/security burden
4 PSP одновременно	Операционная сложность
Postpay self-service	Credit risk
Multi-currency	Нет launch need
Marketplace payouts	Матчасть не marketplace третьих СМИ
Полный бухгалтерский ERP	Не core
Авто-refund любых спорных услуг	Component/service review required

145. Критические pre-launch решения бухгалтера/юриста

1. Юрлицо / ИП и налоговый режим 2. НДС на услуги Mathchast 3. Предмет расчёта в чеках 4. Матрица ККТ: bank / card / SBP B2B / B2C 5. Refund fiscal process 6. Когда услуга считается оказанной 7. Closing docs / УПД 8. Credit/package accounting 9. Offer/contract refund wording 10. Recurring payment consent.

146. Критические технические тесты

Test: successful card failed card SBP success duplicate webhook duplicate click bank payment match wrong amount refund full refund partial receipt failure refund receipt expired invoice credit reserve/release double-funded order provider outage.

147. Financial invariant tests

Автотесты должны проверять не UI, а инварианты.

No credit without funding No negative credit balance Refund ≤ refundable amount Consumed credit cannot disappear Every ledger entry balanced/traceable Provider succeeded amount = expected order amount One external transaction processed once.

148. Launch recommendation

B2B customer: default invoice Fast payment: SBP Card: available convenience YooKassa: single PSP candidate Fiscal: approved single solution Documents: manual/accounting first → EDO automation after demand.

149. Самый важный пересмотр предыдущего документа

Mathchast_30 следует позже обновить по фактической платёжной смеси. В 2026 карточная комиссия на публичном базовом тарифе ЮKassa для услуг может быть существенно выше предположенных 2,5%; при этом B2B bank transfer и СБП могут заметно снизить weighted processing cost. Поэтому unit economics нельзя строить на одной acquiring ставке.

150. Решение документа

Утвердить B2B-first billing architecture: счёт/банковский перевод как основной путь, ЮKassa как кандидат единственного PSP для карт/СБП и будущих recurring payments, внутренний immutable ledger для orders/payments/credits/refunds и component-based refund policy. Заказ, платёж, credit, publication и closing document являются отдельными сущностями. Оплата не обходит модерацию. Credits выдаются и списываются через ledger; publication credit при редакционном отказе возвращается, а уже оказанная production/editing часть учитывается отдельно. Refund поддерживает полный и частичный сценарии и синхронизируется с fiscal/document workflow. ККТ, НДС, УПД и точные моменты оказания услуги до запуска утверждаются бухгалтером/юристом. Recurring billing появляется только для monitoring после явного согласия клиента. Все provider callbacks идемпотентны, платежи ежедневно reconciled, а outstanding credits учитываются как реальная будущая editorial нагрузка.

151. Что этот документ разблокирует

Mathchast_31 billing → Mathchast_32 publication health analytics → Mathchast_33 AI visibility → Mathchast_34 before/after methodology → Mathchast_35 next best publication → Mathchast_37 agency workspace → Mathchast_40 technical architecture → Mathchast_41 security/privacy/backups → Mathchast_43 MVP roadmap

Источники исследования

Рекомендация ЮKassa как первого PSP, матрица refund, credit consumption event, 12-месячный срок credits, invoice price-lock, ledger architecture, recurring monitoring flow, роли, SLA и P0/P1/P2 scope являются проектными решениями «Матчасти». Налоговые и бухгалтерские выводы в этом документе не заменяют заключение бухгалтера/юриста: перед запуском нужно утвердить конкретную схему ККТ, налоговый режим, НДС, фискальные реквизиты и закрывающие документы.