0893 557 642 Искам оферта
solution_04 · Payment layer

Интеграция на платежни системи и виртуални POS

Клиентът стига до плащане. Въвежда картата. Натиска „Плати“ - и нищо не се случва. Или още по-лошо: парите тръгват, поръчката не се записва. В 90% от случаите това не е проблем на банката. Това е проблем на интеграцията. Ние я изграждаме така, че плащането да е естествено продължение на продажбата, а не нейна спирачка.

Поискай оферта Заяви консултация
tx.monitor / live streaming
  • tx_8821 125,75 € CAPTURED
  • tx_8822 756,55 € 3DS_CHAL
  • tx_8823 30,63 € CAPTURED
  • tx_8824 459,62 € FAILED
  • tx_8825 65,95 € PENDING
avg
571 ms
success
99.4%
3DS pass
96.1%
Последният клик

Плащането е моментът, в който всичко може да се счупи

Целият ви маркетинг, цялата ви рекламна стратегия, целият ви продуктов опит - всичко се събира в един единствен бутон. Ако той не работи безупречно, всичко преди него губи смисъл.

  • Клиент се оплаква, че плащането не работи
  • Банката връща интеграцията за корекции
  • Натрупват се отказани пратки от наложен платеж
  • Конверсията пада след добавяне на нов метод
secure.checkout / v3.psd2
TLS 1.3
4242 •••• •••• 1337
holder
I. Petrov
exp
09/28
cvc
•••
amount
756,55 €
Плати
response_time · 412 ms200 OK · auth ok
error.registry

5 типични начина, по които плащането ви губи пари

Повечето търговци разбират, че имат проблем едва когато е твърде късно. Ето как изглеждат най-честите технически пропуски - преди клиентът да напише първото оплакване.

ERR_42

Транзакцията минава, поръчката - не

Webhook-ът от банката не е свързан с order статуса. Парите тръгват, поръчката увисва между „в кошницата“ и „платена“.

ERR_19

Двойни заявки и двойни тегления

Липсва идемпотентен ключ. Един бутон „Плати“, натиснат два пъти, генерира две оторизации към една и съща карта.

ERR_07

Прекъснато плащане без статус

Клиентът затваря таба по време на 3DS. Поръчката стои в „pending“ до безкрайност - нито отказана, нито потвърдена.

ERR_33

Грешна конфигурация - банков ban

Невалидни обратни URL-и, лош MID, липсваща обработка на 3DS. Банката връща интеграцията за корекции.

ERR_88

30% наложени плащания

Магазинът разчита основно на cash on delivery. Резултатът: откази на пратки, замразен оборотен капитал, нула продажби извън България.

Не добавяме „бутон Плати“

Изграждаме цялата логика зад него: state machine, retry, идемпотентност, обратни webhook-и, reconciliation и пълно покритие на 3DS сценариите.

integration.process

Как протича интеграцията на виртуален POS

Шест етапа. Никакви предположения. Всеки сценарий - тестван, преди да види първата истинска карта.

step / 01

Анализ на реалния бизнес модел

B2B, нискомаржови продукти, международни плащания - всеки случай иска различна архитектура.

step / 02

Избор на правилния оператор

BORICA, Stripe, Paysera, PayPal, директен виртуален POS - критерият е „подходящ за вас“, не „популярен“.

step / 03

API интеграция с криптиране

Защитени ключове, обработка на отговорите, retry логика, идемпотентни заявки, чисти state machines.

step / 04

3D Secure & защита от измами

PSD2 / SCA съвместимост, рисково-базирана автентикация, без излишно триене за добрите клиенти.

step / 05

Тестване в sandbox

Успешен · неуспешен · прекъснат · повторен · timeout · refund · partial capture - всеки сценарий минава ръчно.

step / 06

Активиране и мониторинг

Първите реални транзакции се следят на живо. Alarms за грешки > праг. SLA за реакция.

operators

Изборът на оператор не е въпрос на популярност

BORICA · Stripe · Paysera · PayPal · директен виртуален POS - всеки има своите силни страни. Избираме този, който пасва на маржа, географията и потребителския ви профил.

