Уебкуки
Уебкуките предоставят известия в реално време, задвижвани от събития, за критични актуализации на жизнения цикъл на плащанията. Уебкуките на Cardflo позволяват на вашите системи да реагират незабавно на статуси на плащания, спорове и други ключови събития.
Автоматизирайте работните процеси и поддържайте синхронизация между вашата платформа и Cardflo без постоянно допитване.
- Категория
- Разработчик
- Възможности
- 10
- Налично на
- Всички планове
Общ преглед
Уебкуките функционират като асинхронни HTTP обратни извиквания, които улесняват комуникацията в реално време между платежен шлюз и търговски сървър.
За разлика от традиционните методи за допитване, при които сървърът прави повтарящи се заявки за проверка на актуализации на статуса, уебкуките изпращат данни до предварително дефиниран URL адрес в момента, в който възникне конкретно събитие в жизнения цикъл на плащането.
Този механизъм е от решаващо значение за управлението на несинхронни събития като резултати от 3-D Secure удостоверяване, асинхронни завършвания на алтернативни методи за плащане (APM) или получаване на възстановяване на сума.
В рамките на платежния стек, уебкуките действат като свързваща тъкан между приобретателя или PSP и вътрешната система за управление на поръчки (OMS) или платформата за управление на приходите на търговеца.
Те гарантират, че последващата логика, като заключване на инвентара или цифрово право, остава точна, без да въвежда латентност или ненужни API разходи.
Правилното изпълнение изисква надеждно обработване на HTTP кодове за състояние и идемпотентност за управление на потенциални повторни опити от изпращащия сървър, като се гарантира, че всяко събитие се обработва веднъж и само веднъж.
Как работи
Дефиниране на крайна точка и събития
Търговецът посочва целеви URL адрес в своята среда за получаване на POST заявки. Те избират конкретни тригери за събития от жизнения цикъл на плащането, като успешно оторизиране, иницииране на възстановяване или създаване на спор.
Това гарантира, че тяхната система обработва само подходящи пакети данни, намалявайки ненужното натоварване на сървъра и поддържайки точките за интеграция фокусирани и управляеми.
Тригер на събитие и полезен товар
Когато настъпи промяна в статуса, като например клиент, завършващ SCA предизвикателство, системата генерира JSON полезен товар. Този полезен товар съдържа структурирани данни, включително ID на транзакцията, ID на търговеца (MID), сума и конкретен тип събитие.
След това шлюзът се опитва да достави тези данни до регистрираната крайна точка.
Сигурност и проверка на подписа
За да се предотврати неоторизирано инжектиране на данни, полезният товар обикновено се подписва със секретен ключ. Сървърът на търговеца възстановява подписа, използвайки необработеното тяло на заявката, и го сравнява със заглавката.
Тази проверка гарантира, че данните произхождат от доверения източник и не са били манипулирани по време на преноса.
Потвърждаване и обработка
Сървърът на търговеца трябва незабавно да върне код за състояние 200 OK, за да потвърди получаването. След това се изпълнява вътрешна логика, като актуализиране на запис в база данни или задействане на автоматичен имейл.
Ако сървърът е офлайн или върне грешка, системата за доставка следва програмирана схема за повторен опит, за да осигури последователност на данните.
Защо е важно
Оперативна ефективност и автоматизация
Разчитането на ръчни проверки на статуса или периодично допитване до API въвежда латентност, която може да влоши потребителското изживяване и да забави изпълнението. Уебкуките автоматизират прехода между оторизация на плащане и доставка на услуга.
Чрез получаване на незабавно известие за успешно прихващане или сетълмент, бизнесите могат да автоматизират работните процеси за доставка, генерирането на лицензи или предоставянето на акаунти, намалявайки необходимостта от ръчна намеса и минимизирайки риска от човешка грешка при управлението на транзакции.
Намаляване на риска и споровете
Известията за заявки за извличане или възстановяване на суми позволяват на търговците да отговарят в рамките на определените от схемата времеви рамки. Незабавните сигнали относно меки откази или SCA грешки позволяват проактивно ангажиране на клиентите.
Чрез реагиране на тези събития, когато се случват, търговците могат да подобрят своите успешни проценти на представяне и да намалят оперативните разходи, свързани с необработени неуспешни плащания или спорове, които иначе биха останали незабелязани до периодичен ръчен одит.
Приложения
Жизнен цикъл на абонамент и SaaS
Когато повтарящо се плащане е неуспешно или карта изтече, уебкука задейства автоматична последователност за събиране на дългове или спира достъпа на потребителя, поддържайки точни цикли на таксуване без ръчен надзор.
Изпълнение на поръчки за електронна търговия
Онлайн търговец използва уебкуки, за да освободи стоки за доставка само след получаване на събитие „capture. succeeded“, предотвратявайки изпращането на артикули, за които плащането не е било напълно оторизирано.
Координация на изплащанията на пазара
Платформите, получаващи средства, могат да задействат изплащания към под-търговци само след като първоначалната клиентска транзакция достигне уреден статус, осигурявайки ликвидност и намалявайки риска от отменяне на изплащания.
Финализиране на алтернативен метод за плащане
За методи като банкови преводи или местни схеми, които не предоставят незабавно потвърждение, уебкуките уведомяват системата часове или дни по-късно, когато средствата бъдат потвърдени.
В числа
Типично за индустрията забавяне между записването на събитие в платформата за придобиване и изпращането на уебкуката до крайната точка на търговеца.
Стандартен показател за надеждност за услугите за уебкуки, когато включва автоматична логика за повторен опит и излишна инфраструктура за доставка.
Наблюдение на индустрията за подобряване на скоростта на изпълнение при преминаване от периодична пакетна обработка към архитектури на уебкуки, задвижвани от събития.
Свързани термини
Talk to our team about a live rollout on your acquiring stack.
Какво получавате с Уебкуки
- Асинхронна доставка на промени в статуса на транзакцията за подобрена производителност на системата.
- Поддръжка за множество типове събития, включително оторизация, прихващане, възстановяване и спор.
- 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 и че съдържанието не е било променяно, осигурявайки сигурността на вашия процес на изпълнение на поръчки.
Как уебкуките обработват изискванията за 3-D Secure и SCA?
По време на 3-DS поток, транзакцията често преминава в състояние на изчакване, докато потребителят бъде пренасочен към своя издател за удостоверяване. Окончателният резултат от това удостоверяване може да не е известен веднага.
Уебкуките се използват за уведомяване на вашата система, когато 3-DS предизвикателството е завършено и транзакцията впоследствие е оторизирана или отказана.
Това предотвратява блокирането на вашата каса и позволява на вашия бекенд да реагира на окончателното състояние на оторизация, след като клиентът се върне от страницата за пренасочване на банката.
Могат ли уебкуките да се използват за управление на времевите рамки за възстановяване на суми и спорове?
Да, уебкуките са основен инструмент за управление на жизнения цикъл на споровете. Когато картодържател инициира заявка за извличане или официално възстановяване на сума с техния издател, шлюзът получава това известие чрез картовите схеми.
След това се изпраща уебкука до вашата система, указваща кода на причината, сумата и крайния срок за отговор.
Използвайки тези данни в реално време, можете да автоматизирате спирането на съответния акаунт и да уведомите вашия екип за риск да започне процеса на представяне незабавно, увеличавайки вероятността за успешно отменяне на спора.
Какво се случва, ако нашият сървър е изключен по време на критично събитие на уебкука?
Надеждните системи за уебкуки работят с политика за повторен опит. Ако вашата крайна точка върне грешка 4xx или 5xx, или не успее да отговори в рамките на няколко секунди, шлюзът ще постави съобщението на опашка за повторна доставка.
Тези повторни опити обикновено следват експоненциален модел на отстъпване, опитвайки се да доставят няколко пъти в продължение на минути или часове.
За да осигурите дългосрочна последователност, трябва също така да имате резервен механизъм, като например ежедневен скрипт за съгласуване, който извиква API, за да намери пропуснати промени в статуса, осигурявайки предпазна мрежа за продължителни прекъсвания.
Свързани функции.
Готови ли сте за скорост?
Разкажете ни за вашия бизнес. Ние ще ви свържем с правилните банки акцептанти и правилния маршрут, обикновено в рамките на една седмица.