Уебкуки
Уебкукове за обработка на плащания, позволяващи HTTP известия в реално време за синхронизация през над 50 партньори-придобиващи, автоматизиране на изпълнението и незабавно проследяване на събития за обратно плащане или активност на MID.
- Категория
- Разработчик
- Възможности
- 6
- Налично на
- Всички планове
Уебкуките предоставят известия в реално време, задвижвани от събития, за критични актуализации на жизнения цикъл на плащанията. Уебкуките на Cardflo позволяват на вашите системи да реагират незабавно на статуси на плащания, спорове и други ключови събития.
Автоматизирайте работните процеси и поддържайте синхронизация между вашата платформа и Cardflo без постоянно допитване.
Навременните известия от уебкуки предоставят актуализации в реално време за статусите на транзакциите и активността на MID в нашата обширна мрежа от придобиващи. Този незабавен поток от данни позволява бърза автоматизация на критични бизнес процеси и незабавни отговори на събития.
Преглед на Уебкукипреглед
Уебкуките функционират като асинхронни HTTP обратни извиквания, които улесняват комуникацията в реално време между платежен шлюз и търговски сървър.
За разлика от традиционните методи за допитване, при които сървърът прави повтарящи се заявки за проверка на актуализации на статуса, уебкуките изпращат данни до предварително дефиниран URL адрес в момента, в който възникне конкретно събитие в жизнения цикъл на плащането.
Този механизъм е от решаващо значение за управлението на несинхронни събития като резултати от 3D Secure удостоверяване, асинхронни завършвания на алтернативни методи за плащане (APM) или получаване на възстановяване на сума.
В рамките на платежния стек, уебкуките действат като свързваща тъкан между приобретателя или PSP и вътрешната система за управление на поръчки (OMS) или платформата за управление на приходите на търговеца. Те гарантират, че последващата логика, като заключване на инвентара или цифрово право, остава точна, без да въвежда латентност или ненужни API разходи.
Правилното изпълнение изисква надеждно обработване на HTTP кодове за състояние и идемпотентност за управление на потенциални повторни опити от изпращащия сървър, като се гарантира, че всяко събитие се обработва веднъж и само веднъж.
Как работи Уебкукиработи
Дефиниране на крайна точка и събития
Търговецът посочва целеви URL адрес в своята среда за получаване на POST заявки. Те избират конкретни тригери за събития от жизнения цикъл на плащането, като успешно оторизиране, иницииране на възстановяване или създаване на спор. Това гарантира, че тяхната система обработва само подходящи пакети данни, намалявайки ненужното натоварване на сървъра и поддържайки точките за интеграция фокусирани и управляеми.
Тригер на събитие и полезен товар
Когато настъпи промяна в статуса, като например клиент, завършващ SCA предизвикателство, системата генерира JSON полезен товар. Този полезен товар съдържа структурирани данни, включително ID на транзакцията, ID на търговеца (MID), сума и конкретен тип събитие. След това шлюзът се опитва да достави тези данни до регистрираната крайна точка.
Сигурност и проверка на подписа
За да се предотврати неоторизирано инжектиране на данни, полезният товар обикновено се подписва със секретен ключ. Сървърът на търговеца възстановява подписа, използвайки необработеното тяло на заявката, и го сравнява със заглавката. Тази проверка гарантира, че данните произхождат от доверения източник и не са били манипулирани по време на преноса.
Защо Уебкуки е от значение
Оперативна ефективност и автоматизация
Разчитането на ръчни проверки на статуса или периодично допитване до API въвежда латентност, която може да влоши потребителското изживяване и да забави изпълнението. Уебкуките автоматизират прехода между оторизация на плащане и доставка на услуга. Чрез получаване на незабавно известие за успешно прихващане или сетълмент, бизнесите могат да автоматизират работните процеси за доставка, генерирането на лицензи или предоставянето на акаунти, намалявайки необходимостта от ръчна намеса и минимизирайки риска от човешка грешка при управлението на транзакции.
Намаляване на риска и споровете
Известията за заявки за извличане или възстановяване на суми позволяват на търговците да отговарят в рамките на определените от схемата времеви рамки. Незабавните сигнали относно меки откази или SCA грешки позволяват проактивно ангажиране на клиентите. Чрез реагиране на тези събития, когато се случват, търговците могат да подобрят своите успешни проценти на представяне и да намалят оперативните разходи, свързани с необработени неуспешни плащания или спорове, които иначе биха останали незабелязани до периодичен ръчен одит.
Регулаторни бележки за Уебкуки
Data privacy and payload security
Transmitting transaction data across open networks leaves no slack against data protection regulations like GDPR and PCI DSS. Notification payloads must travel exclusively over TLS-encrypted connections to prevent interception by unauthorised third parties during transit.
Cardflo enforces HTTPS URLs for all registered listener endpoints, rejecting any unencrypted destinations.
Furthermore, structured notifications exclude sensitive cardholder data, such as full primary account numbers or security codes. The gateway transmits tokenised identifiers and masked references, ensuring that the receiving server does not inadvertently bring its hosting environment into the highest tiers of PCI DSS compliance scope.
PSD2 and asynchronous strong customer authentication
Under Payment Services Directive 2, Strong Customer Authentication introduces asynchronous flows into the standard checkout process. When a transaction requires an out-of-band authentication step, such as a biometric check in a banking application, the initial request cannot return an immediate definitive success or failure status.
Event listeners are essential for capturing the final outcome of these mandated security challenges. Once the issuing bank confirms the authentication result through the acquirer partner network, the orchestration layer fires an asynchronous event.
This notification informs the merchant system that the security requirement is satisfied and the capture can proceed.
Случаи на употреба на Уебкукислучаи на употреба
Жизнен цикъл на абонамент и SaaS
Когато повтарящо се плащане е неуспешно или карта изтече, уебкука задейства автоматична последователност за събиране на дългове или спира достъпа на потребителя, поддържайки точни цикли на таксуване без ръчен надзор.
Изпълнение на поръчки за електронна търговия
Онлайн търговец използва уебкуки, за да освободи стоки за доставка само след получаване на събитие „capture.succeeded“, предотвратявайки изпращането на артикули, за които плащането не е било напълно оторизирано.
Координация на изплащанията на пазара
Платформите, получаващи средства, могат да задействат изплащания към под-търговци само след като първоначалната клиентска транзакция достигне уреден статус, осигурявайки ликвидност и намалявайки риска от отменяне на изплащания.
Финализиране на алтернативен метод за плащане
За методи като банкови преводи или местни схеми, които не предоставят незабавно потвърждение, уебкуките уведомяват системата часове или дни по-късно, когато средствата бъдат потвърдени.
Уебкуки в цифри
Типично за индустрията забавяне между записването на събитие в платформата за придобиване и изпращането на уебкуката до крайната точка на търговеца.
Стандартен показател за надеждност за услугите за уебкуки, когато включва автоматична логика за повторен опит и излишна инфраструктура за доставка.
Наблюдение на индустрията за подобряване на скоростта на изпълнение при преминаване от периодична пакетна обработка към архитектури на уебкуки, задвижвани от събития.
Методология: тези цифри са илюстративни диапазони, извлечени от публикувани индустриални данни и наблюдавани търговски кохорти, а не гаранции. Действителните резултати зависят от вашия рисков профил, комбинация от карти, география и настройки за придобиване, и се потвърждават само във вашите собствени ценови условия и условия за одобрение.
Свързани термини
Говорете с нашия екип за жива интеграция на rails на нашите партньори по придобиване.
Какво получавате с Уебкуки
- Асинхронна доставка на промени в статуса на транзакцията за подобрена производителност на системата.
- Поддръжка за множество типове събития, включително оторизация, прихващане, възстановяване и спор.
- HMAC-SHA256 заглавки за подпис за надеждна проверка на целостта на входящите данни.
- Автоматична логика за повторен опит след експоненциални графици за отстъпване при неуспешни опити за доставка.
- Версиониране на полезния товар за осигуряване на съвместимост при развитието на структурите на данните с течение на времето.
- Възможности за IP whitelisting за ограничаване на входящия трафик до известни източници на шлюзове.
A short scoping call, then a written plan for your MIDs.
Въпроси относно Уебкуки
Как трябва нашият сървър да обработва дублирани известия от уебкуки?
Стандартна практика е платежните шлюзове да използват механизъм за повторен опит, ако крайната точка не върне 200 OK отговор в рамките на определен период от време. Следователно, вашият сървър може да получи едно и също събитие няколко пъти.
За да поддържате целостта на данните, трябва да приложите логика за идемпотентност. Това обикновено включва проследяване на уникалния идентификатор на събитието, предоставен в полезния товар, и проверка дали вече е бил обработен, преди да се изпълни каквато и да е бизнес логика.
Ако идентификаторът съществува във вашата база данни, вашият сървър трябва да игнорира събитието, но все пак да върне 200 OK, за да спре по-нататъшни повторни опити.
Каква е разликата между допитване до API и използване на уебкуки?
Допитването изисква вашият сървър да инициира чести заявки към шлюза, за да проверява за актуализации на статуса, което е неефективно и може да доведе до проблеми с ограничаване на скоростта или забавена информация.
Уебкуките обръщат този поток, като шлюзът инициира заявка към вашия сървър само когато възникне събитие.
Този „push“ модел е по-ефективен, намалява натоварването на сървъра и гарантира, че статусите се актуализират почти в реално време във вашата инфраструктура, което е особено важно за чувствителни към времето действия като доставка на цифрово съдържание или предотвратяване на измами.
Защо е необходима проверка на подписа за всяка заявка за уебкука?
Тъй като крайните точки на уебкуките са публични URL адреси, те са теоретично достъпни от всяко лице в интернет. Без проверка, нападател може да изпрати фалшив JSON полезен товар до вашия сървър, като невярно посочи, че плащане с висока стойност е било успешно.
Чрез използване на споделен секрет за проверка на HMAC подписа, предоставен в заглавката на заявката, вашата система може математически да докаже, че съобщението е изпратено от вашия PSP и че съдържанието не е било променяно, осигурявайки сигурността на вашия процес на изпълнение на поръчки.
Как уебкуките обработват изискванията за 3D Secure и SCA?
По време на 3-DS поток, транзакцията често преминава в състояние на изчакване, докато потребителят бъде пренасочен към своя издател за удостоверяване. Окончателният резултат от това удостоверяване може да не е известен веднага.
Уебкуките се използват за уведомяване на вашата система, когато 3-DS предизвикателството е завършено и транзакцията впоследствие е оторизирана или отказана.
Това предотвратява блокирането на вашата каса и позволява на вашия бекенд да реагира на окончателното състояние на оторизация, след като клиентът се върне от страницата за пренасочване на банката.
Свързани функции.
Свързани ръководства.
Вижте как Cardflo се сравнява.
Готови ли сте да подобрите настройките за плащанията си?
Разкажете ни за вашия бизнес. Ние ще ви свържем с правилните банки акцептанти и правилния маршрут, обикновено в рамките на една седмица.