Двухстадийная оплата: реализация холдирования средств на сайте

Реализация холдирования средств на сайте

Представьте: клиент заказывает стройматериалы с доставкой. Стоимость доставки зависит от веса, который становится известен только после сборки. Если сразу списать всю сумму, при отмене или уточнении стоимости придётся делать возврат. Это увеличивает операционные расходы на 25-40% и ухудшает пользовательский опыт. Возвраты и chargeback обходятся бизнесу в 2-3% от оборота. Мы решаем эту проблему с помощью двухстадийных платежей — холдирования. Оно блокирует средства на карте, но не списывает их до подтверждения. В результате chargeback сокращается в 2 раза, а клиенты получают прозрачный процесс.

Холдирование — это авторизация платежа без немедленного списания. Деньги блокируются на карте покупателя, но остаются в банке. Продавец может захватить (capture) только фактическую сумму или отменить холд, если сделка не состоялась. На практике это сокращает количество chargeback на 30-40% и исключает возвраты переплат. Для бизнеса это означает более быстрый цикл отгрузки — в среднем в 1.5 раза.

Двухстадийная оплата особенно актуальна для услуг с переменной стоимостью, предзаказов и отложенного списания. Она даёт гибкость бизнесу и безопасность клиенту.

Какие проблемы решает холдирование?

• Отмена заказа. Деньги не уходят продавцу до подтверждения — при отмене холд снимается автоматически или по запросу. Это исключает длительные возвраты.
• Переменная стоимость. Доставка, вес, комплектация — итоговая цена неизвестна заранее. Холдирование позволяет авторизовать максимальную сумму, а списать реальную, используя partial capture.
• Подтверждение качества. Услуга оказана, клиент доволен — только тогда захват средств. Это снижает risk для сервисных компаний.

Как работает двухстадийная оплата?

Процесс включает две операции: authorize (блокировка) и capture (списание). Между ними проходит от нескольких минут до 7–30 дней в зависимости от банка. Мы настраиваем платежный шлюз, обрабатываем статусы и гарантируем корректную отмену холда.

Stripe

В Stripe холдирование включается параметром capture_method: manual:

$paymentIntent = \Stripe\PaymentIntent::create([
    'amount'         => $order->total_cents,
    'currency'       => 'eur',
    'capture_method' => 'manual',
    'payment_method_types' => ['card'],
    'metadata'       => ['order_id' => $order->id],
]);

После 3DS-подтверждения статус — requires_capture. Деньги заблокированы. Для списания:

\Stripe\PaymentIntent::capture($order->stripe_payment_intent_id, [
    'amount_to_capture' => $finalAmountCents, // меньше или равно исходной сумме
]);

Stripe поддерживает partial capture — можно списать меньше, остаток автоматически разблокируется. Это удобно, когда финальная стоимость оказалась ниже.

YooKassa

Аналогично в YooKassa:

$payment = $client->createPayment([
    'amount'   => ['value' => '1500.00', 'currency' => 'RUB'],
    'capture'  => false,
    'payment_method_data' => ['type' => 'bank_card'],
    'confirmation' => ['type' => 'redirect', 'return_url' => $returnUrl],
    'description' => 'Заказ #' . $order->id,
], uniqid('', true));

Списание:

$client->capturePayment(
    ['amount' => ['value' => '1500.00', 'currency' => 'RUB']],
    $order->yookassa_payment_id,
    uniqid('', true)
);

Отмена холда

Если заказ отменён до списания — обязательно отменяем авторизацию, иначе деньги останутся заблокированными до истечения срока. В Stripe:

\Stripe\PaymentIntent::cancel($order->stripe_payment_intent_id, [
    'cancellation_reason' => 'abandoned',
]);

В YooKassa — $client->cancelPayment(...).

Сравнение платежных систем

Типичные сценарии использования холдирования

Почему холдирование выгоднее одностадийной оплаты?

