Какво е платежен шлюз? Как работят онлайн плащанията, обяснено
Платежният шлюз е услугата, която сигурно приема данните за плащане на клиента при касата, предава ги към банките и картовите мрежи за одобрение и връща „одобрено“ или „отказано“ — обикновено в рамките на няколко секунди. Той е мостът между приложението ви и финансовата система. Stripe, PayPal, Adyen, Square и Braintree са известни примери.
Днес повечето от тези компании обединяват шлюза с всичко друго, което ви трябва, за да получавате плащания, затова „платежен шлюз“, „платежен процесор“ и „платежен доставчик“ често означават едно и също.
Защо платежните шлюзове са важни, когато строите с AI
„Добави плащания“ е една от най-честите молби към AI платформите и една от най-лесните за объркване по тънък начин. Самият код обикновено е кратък. Важните неща са решенията около него:
- Кой доставчик подхожда на вашия бизнес, държава и продукт.
- Къде работи кодът. Секретните ключове за плащания трябва да остават на сървъра, никога в браузъра.
- Как приложението разбира, че плащането е успешно. Надеждният начин е webhook от доставчика — не клиентът да попадне на страница „Благодарим“.
- Вашите правни и данъчни отговорности, които зависят от това кой е търговецът на записа.
Разбирането какво прави шлюзът ви помага да давате ясни инструкции и да проверите, че резултатът е безопасен.
Ежедневна аналогия
Представете си плащане с карта в магазин.
Терминалът на касата е шлюзът: той чете картата ви сигурно и изпраща заявката. Той не решава нищо — подава въпроса „може ли този човек да плати 40 евро?“ по верига към банката ви и получава отговора обратно. Банката на магазина (acquirer) и вашата банка (issuer) вземат решението чрез картовата мрежа (Visa, Mastercard), която ги свързва.
Онлайн платежният шлюз е същият терминал, пренесен в уеба — плюс сигурността да се обработват данни за карти, които пристигат през интернет.
Как работи онлайн плащане с карта
Ето какво се случва в няколкото секунди след като клиентът натисне „Плати“:
| Стъпка | Какво се случва | Кой го извършва |
|---|---|---|
| 1. Каса | Клиентът въвежда данните на картата във формата за сигурно плащане | Формата или страницата на доставчика |
| 2. Криптиране | Данните се криптират и изпращат към шлюза | Шлюз |
| 3. Заявка за авторизация | Заявката отива към картовата мрежа и банката на клиента | Процесор, картова мрежа |
| 4. Проверки | Банката проверява наличност и сигнали за измама и може да поиска допълнителна верификация, например 3D Secure | Банката издател |
| 5. Отговор | Одобрение или отказ се връщат към приложението ви | Шлюз |
| 6. Уреждане и сетълмент | Парите се събират и след графика за изплащане на доставчика се превеждат на банковата ви сметка, намалени с таксите | Процесор, acquirer |
Две неща си заслужава да знаете:
- Авторизацията не е същото като получаването на пари. Сумата първо се резервира, после се снима (capture), после се уреджда по сметката ви — често след дни.
- Приложението ви изобщо не трябва да вижда номера на картата. Съвременните доставчици дават хостната страница за плащане или вградени полета, които контролират те, а приложението ви получава само препратка към плащането.
Основните части и кой какво прави
| Част | Какво е |
|---|---|
| Платежен шлюз | Сигурно приема данните за плащане и ги предава нататък. |
| Платежен процесор | Премества данните на транзакцията между банките. |
| Търговска сметка | Сметката, която получава картовите плащания от ваше име. Доставчици като Stripe я включват в пакета. |
| Acquirer | Банката от страната на търговеца. |
| Issuer | Банката на клиента, която одобрява или отказва. |
| Картова мрежа | Visa, Mastercard и други, които свързват acquirer и issuer. |
| Търговец на записа (merchant of record) | Бизнесът, който законово продава на клиента и отговаря за данъците, възвръщанията и спорове. |
Някои доставчици (Paddle, Lemon Squeezy) действат сами като търговец на записа, като поемат ДДС и данъците вместо вас срещу по-високи такси. Други (Stripe, PayPal) ви оставят като търговец на записа, с опционални данъчни инструменти. За честен преглед на опциите вижте Stripe срещу Paddle срещу Lemon Squeezy и Stripe срещу PayPal.
Практически пример: продажба на курс
Продавате онлайн курс за 99 евро и искате от AI платформата да добави бутон „Купи“.
- Клиентът натиска Купи. Вашият сървър използва секретния си ключ, за да поиска от доставчика да създаде сесия за плащане за 99 евро, и получава обратно линк.
- Клиентът се пренасочва към хостната страница за плащане на доставчика, въвежда картата си и преминава през 3D Secure проверка с банката си, ако се налага.
- Плащането е одобрено и клиентът се пренасочва към вашата страница „Успешно“.
- Отделно доставчикът изпраща webhook към вашия сървър: „плащането за сесия X е успешно“. Сървърът проверява подписа на webhook-а, намира поръчката, маркира я като платена и отключва курса.
- Няколко дни по-късно парите, минус таксите, пристигат на банковата ви сметка.
Стъпка 4 е най-важна. Ако отключите курса на страницата „Успешно“, всеки, който намери този адрес, може да го получи безплатно, а клиентите, чийто браузър се е затворил рано, ще платят и няма да получат нищо.
Ключови термини
| Термин | Значение |
|---|---|
| Сесия за плащане (checkout session) | Еднократна страница или процес за плащане, създаден от вашия сървър за конкретна покупка. |
| Тестов режим | Пясъчник, в който използвате тестови ключове и тестови номера на карти — не се движат реални пари. |
| Публикуем / секретен ключ | Публикуемият ключ може да се появи в браузърния код; секретният трябва да остане на сървъра. |
| 3D Secure | Допълнителна стъпка, при която клиентът потвърждава плащането пред банката си; в Европа е обичайна по правилата за силна клиентска автентикация (SCA). |
| PCI DSS | Стандартът за сигурност в картовата индустрия за всеки, който работи с данни за карти. |
| Възвръщане / оспорване (chargeback) | Когато клиент оспори плащане при банката си и парите бъдат върнати обратно. |
| Възстановяване (refund) | Връщане на пари от вас, доброволно. |
| Изплащане (payout) | Прехвърляне на събраните ви пари от доставчика към банковата ви сметка. |
Чести заблуди
- „Трябва да пазя номерата на картите, за да таксувам клиентите отново.“ Не. Доставчиците пазят картата и ви дават препратка (токен) за повторни плащания и абонаменти. Никога не трябва да пазите сами номера на карти.
- „Страницата „Успешно“ означава, че плащането е минало.“ Потвърждавайте плащанията с webhook на сървъра. Пренасочванията могат да бъдат пропуснати, фалшифицирани или никога да не се случат.
- „Всички платежни доставчици струват горе-долу еднакво.“ Таксите се различават според доставчика, държавата, вида карта и това дали е включено обработването на данъци. Проверете текущата ценова страница на всеки доставчик за вашата държава.
- „Със Stripe съм PCI съвместим.“ Това прави съответствието много по-просто, защото данните за картите остават при доставчика, но все пак трябва да попълните самооценяване (обикновено кратко).
- „Тестовият и реалният режим се държат напълно еднакво.“ Почти, но реалният режим изисква напълно потвърден акаунт, реални webhook крайни точки за живата среда и реални банкови данни.
- „Платежният шлюз се грижи за данъците ми.“ Само ако е търговец на записа или сте включили и настроили данъчните му функции. Проверете местните правила или се консултирайте със специалист.
Какво да поискате от AI платформата
- „Добави [Stripe] Checkout за [продукт]. Създай сесията на сървъра, като използваш секретния ключ от променлива на средата.“
- „Отбелязвай поръчките като платени само от проверен webhook и провери подписа на webhook-а.“
- „Обработвай случаи, в които webhook-ът е изпратен два пъти, без да се създават дублирани поръчки.“
- „Използвай тестовите ключове от тестовия режим и ми покажи как да тествам с тестовите карти на доставчика, включително с отказана карта.“
- „Какво се случва, ако клиентът затвори раздела след плащане?“
- „Покажи ми всяко място, където се използва платежен ключ, и потвърди, че секретният ключ никога не стига до браузъра.“
Платежни шлюзове в Mythex
Mythex не включва вградени плащания за приложенията, които строите, и няма бутон „Свържи Stripe“ с едно кликане. Създавате акаунт при избрания от вас доставчик, добавяте тестовите му ключове като тайни на проекта и поискате от агента да изгради касата от страна на сървъра. Тествайте в Preview с тестовите карти на доставчика, после публикувайте. Документацията описва процеса в Приемане на плащания със Stripe, а Webhooks обяснява стъпката за потвърждение.
За стъпка по стъпка изграждане вижте как да добавите плащания към приложението си, а за периодично таксуване — как да добавите абонаменти със Stripe.
Въпроси
Какво е платежен шлюз с прости думи?
Платежният шлюз е услугата, която сигурно приема данните за плащане на клиента от касата ви, изпраща ги към банките и картовите мрежи за одобрение и връща на приложението ви отговор — одобрено или отказано, обикновено за няколко секунди.
В какво се различава платежният шлюз от платежния процесор?
Строго погледнато, шлюзът е сигурният вход, който приема и предава данните за плащане, а процесорът премества транзакцията между банките. На практика съвременните доставчици като Stripe, PayPal и Adyen обединяват и двете, както и търговската сметка, в една услуга, затова термините често се използват взаимозаменяемо.
Трябва ли да съм PCI съвместим, за да приемам картови плащания?
Всеки бизнес, който приема карти, трябва да спазва някаква форма на стандарта за сигурност PCI DSS. Ако използвате хостната страница за плащане или вградените полета на доставчика, номерата на картите никога не минават през вашите сървъри, което намалява значително отговорността ви. Доставчикът ви ще каже кое самооценяване важи за вас.
Какво е търговец на записа (merchant of record)?
Търговецът на записа е бизнесът, който законово продава на клиента и отговаря за неща като събиране и плащане на ДДС, както и за възвръщания и оспорвания на плащания. Услуги като Paddle и Lemon Squeezy действат като търговец на записа вместо вас; при Stripe или PayPal обикновено това сте вие.
Мога ли да добавя плащания към приложение, построено с AI?
Да. AI платформата може да напише кода, който свързва приложението ви с доставчик като Stripe: създаване на сесии за плащане на сървъра, обработка на webhook събития и обновяване на поръчките. Все пак ви е нужен собствен акаунт при доставчика, а всичко трябва да тествате в тестовия му режим, преди да пуснете на живо.