Що таке міграція платіжного провайдера?

Міграція платіжного провайдера – це просто перенесення вашого платіжного шлюзу, PSP, еквайра або платіжного оркестратора до іншого PSP. Для SaaS-компаній міграція зазвичай передбачає переключення інтеграцій, логіки маршрутизації, даних регулярних платежів і токенів за умови безперебійної роботи процесу оформлення замовлення. Токенізація – це процедура, під час якої PAN обмінюються на токени, що призводить до того, що системи обробляють токени та, можливо, змінюють рівні ризику PCI.

Зміна платіжних провайдерів може вплинути на різні аспекти бізнесу та операційної діяльності. Ключові характеристики охоплюють конкретні рівні показників авторизації, різноманітні структури комісій за обробку платежів, змінений моніторинг шахрайства, географічну доступність та аспекти взаємодії з користувачами, що залежать від показників успішності транзакцій.

Щодо SaaS-бізнесу, це, як очікується, буде пов'язано з різними наслідками:

•       Збільшення показників авторизації на 2-4%.
•       Рівень чарджбеків має вимірний показник.
•       Вартість транзакції фіксується на нижчому конкретному показнику.
•       Менше звернень до служби підтримки.
•       Захист конфіденційних даних може включати токени.

Процес міграції платежів включає різні компоненти, а розуміння пов'язаних ризиків стосується операційних або процедурних міркувань.

•       Аналіз досліджує фактори перебоїв, простоїв та збоїв транзакцій, а також їхнє значення для доходу та довіри клієнтів.
•       Різні провайдери пропонують низку функцій передачі токенів; деякі з них не включають можливості імпорту чи експорту.
•       Зіставлення даних, у контексті переміщення конфіденційних клієнтських записів та записів транзакцій, може мати відмінності.
•       Підтримка обсягу PCI DSS та рівня відповідності протягом усього процесу міграції.
•       Після зміни було відзначено тимчасове зниження показників авторизації.
•       Збої, що викликають відгуки клієнтів, впливають на досвід користувачів.
•       Паритет вебхуків, повторні спроби та повернення коштів мають належним чином працювати в різних системах.
•       Безперервність періодичного виставлення рахунків має бути ретельно спланована, щоб не переривати роботу підписників.

Спочатку детально визначте всі компоненти вашої платіжної системи, потоки, комісії, договори та способи оплати. Вам потрібно перевірити ваш інвентар токенів, залежності регулярних платежів, налаштування протидії шахрайству та вимоги до звітів, щоб перелічити всі точки інтеграції та їхній вплив. Вам також необхідно переконатися, що перехід спланований з урахуванням ваших варіантів розгортання та відкату, а також показників успішності. Нарешті, підготуйте свою команду до переходу, протестувавши в пісочниці з вашим новим постачальником і провівши “м'які запуски”, щоб зменшити збої, коли відбудеться остаточна міграція ​‍​‌‍​‍‌.

Добре виконана міграція платіжного провайдера передбачає низку дій: аудит, вибір, впровадження, міграція та виведення з експлуатації саме в такому порядку.

1.   Проаналізуйте вашу поточну інфраструктуру, рівні продуктивності та ваші бізнес-вимоги.
2.   Прийміть рішення щодо вибору провайдерів.
3.   Вирішіть технічні питання. Переконайтеся, що технічна сторона зміни вашої системи забезпечена.
4.   Перенесіть дані та токени. Передайте вміст до вашої нової системи.
5.   Виконайте тестування та паралельні живі транзакції. Виявляйте помилки під час ретельного тестування та запустіть обидві системи, щоб ознайомитися з новою.
6.   Процес передбачає поступове вимкнення старої системи, а потім її виведення з експлуатації. Ви можете вивести стару систему з експлуатації повністю або взагалі цього не робити, але вивести її частинами.

Вибір провайдерів на основі факторів, що впливають на їхню продуктивність та адаптивність до майбутніх змін, є надзвичайно важливим. Критерії повинні включати 

• швидкість авторизації, 
• діапазон оброблюваних платежів, 
• охоплені регіони, 
• переносимість токенів, 
• інструменти для боротьби з шахрайством, 
• детальна звітність, 
• гарантована безвідмовна робота/SLA, 
• інструменти розробника, тощо.

Залиште існуючий шлюз працювати як резервний варіант та налаштуйте моніторинг ключових показників у реальному часі. Відстежуйте їх постійно, щоб виявляти проблеми на ранній стадії:

• Показники авторизації та затримка.
• Спостереження щодо кодів помилок та робочих станів вебхуків.
• Обсяги повернень коштів.
• Запити до служби підтримки клієнтів.

Переконайтеся, що ваш поточний payment gateway залишається повністю активним та функціональним під час фази інтеграції та тестування нової системи. Потім перенаправляйте відносно невеликий обсяг трафіку до нової системи, використовуючи «канарейкову» маршрутизацію кожної транзакції для тестування до повного переключення. Стратегія «живих» систем часто пов'язана зі зменшенням перебоїв, що може полегшити живу міграцію без необхідності планового простою.