Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
Когда payment link лучше обычного checkout
Платежная ссылка полезна там, где заказ создает менеджер, CRM или внутренний процесс, а не корзина сайта.
Payment link подходит для B2B-счетов, услуг, предоплат, индивидуальных сумм, ручных продаж и сценариев, где клиент приходит из CRM, мессенджера или e-mail. В отличие от обычного checkout, ссылка должна быть связана с конкретным счетом или сделкой.
Ключевой риск - отправить клиенту ссылку, которую CRM не сможет однозначно сопоставить с invoice. Тогда менеджер видит оплату отдельно, счет отдельно, а бухгалтерия закрывает день вручную.
- связать ссылку с CRM deal, invoice или order id;
- задать сумму, валюту, назначение и срок действия;
- создавать ссылку идемпотентно, чтобы не плодить дубли;
- показывать клиенту понятные success, fail и pending страницы.
Какие правила нужны до отправки ссылки
Менеджер не должен каждый раз решать, когда ссылка истекла, можно ли менять сумму и что делать с повторной оплатой.
Перед запуском payment links нужно описать правила: можно ли менять сумму после отправки, сколько действует ссылка, как отменить ссылку, что делать с повторной попыткой и как закрывать счет при частичной оплате.
Без этих правил платежные ссылки начинают жить вне CRM. Менеджер отправляет новую ссылку при каждом вопросе клиента, клиент оплачивает старую, webhook приходит по устаревшему invoice, а поддержка разбирает конфликт вручную.
- фиксировать amount/currency после отправки;
- хранить expiration и cancelled status;
- создавать новую payment attempt без нового счета;
- логировать кто создал, отправил и отменил ссылку.
Как синхронизировать оплату обратно в CRM
CRM должна получать не raw provider response, а нормализованный результат с понятным действием для менеджера.
После оплаты backend должен проверить статус у провайдера или принять доверенный webhook, затем обновить CRM-счет, сделку, задачу менеджера и audit trail. Нельзя полагаться только на письмо клиенту или redirect.
Для менеджера важны paid, pending, failed, expired, refunded и manual review. Для учета нужны amount, currency, provider reference, paidAt, fiscal status и связь с invoice. Для поддержки - request id и история повторных доставок.
- обновлять CRM только после server-side verification;
- использовать idempotency для webhook и CRM update;
- отправлять менеджеру задачу только по исключениям;
- включить payment link в ежедневную сверку.
FAQ
Можно ли отправлять клиенту одну и ту же payment link несколько раз?
Да, если ссылка активна и связана с тем же счетом. Но повторная отправка должна логироваться, а статус счета должен обновляться только один раз по финальному платежу.
Что делать, если клиент оплатил старую ссылку?
Backend должен определить invoice/payment attempt, проверить статус и перевести случай в paid или manual review. Старые ссылки лучше отменять при выпуске новой.
Нужно ли делать payment links отдельным каналом сверки?
Нет. Их лучше включать в общую сверку платежей вместе с сайтом, CRM, ERP и возвратами.