EU / SCA / PSD2 ready
BORICA
BORICA
Български виртуален POS
card
Stripe
Stripe
International · Apple/Google Pay
card · wallet
Paysera
Paysera
EU + локални методи
card · bank
PayPal
PayPal
Trust-based checkout
wallet
Direct vPOS
Direct vPOS
DSK · UCB · Fibank · Postbank
card
Revolut Pay
Revolut Pay
Open Banking · A2A
bank
handshake.sequence

Три точки. Една успешна транзакция.

Разминаването между която и да е от тях създава „висящи“ поръчки. Правилната интеграция държи трите в синхрон - във всяко състояние на плащането.

merchant.api

Магазин

Изпраща заявка, поддържа state machine, реагира на webhook-и за всеки изход.

psp.layer

Gateway / vPOS

Криптира, верифицира 3DS, маршрутизира към издателя, връща ясни кодове.

issuer.bank

Банка / Issuer

Авторизира, capture-ва, изпраща settlement - със същия order ID през целия цикъл.

tx.timeline · 756,55 €total 1.82s · 3ds pass
init
auth_req
3ds_chal
3ds_ok
capture
webhook
security.layer

Сигурност и 3D Secure

Картовите данни никога не минават през вашия сървър. Всяка стъпка от плащането е криптирана, подписана и логнатa - съобразно PSD2, SCA и PCI DSS изискванията на европейските регулатори.

  • PCI DSSscope minimisation чрез tokenization
  • PSD2 / SCAStrong Customer Authentication по подразбиране
  • 3DS 2.xfrictionless flow за нискорискови транзакции
  • GDPRникакви карти в логове, маскирани PAN-ове
Криптиране в транзит и в покой
tls 1.3 · aes-256

Всеки байт между браузъра, магазина, gateway-а и банката пътува през TLS 1.3 с актуални cipher suites. Картови данни не се записват - само еднопосочни токени.

<span class="text-white/40">POST</span> /charge <span class="text-[hsl(var(--neon))]">→ tok_3a91...f7d2</span><br><span class="text-white/40">PAN</span> 4242 41•• •••• 1337 <span class="text-amber-300">[masked]</span><br><span class="text-white/40">cipher</span> TLS_AES_256_GCM_SHA384
Ключове и ротация
hsm / vault

Production ключовете живеят в secret manager (Vault / KMS), не в кода и не в .env. Разделение на live / test среди, ротация по график, отделни webhook signing secrets за всяка интеграция.

public_key
pk_live_••
secret_key
vault://
wh_secret
whsec_••
3D Secure challenge · live
3ds.v2.2
  1. risk_scorelow · frictionless
  2. device_fingerprintmatch · trusted
  3. issuer_challengeOTP · passed
  4. fraud_rules0 trigger
auth.code · 200_OKliability shift · issuer
platforms

Платформата не е решаваща. Конфигурацията - е.

WooCommerce, OpenCart, Shopify, Magento или custom build - стабилната интеграция зависи от това как е настроена връзката между магазина, банката и логиката за обработка на поръчките.

WooCommerce
Plugin + custom hooks
OpenCart
Native module
Shopify
App + Checkout extensibility
Magento / Adobe Commerce
Custom payment method
Custom build
Direct API integration
when.required

Кога интеграцията на виртуален POS става критична

Не „още един метод на плащане“. Това са сигналите, че сегашната ви схема вече ви струва пари - всеки ден.

  • 01Разчитате прекалено много на наложен платеж
  • 02Искате да продавате извън България
  • 03Имате проблеми с отказани или прекъснати транзакции
  • 04Банката връща интеграцията ви за корекции
  • 05Усещате, че губите поръчки на етап „плащане“
outcomes / measured

Какво реално се променя след правилна интеграция

+ растеж
Конверсия в checkout
- драстично
Отказани пратки
0
„Висящи“ поръчки
0
Разминавания банка ↔ магазин
faq

Често задавани въпроси

Договори, прекъснати плащания, диагностика на сегашна интеграция, срокове за внедряване - кратки и конкретни отговори.

Не. Ако нямате договор, ще ви насочим кой вариант е най-подходящ според вашия бизнес модел и ще съдействаме с техническите изисквания към банката или оператора - от попълването на документи до техническите спецификации.

Подозирате, че губите поръчки на етап плащане?

Правим анализ на текущата ви интеграция и ви показваме къде точно изтичат клиентите - кой webhook не пристига, кой код за грешка не се обработва, кой timeout убива транзакцията.

Заяви консултация Виж други решения