Stripe — не эквайринг, а очень дорогая зависимость от одного API

Stripe — не эквайринг, а очень дорогая зависимость от одного API

Пока у вас один продукт, одна страна и один сценарий оплаты, Stripe выглядит как магия. Но магия заканчивается там, где начинаются: холды, спорные чарджбеки, редкие BIN-ы, локальные методы оплаты и внезапный риск-ревью. Идемпотентность или смерть: если ваш флоу не переживает ретраи, дубли и отложенные вебхуки, вы уже сидите в клетке, просто решётки пока полированы.

Главная ловушка — архитектурная. Вы строите бизнес вокруг чужих примитивов: intents, captures, refunds, subscriptions, dispute flows. Потом выясняется, что:
— локальные оплаты живут отдельно от карточного мира;
— рекурренты ломаются на смене карты и 3DS;
— payout-логика и сеттлмент не совпадают с вашей бухгалтерией;
— ваш мерчант забанен без объяснения причин, а вместе с ним — и весь cashflow.

Документация — это ложь, логи — истина. В интеграции с Stripe надо с самого начала закладывать слой абстракции: свой state machine, свой ledger, свою обработку вебхуков, свою систему reconciliation. Иначе любой «простой» переход на другого PSP превращается в переписывание ядра продукта. Костыль на костыле и финтехом погоняет — особенно когда всё завязано на один account, один API key и одну точку отказа.

Вывод простой: Stripe хорош как стартовая батарейка, но плох как фундамент. Если планируете масштаб, сразу проектируйте выход из клетки: не храните бизнес-логику внутри SDK, не верьте одному webhook, не делайте payment flow без независимого сверочного контура.