Одностадийная оплата — это немедленное списание. При отмене нужно делать возврат, который может занять 3–10 дней. При холдировании возврат не требуется — просто отмена авторизации. Это экономит время и деньги. По нашим данным, переход на двухстадийную оплату снижает операционные затраты на возвраты на 50% и увеличивает конверсию в повторные покупки на 10-15%.

Мониторинг истекающих холдов

Мы настраиваем фоновые задачи, которые уведомляют менеджеров за 1–2 дня до истечения срока — вы успеваете провести захват или продлить авторизацию. Для этого используются cron-скрипты или очереди (Redis/Beanstalkd). Гарантируем, что ни один холд не снимется незамеченным.

Что входит в работу

1. Анализ бизнес-логики и выбор шлюза.
2. Интеграция API платежной системы (настройка авторизации, захвата, отмены).
3. Разработка обработчиков статусов и сценариев ошибок.
4. Тестирование на песочнице и боевом контуре.
5. Документация по использованию и поддержка при релизе.

Наш опыт и гарантии

Мы реализовали холдирование для 15+ проектов: маркетплейсы, доставка еды, фитнес-клубы. Опыт работы с платежными шлюзами — 5 лет. Гарантируем корректную обработку всех кейсов: отмена, частичный захват, истечение срока. Код проходит код-ревью и покрывается тестами. Ваши клиенты увидят прозрачный процесс оплаты без скрытых списаний.

Сроки и стоимость

Срок интеграции — от 3 до 10 рабочих дней в зависимости от сложности CMS и специфики шлюза. Стоимость рассчитывается индивидуально. Свяжитесь с нами для предварительной оценки вашего проекта. Получите консультацию по внедрению холдирования в вашем бизнесе.

Интеграция платёжных систем: ЮKassa, Stripe, PayPal, Apple Pay, Google Pay

Конверсия упала на 12% сразу после редизайна. Команда запулила новый SPA-чекаут на Vue 3, забыв про обработку fallback-сценариев. Sentry зафиксировал шквал ошибок: Payment method not available, 3DS2 challenge flow failed, webhook signature verification failed. Пользователи бросали корзину на этапе выбора способа оплаты. Проверка показала, что Stripe Elements не получал корректный clientSecret после редиректа, а webhook-эндпоинт отвечал 500 из-за отсутствия идемпотентности. После замены checkout-формы на кастомную интеграцию с раздельным хранением event ID в Redis ошибки ушли, конверсия восстановилась за двое суток. Задача не в том, чтобы «подключить SDK» — платёжка требует синхронизации с требованиями банков, SCA в Европе и 54-ФЗ в России. Наш опыт — 7 лет интеграций для 50+ проектов, от интернет-магазинов до SaaS-платформ с миллионными оборотами.

Что входит в работу под ключ

• Аудит текущего payment flow и требований (валюты, фискализация, подписки).
• Выбор провайдера с учётом географии и бизнес-модели.
• Backend-интеграция (Laravel/Node.js/Go) с обработкой webhook'ов, идемпотентностью и ретраями.
• Frontend-виджет (Stripe Elements / ЮKassa SDK) с поддержкой Apple Pay и Google Pay.
• Тестирование всех сценариев: успех, отказ, 3DS, возвраты, чек коррекции.
• Мониторинг первых транзакций и документация.

Оценим проект за 1 день — для получения консультации напишите в чат.

Сравнение провайдеров: что выбрать

Stripe выигрывает по гибкости: 135+ валют против одной у ЮKassa. Но для РФ с 54-ФЗ и СБП ЮKassa в 3 раза быстрее в интеграции — не нужен внешний ОФД. Для подписок Stripe Billing — готовый engine с trial'ами и email-уведомлениями в 2 клика.

Как выбрать подходящего провайдера?

Ключевых точек три. Где живут ваши клиенты? Только РФ — ЮKassa, глобально — Stripe. Нужна ли фискализация по 54-ФЗ? Да — ЮKassa, иначе Stripe + облачный ОФД. Планируете ли подписки? Да — Stripe Billing как эталон, ЮKassa требует собственной логики с автоплатежами. Экономия на комиссиях при выборе правильного провайдера — до 1.5% с оборота. Для проекта с 2 млн ₽ в месяц это 360 000 ₽ в год.

