Stripe в България: технически въпроси преди интеграцията

Опишете реалния бизнес сценарий

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

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

Връзки с доставчици

Изберете платежния интерфейс

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

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

Инструменти за разработчици

Разделете тестовите и реалните настройки

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

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

Свържете всеки опит с поръчка

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

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

Обработвайте известията надеждно

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

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

Проверете обхвата на OrsunPay

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

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

Източници

• Stripe Checkout
• Stripe Webhooks