Пълен набор от платежни услуги

Бърза API интеграция

Плъгин за минути или чисто REST API за един ден, според това как е построен сайтът ти.

Ако си на WooCommerce, PrestaShop или Magento, инсталираш плъгин и въвеждаш ключовете. Ако имаш собствена платформа, работиш срещу REST API с предвидими отговори и подробна документация.

Тестовата среда е достъпна веднага след одобрението, така че интеграцията може да върви паралелно с обработката на документите.

Разработчик пише код на светло работно място до голям прозорец

Какво получаваш

REST API

Версионирани, стабилни ендпойнти.

Webhooks

Подписани известия в реално време с повторни опити.

SDK

PHP, Node.js и Python.

Готови плъгини

WooCommerce, PrestaShop, Magento, OpenCart.

Idempotency ключове

Защита срещу двойно таксуване при повторна заявка.

Sandbox

Пълна тестова среда с тестови карти.

Как работи

Ключове

Получаваш тестови ключове веднага след одобрението.

Интеграция

Плъгин или API, според платформата ти.

Тест

Проверяваш плащане, възстановяване и webhook.

Продукция

Сменяш ключовете и пускаш на живо.

Плъгин за минути или API за един ден

Изборът зависи от това как е построен сайтът ти, не от това колко добър е разработчикът ти.

Ако работиш на WooCommerce, PrestaShop или OpenCart, плъгинът е правилният отговор. Инсталираш, слагаш ключовете от панела, избираш кои методи да се показват и си готов. Плъгинът поддържа връщания направо от администрацията на магазина, така че не влизаш в два панела за една операция.

Ако имаш собствено приложение, нестандартна количка или продаваш през няколко канала наведнъж, REST API-то дава контрола, който ти трябва. Заявките са JSON, отговорите са JSON, грешките имат стабилни кодове, а не свободен текст, който се променя между версиите.

И в двата случая има тестова среда с карти за всеки сценарий: успех, отказ поради липса на средства, изтекла карта, провален 3-D Secure, чарджбек. Тестваш целия поток, преди да си пуснал един реален лев.

Три неща, които спестяват дни отстраняване на проблеми

Идемпотентност. Всяка заявка за плащане носи ключ, който ти генерираш. Ако връзката прекъсне и клиентът натисне пак, същият ключ връща същия резултат вместо да създаде второ плащане. Това е най-честата причина за двойно таксуване при доставчици, които го нямат.

Webhook вместо запитване на цикъл. Когато състоянието на плащане се промени, ние ти пращаме съобщение. Не ти се налага да питаш на всеки трийсет секунди дали нещо се е случило. Всяко съобщение е подписано, така че можеш да провериш, че наистина идва от нас.

Стабилни кодове за грешки. Отказът заради липса на средства и отказът заради блокирана карта имат различни кодове и се обработват различно. Ако системата ти ги третира еднакво, губиш продажби, които са били възстановими.

Какво трябва да подготви разработчикът ти

Списъкът е кратък и се сваля от плещите преди началото, а не по средата.

HTTPS на целия сайт, не само на страницата за плащане. Място, където да пазиш нашите ключове извън кода, например променливи на средата. Адрес за webhook, който отговаря бързо и връща 200, дори когато вътрешната обработка отнема време. Логове, в които не влизат картови данни. И решение какво прави системата, когато плащането е успешно, но твоят сървър е бил недостъпен в този момент.

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

Какво да тестваш, преди да пуснеш

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

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

Прекъснат 3-D Secure. Клиентът е пренасочен към банката и е затворил таба. Какво става с поръчката ти. Тя не трябва да остане завинаги в състояние на изчакване.

Двойно изпращане. Натисни бутона два пъти бързо. Ако получиш две плащания, идемпотентният ключ не е сложен правилно.

Webhook при недостъпен сървър. Спри своя сървър, направи плащане, пусни го пак. Съобщението трябва да дойде повторно и поръчката да се затвори сама.

Връщане, частично и пълно. Проверяваш и че сумата се приспада коректно в следващия сетълмент.

Тестовата среда има карти за всеки от тези случаи, така че целият списък се минава за час.

Какво получава разработчикът ти в първия ден

Всичко е достъпно веднага след откриването на акаунта, без чакане и без обаждания.

  • Ключове за тестова и за реална среда
  • Документация с примери на curl, PHP и JavaScript
  • Тестови карти за всеки сценарий, включително отказ
  • Готови плъгини за WooCommerce, PrestaShop и OpenCart
  • Инструмент за проверка на webhook съобщения
  • Директен контакт с човек, който познава интеграцията

Въпроси по темата

Колко наистина отнема интеграцията?

С плъгин, около час. Със собствено API, обикновено един работен ден за стандартен поток на плащане. Ако имаш абонаменти, запазени карти и връщания, отдели два до три дни за спокойно тестване.

Има ли ограничение на заявките?

Има разумен лимит, който при нормална търговия не се усеща. Ако очакваш пик, например при кампания или при старт на продажби на билети, кажи предварително и го вдигаме.

Как проверявам, че webhook съобщението е от вас?

Всяко съобщение носи подпис с общата тайна от панела. Разработчикът пресмята подписа и го сравнява. Примери има в документацията за трите езика.

Какво става при промяна във вашето API?

Версиите се пазят. Промени, които чупят съвместимост, излизат под нова версия, а старата продължава да работи. Не се събуждаш с недействащ checkout.

Можете ли да направите интеграцията вместо нас?

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

Поддържате ли SDK за конкретен език?

Документацията е с примери на curl, PHP и JavaScript, които покриват повечето случаи. За Python, .NET или Java даваме готови примери при поискване, вместо да поддържаме библиотеки, които остаряват по-бързо от самото API.

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

Двете среди имат отделни ключове и отделни панели. Тестова транзакция не може да попадне в реалния ти отчет дори при объркан ключ, защото ключът определя средата.

Готов ли си да приемаш плащания?

Изпрати запитване и ще получиш конкретна оферта с изчислени такси за твоя бизнес, обикновено в рамките на един работен ден.