Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
Payment request должен знать booking context
Сумма без даты, специалиста и service id не помогает поддержке при переносе или отмене записи.
Клиники, салоны и сервисные команды часто берут предоплату, депозит или полную оплату до визита. Если payment link не связан с booking context, оператору сложно понять, за какую услугу заплатил клиент и можно ли переносить запись.
Backend должен хранить service id, appointment time, branch, specialist, amount, currency, expiration and CRM reference. После verified payment запись получает controlled status, а не ручную заметку в чате.
- связывать payment request с appointment id;
- фиксировать branch, specialist и time slot;
- не хранить медицинские детали в платежном событии;
- показывать pending/paid/expired/manual review в CRM.
No-show, перенос и отмена должны быть правилами
Депозит работает только если заранее понятно, что происходит при опоздании, переносе или отмене.
Платежная интеграция не должна решать медицинские или сервисные правила, но она должна уметь их технически поддержать. Например, если клиент отменил запись до дедлайна, система показывает доступный refund path; если запись перенесена, payment context сохраняется.
Важно не смешивать cancellation, refund and no-show в один статус. Это разные события с разными правами доступа, сроками и audit trail.
- хранить cancellation window и policy version;
- перенос записи не должен терять payment reference;
- refund требует отдельного reason и actor;
- manual exception должен попадать в audit log.
Privacy и сверка важнее лишних данных
Платежному backend обычно не нужны медицинские детали, ему нужны ids, суммы, статусы и audit trail.
Для клиник особенно важно минимизировать данные в платежном слое. Payment backend должен видеть идентификаторы записи, сумму, валюту, provider reference and status, но не должен хранить лишние медицинские или чувствительные данные.
Ежедневная сверка сравнивает provider payments, appointment statuses, CRM records and refunds. Так команда видит оплаченные записи, отмены, no-show cases и исключения без ручного сбора таблиц.
- минимизировать персональные данные в payment log;
- сверять paid appointments с provider report;
- показывать refunds и no-show отдельно;
- ограничить доступ к sensitive CRM context.
FAQ
Можно ли хранить детали услуги в платежном backend?
Лучше хранить только нужные ids, сумму, валюту и статус. Детали услуги и чувствительный контекст должны оставаться в CRM/booking system с ограниченными правами.
Что делать при переносе записи после оплаты?
Сохранить payment reference и связать его с новой датой записи через controlled status change. Нельзя терять историю исходного платежа.
Как обрабатывать no-show?
Через заранее описанные правила: cancellation window, deposit policy, manual review and audit trail. Платежный слой должен поддержать правило, а не принимать бизнес-решение сам.