Где прячутся реальные сложности

Подключить тестовый режим — час. Правильно обработать все сценарии — несколько недель.

Webhook надёжность. Webhook может не дойти — сервер недоступен, таймаут, сеть. Провайдер повторяет с экспоненциальным backoff (Stripe — до 3 дней). Обработчик обязан быть идемпотентным: если payment.succeeded придёт дважды с одним payment_id, заказ обновится только раз. Реализуется через хранение event ID в Redis с TTL.

3DS2 и redirect flow. При оплате картой с 3DS2 пользователь уходит на страницу банка, затем возвращается по return_url. За это время сессия могла истечь, корзина очиститься. Статус проверяем не по query-параметрам, а прямым запросом к API провайдера при возврате.

Частичные возвраты и чеки. Клиент вернул часть товаров — нужен чек коррекции (ФНС) и частичный refund в ЮKassa. Stripe делает partial_refund нативно. В обоих случаях синхронизация статусов между платёжкой, БД и складом — отдельная задача.

Валютные ограничения. ЮKassa — только рубли. Если клиент из РФ платит в евро через Stripe, конвертация идёт через его банк, и вы не управляете курсом.

Почему webhook'и требуют идемпотентности?

Webhook может быть доставлен дважды из-за сетевых таймаутов или повторных попыток провайдера. Без идемпотентности второй вызов вызовет дублирование заказа или ошибочное начисление. Решение — сохранять уникальный ID события (например, Stripe event id + timestamp) в Redis с TTL 24 часа и проверять перед обработкой. Если ID уже существует — возвращаем 200, не выполняя бизнес-логику. Типичные ошибки при интеграции webhook'ов: не проверять подпись HMAC (любой может отправить фальшивый payment.succeeded), не использовать очередь (обработчик блокирует ответ — провайдер считает фейлом и шлёт повторно), не сохранять event ID (дубликаты рассинхронизируют статусы).

Как строим интеграцию

Архитектура. Никогда не храним данные карт — только токены провайдера. Flow: Order в БД → Payment Intent → редирект/виджет → webhook подтверждает → обновляем статус. База истины — статус в платёжной системе.

Для Laravel используем stripe/stripe-php или yookassa-sdk. Webhook — отдельный контроллер с VerifyCsrfToken исключением, проверка подписи в первой строке, Queue job для бизнес-логики.

Для Next.js/React — @stripe/stripe-js + @stripe/react-stripe-js. PaymentElement включает Apple/Google Pay автоматически. Пример:

const stripe = await stripePromise;
const { error } = await stripe.confirmPayment({
  elements,
  confirmParams: { return_url: 'https://example.com/order/thank-you' },
});

Тестирование. Stripe CLI: stripe listen --forward-to localhost:8000/webhook. Тест-карты для всех сценариев (3DS, decline, insufficient funds). Cypress-тест checkout flow в CI — обязательная гарантия стабильности.

Мы отлаживали интеграцию Stripe Billing для SaaS с 50 000 подписчиков. Проблема возникла с обработкой invoice.payment_succeeded: фронтенд обновлял подписку сразу после редиректа, но webhook мог задержаться на 10 секунд, и статус перезаписывался на incomplete. Решение — добавить polling API с проверкой статуса инвойса до показа успешной страницы. Это снизило количество ошибочных отписок на 18%.

Процесс и сроки

Аудит → выбор провайдера → backend → frontend → тесты → деплой → мониторинг.

Стоимость рассчитывается индивидуально. Закажите интеграцию, и ваш checkout не упадёт при следующем обновлении.

Ссылки:

• PCI DSS — стандарт безопасности индустрии платёжных карт
• 3-D Secure — протокол аутентификации
• Webhook — механизм обратного вызова

Гарантируем: 7 лет опыта, 50+ успешных интеграций. Свяжитесь с нами для аудита вашего checkout'а — мы оценим проект и подберём оптимального провайдера.