Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
Donation payment должен быть связан с campaign context
Сумма без campaign id, donor consent и источника формы не помогает фонду закрывать отчетность и поддержку.
Благотворительные сборы, фонды, НКО и социальные проекты часто запускают несколько кампаний одновременно. Если payment link или форма не знает campaign id, источника, суммы, валюты и donor consent, команда потом вручную восстанавливает, к какому сбору относится платеж.
Надежная схема создает donation payment request из controlled form: campaign id, donor record, public/private donation preference, amount, currency, request id and expiration фиксируются до оплаты. CRM получает только verified status после webhook или server-side status lookup.
- связывать каждый платеж с campaign id;
- фиксировать donor consent и communication preference;
- не отмечать donation как received по return URL;
- разделять public donor display и внутренний CRM record.
Recurring donations и receipts зависят от правил
Повторные донаты, квитанции и налоговые документы нельзя обещать без провайдера, договора и актуальных требований.
Команды часто хотят recurring donations, автоматические письма и receipt-like documents. Технически это разные процессы: one-time payment, recurring intent, reminder, accounting document, donor notification and legal/tax review. Их нельзя смешивать в один payment status.
Если provider или договор не поддерживает automatic recurring charge, безопасный старт - donation links, reminders and donor CRM tasks. Юридические, налоговые и отчетные требования нужно проверять по актуальным правилам организации и провайдера.
- не обещать автосписание без provider support;
- receipt status хранить отдельно от payment status;
- donor notification не должна раскрывать лишние данные;
- manual correction должен иметь actor, reason и timestamp.
Privacy и сверка важнее красивого счетчика
Публичный прогресс сбора полезен, но backend должен защищать donor data и сверять кампанию по verified payments.
Donation page может показывать progress, список доноров или анонимные суммы, но платежный backend должен хранить только нужные ids, статусы и ссылки на CRM. Лишние персональные данные не должны попадать в публичный слой или технические логи.
Сверка сравнивает campaign goal, verified payments, refunds, donor preferences, CRM records and provider report. Так команда видит, какие кампании закрываются, где есть refund или dispute, и какие платежи требуют ручного review.
- минимизировать donor data в payment log;
- публичный progress считать по verified payments;
- refund не должен удалять original donation;
- сверять CRM, provider report и accounting export.
FAQ
Можно ли показывать донат на сайте сразу после return URL?
Лучше показывать публичный прогресс после verified payment event. Return URL может открыться до финального статуса платежа.
Можно ли сделать регулярные донаты?
Только если провайдер, договор и правила организации поддерживают recurring charge. Иначе безопаснее использовать payment links, reminders и donor CRM tasks.
Какие данные донора хранить в платежном backend?
Только минимально нужные ids, consent/status fields и provider references. Публичные имена, контакты и предпочтения лучше хранить в CRM с ограниченными правами.
