Чаще всего знание человека об оплате ограничивается, но сценариев на самом деле намного больше. Я кратко пройдусь по каждому из этапов, чтобы у вас, как у владельца бизнеса сложилась абсолютно четкая картинка, когда вы будете подключать оплату на своем сайте.
Зачем вам это знать? Ну вот например, один из наших клиентов при создании маркетплейса хотел нанять дополнительного бухгалтера, чтобы тот занимался клиентскими выплатами, а мы предложили другой сценарий. Какой? Узнаете дальше.
Максим
CEO
Оплачиваем заказ на сайте
Чаще всего нажимаем оплатить, переходим на страницу стороннего сервиса, вводим данные карточки или используем apple pay, после чего деньги списываются.
Бывают у платежных систем виджеты – после нажатия “оплата”, всплывает окно прямо на сайте, далее вводим данные карты, код из смс, после чего окно закрывается – значит, оплата прошла.
Не забывайте, что здесь и далее еще до этапа разработки стоит всегда подключать тестировщиков, чтобы они прошлись по всем возможным сценариям и предусмотрели любые сложности, которые могут возникнуть у ваших клиентов при внесении денег. Ведь это очень щепетильная тема, которая волнует даже очень опытных пользователей. Просто представьте, как они волнуются, если не закрылось окно, не всплыло жизнеутверждающее «оплата прошла успешно», появилось пугающее – «сессия окончена», и вообще не ясно, что дальше делать. Позвольте сделать ваш сервис максимально удобным и комфортным, чтобы люди к вам возвращались.
Есть еще ссылки на оплату. Такой способ тоже имеет место быть для некоторых некрупных бизнесов. Она формируется лично, после конкретного заказа и высылается любым удобным способом.
Лично мой, самый любимый способ — привязка карточки. Один раз ввел данные и забыл. Я так в Dodo сделал. Иногда даже заказываю именно там, а не где-то в другом месте, потому что там привязана карта, и мне не нужно ничего вводить.
А что если данные карты
«утекут» в сеть?
Что касается страхов о краже личных данных, спешу вас успокоить: сайты их не хранят. Для этого им требовалось бы пройти очень дорогую сертификацию PCI DSS. А в этом нет смысла, потому что данные карты хранит сама платежная система, которая и гарантирует безопасность. Например, в наших проектах в базе данных хранится только хэш, и мы по нему дергаем данные для оплаты. Поэтому не стоит бояться.
Оплата в мобильном приложении
Такие же сценарии используются и для мобильных приложений. С одним только НО. Вы не можете уводить клиента из приложения на сайт для оплаты или верификации. Поэтому все операции должны происходить внутри. Приложение вызывает браузер, он открывается внутри web view, и вы совершаете все действия по оплате. Например, Apple не позволяет размещать приложение в сторе, если списание происходит по другому сценарию.
Какие есть типы платежей?
1
Подписки (рекуррентные платежи, автоплатежи) — привязали карту и списания происходят в какой-то определенный срок и/или определенная сумма.
2
Холдирование (некоторые это называют “безопасная сделка”) — блокировка n-ной суммы у пользователя, которая может быть списана/разблокирована после выполнения какого-то сценария. Очень популярный способ оплаты, например, на маркетплейсах. Есть продавец, который отфотографировал товар, выложил. Есть покупатель – ему нужно получить товар и подтвердить, что это именно то, что было заявлено продавцом. После этого захолдированная сумма поступит на счет продавцу. Также действуют автопрокаты, когда требуют депозит.
3
Сплитование. Тоже популярный сценарий для маркетплейсов. В случае, когда покупатель оплатил некую сумму. Из нее 20% получает сайт, 80% – продавец. Самый правильный вариант, распределять деньги сразу при получении транзакции. Такой же сценарий используется при покупке товаров сразу у нескольких поставщиков на одной площадке. Следовательно, вы, как владелец маркетплейса будете получать себе на счет только чистую прибыль.
Это классно, но знаю, что некоторые предпочитают принимать все деньги себе на счет, проводить с ними какие-то операции и рассчитываться с поставщиками только раз в месяц. В таком случае можно будет зарабатывать еще и на процентах от банка.
Максим
CEO
4
Платежи в рассрочку. Благодаря финансовым возможностям платежных систем, в России стали предлагать оплачивать товары и услуги в рассрочку прямо на сайте, без обращения в банки.
А что если деньги надо не получить, а выплатить?
1
Массовые выплаты. Например, вы – биржа, у вас месяц работают люди, каждый сколько-то заработал, а в конце месяца, вам необходимо с ними со всеми рассчитаться. При этом платежные системы сейчас умеют выплачивать в разные каналы (например, когда у кого-то привязана карточка, у кого-то paypal, у кого-то счет в банке – вы загружаете список на зачисление, он отправляет каждому в свой канал, конечно, за минусом комиссии).
2
P2P выплаты (перевод с одной карты на другую). Работают по сути, как привязанная карта. Самый прикольный сценарий – оставить чаевые официанту, когда у вас с собой нет налички. Соответственно, с одной стороны надо списать деньги, с другой – зачислить. Для списания используем один из сценариев описанных выше. Для зачисления, в зависимости от выбранного payment-провайдера, либо просто ввести номер карты, либо надо будет привязать карту, а вам – обеспечить хранение хэша. Мы, например, делали личный кабинет для официантов, где они могли ввести данные своей карты, чтобы получить начисленные средства.
3
Возвраты. Важно обратить внимание на этот сценарий, особенно при выборе провайдера. Еще механизм возврата товаров важен при разработке. Поэтому этот вопрос, тоже обязательно надо продумывать как на этап прототипирования, так и при расчете сроков разработки с учетом интеграций.
Если нужны консультации, feel free to connect us. Возможно, сейчас вы далеки от этого, но в будущем это позволит вам оптимизировать бизнес за счет его автоматизации.
Максим
CEO
