Колега купує квиток на конференцію за допомогою корпоративної віртуальної картки. Під час оформлення платежу з’являється екран 3D Secure, але запит на підтвердження надходить на телефон фінансового менеджера, який наразі недоступний.
У цей момент пересилання одноразового коду в груповому чаті може здатися зручним рішенням.
Але це може послабити контроль, який саме й має забезпечувати 3D Secure.
Справжня проблема полягає не просто в тому, що платіж не пройшов. Команда не визначила чітко три речі:
- Хто має право здійснювати покупку
- Хто затверджує витрати
- Хто може пройти автентифікацію емітента
У цьому посібнику пояснюється, як командам підготуватися до 3D Secure до початку оформлення платежу, що робити, якщо запит на підтвердження надходить не тій людині, і як відновити процес без створення дубльованих замовлень або передачі конфіденційних даних автентифікації.
Зрозумійте, що саме запитує перевірка 3D Secure
3D Secure є частиною процесу автентифікації картки між продавцем і емітентом.
Залежно від налаштувань перевірка може вимагати:
- Одноразовий код
- Підтвердження в застосунку
- Біометричні дані
- Інший метод автентифікації, який підтримує емітент
Мета полягає в тому, щоб перевірити, чи має особа, яка завершує платіж, право використовувати картку.
Це окремо від внутрішнього погодження витрат у компанії.
Менеджер уже міг погодити придбання квитка на конференцію вартістю €400, але емітент усе одно може вимагати дійсне підтвердження автентифікації, перш ніж платіж карткою буде проведено.
Перед підтвердженням будь-якого запиту перевірте:
- Продавця
- Суму
- Валюту
- Час
- Чи була покупка очікуваною
Якщо в запиті на підтвердження зазначено €4 000, хоча покупець очікував €400, зупиніться.
Якщо ніхто наразі не здійснює покупку, вважайте запит підозрілим і перевірте його через офіційну активність облікового запису.
Три ролі під час корпоративної покупки
У багатьох командах одна людина не контролює всі етапи.
Зазвичай існує три ролі:
Ініціатор
Працівник, якому потрібен продукт або послуга.
Особа, яка погоджує витрати
Людина, яка вирішує, чи повинна компанія здійснити оплату.
Відповідальний за автентифікацію
Людина, яка має доступ до методу 3D Secure, що підтримується емітентом.
Іноді один працівник виконує всі три ролі. В інших випадках вони можуть працювати в різних відділах або навіть у різних країнах.
Важливо знати, хто відповідає за кожен етап, ще до введення даних картки під час оформлення платежу.
Політики на кшталт «фінансовий відділ погоджує платежі» недостатньо, якщо ніхто не знає, хто зможе відповісти на запит 3DS у момент фактичної покупки.
Не передавайте OTP або облікові дані для автентифікації
Командам слід уникати вирішення проблеми шляхом пересилання одноразових кодів, паролів, сеансів входу або облікових даних для автентифікації через чат.
Це послаблює відповідальність за дії та може розкрити іншу інформацію про картку або обліковий запис.
Кращий підхід:
- Покупець повідомляє уповноважену особу, відповідальну за автентифікацію, про те, що здійснюється спроба платежу
- Відповідальна особа самостійно відкриває офіційний застосунок емітента або інший метод автентифікації
- Вона перевіряє продавця, суму та валюту
- Вона підтверджує платіж лише в тому випадку, якщо запит відповідає погодженій покупці
Наприклад:
«Я перебуваю на сторінці оформлення квитка на конференцію на суму €400. Будь ласка, перевірте в застосунку емітента, чи є відповідний запит».
Це передає контекст покупки, не розкриваючи секрет автентифікації.
Підготуйте пристрій до початку оформлення платежу
Наявності дійсної картки недостатньо, якщо пристрій для автентифікації недоступний.
Перед терміновою покупкою перевірте, чи має уповноважена особа фактичний доступ до відповідного методу автентифікації.
Можливі проблеми:
- Зареєстрований телефон перебуває офлайн
- Термін дії сеансу в застосунку завершився
- Push-сповіщення вимкнені
- Зареєстрований номер належить колишньому працівнику
- Користувач більше не має доступу до необхідного облікового запису
- Метод автентифікації потребує оновлення
Якщо канал автентифікації налаштований неправильно, скористайтеся офіційною процедурою постачальника для його оновлення.
Не чекайте, поки таймер оформлення платежу вже запуститься. Деякі зміни доступу потребують перевірки та не можуть бути виконані миттєво.
Що робити, якщо запит на підтвердження надійшов не тій людині
Якщо запит 3DS надходить людині, яка недоступна, не намагайтеся багаторазово повторювати той самий платіж.
Натомість:
- Збережіть сторінку замовлення та його номер.
- Зв’яжіться з уповноваженою особою, відповідальною за автентифікацію.
- Попросіть її перевірити офіційний інтерфейс емітента.
- Якщо вона не може відповісти до завершення терміну дії запиту, дозвольте спробі завершитися.
- Перевірте, чи створив продавець замовлення та чи відображається очікувана авторизація в обліковому записі картки.
- Повторюйте платіж лише після того, як команда зрозуміє статус першої спроби.
Завершення терміну дії запиту 3DS не означає автоматично, що нічого не сталося.
Продавець усе ще міг створити замовлення, а авторизація картки все ще може існувати.
Якщо запит на підтвердження надійшов колишньому працівнику
Це не просто проблема з платежем. Це проблема контролю облікового запису.
Не просіть колишнього працівника пересилати коди після його звільнення з компанії.
Натомість:
- Видаліть застарілий доступ через офіційну процедуру постачальника
- Підтвердьте поточного уповноваженого користувача або адміністратора
- Перевірте, чи не використовують інші картки або облікові записи той самий старий контакт
- Оновіть внутрішні записи про відповідальних осіб
Для термінової покупки компанії може знадобитися використати інший затверджений спосіб оплати, поки проблема з доступом до облікового запису вирішується.
Коли запит на підтвердження схвалено, але оформлення платежу все одно не проходить
Успішне підтвердження 3DS не обов’язково означає, що продавець прийняв замовлення.
Автентифікація є лише одним етапом платіжного процесу.
Якщо відповідальна особа схвалює запит, але під час оформлення все одно з’являється помилка:
- Зафіксуйте час
- Збережіть номер замовлення продавця
- Перевірте, чи створив продавець замовлення
- Перевірте рахунок картки на наявність очікуваних або завершених операцій
- Зв’яжіться з продавцем щодо статусу замовлення
- Зв’яжіться з постачальником картки, якщо потрібно перевірити автентифікацію або статус картки
Продавець і постачальник картки можуть бачити різні частини платіжного процесу.
Уникайте повторних спроб платежу
Одна з найпоширеніших помилок після невдалої перевірки 3DS — повторне надсилання платежу знову і знову.
Це може призвести до:
- Дубльованих замовлень у продавця
- Кількох спроб авторизації
- Тимчасових блокувань коштів
- Спрацювання ризикових перевірок
- Кількох запитів на автентифікацію
Якщо протягом короткого часу надходить кілька запитів, не підтверджуйте їх усі лише для того, щоб перевірити, який із них спрацює.
Зупиніть оформлення платежу, визначте активне замовлення та порівняйте продавця, суму й час кожного запиту.
Таймер оформлення платежу та статус замовлення — це різні речі
Продавець може резервувати квиток на десять хвилин, тоді як запит 3DS має коротший термін дії.
Продавець також може створити неоплачене замовлення до завершення автентифікації.
Тому командам слід розрізняти:
- Таймер оформлення платежу
- Таймер автентифікації
- Статус замовлення у продавця
- Статус авторизації картки
Перед повторною спробою підтвердьте, що саме сталося з першим замовленням.
Це особливо важливо для квитків на конференції, бронювання подорожей, товарів з обмеженою кількістю або програмного забезпечення з ціною, що залежить від часу покупки.
Де тут Buvei
Якщо картка керується через Buvei, перевірте інструкції з автентифікації та доступні ролі облікового запису для конкретної картки та облікового запису.
У разі невдалої або неправильно спрямованої спроби автентифікації надайте службі підтримки:
- Дату й час
- Продавця
- Суму
- Валюту
- Масковані дані картки
- Повідомлення про помилку
- Чи з’явився запит на підтвердження
- Чи хтось його схвалив
Не додавайте до скриншотів актуальні OTP, повні номери карток або коди безпеки.
Окрема віртуальна картка може допомогти командам визначити, якого постачальника, проєкту або бюджету стосується транзакція, але вона не замінює автентифікацію емітента або внутрішнє погодження.
Створіть резервне покриття без спільного використання одного облікового запису
Один фінансовий менеджер не завжди може бути доступним для кожної покупки.
Командам слід враховувати:
- Відпустки
- Різні часові пояси
- Звільнення працівників
- Термінові покупки для заходів
- Регулярні підписки
- Платежі поза робочим часом
Якщо постачальник це підтримує, використовуйте належним чином уповноважені ролі або адміністраторів замість спільного використання логіна чи методу автентифікації одного працівника.
Якщо постачальник не підтримує резервну відповідальну особу за автентифікацію, команді, можливо, доведеться планувати важливі покупки заздалегідь або використовувати інший затверджений спосіб оплати.
Рішення має бути передбачене робочим процесом, а не імпровізоване в останню хвилину.
Ведіть простий командний запис
Для важливих продавців зберігайте простий внутрішній запис, що містить:
- Відповідального за покупку
- Особу, яка погоджує витрати
- Позначку картки
- Відповідального за автентифікацію
- Затверджений резервний процес
- URL-адресу облікового запису постачальника
- Контакт служби підтримки
Не зберігайте:
Мета не в тому, щоб створити великий документ із вимогами відповідності.
Потрібно лише переконатися, що покупець знає, до кого звернутися ще до початку оформлення платежу.
Три схожі проблеми, які потребують різних рішень
Деякі ситуації з 3DS можуть виглядати схожими, але потребують різних дій.
Запит надходить правильній людині, але містить неправильну суму
Відхиліть його та перевірте кошик, продавця й можливі дубльовані сеанси оформлення.
Запит надходить колишньому працівнику
Оновіть власника облікового запису через офіційну процедуру постачальника.
Ніхто не отримує запит
Перевірте перенаправлення браузера, застосунок постачальника, налаштування картки та запитайте службу підтримки, чи було ініційовано подію автентифікації.
Орієнтуйтеся на конкретну подію, яку ви побачили, а не припускайте, що кожна проблема — це просто «3DS не пройшов».
Після проблеми з автентифікацією
Короткий аналіз може допомогти запобігти повторенню тієї самої проблеми.
Зафіксуйте:
- Продавця
- Час і часовий пояс
- Позначку картки
- Суму
- Те, що відображалося на екрані покупця
- Те, що відображалося на пристрої відповідальної особи
- Чи було схвалено запит
- Статус замовлення у продавця
- Статус авторизації картки
Потім призначте одну людину відповідальною за усунення основної проблеми.
Це може означати оновлення застарілого номера телефону, зміну власника облікового запису, додавання уповноваженої ролі, якщо така можливість підтримується, або вдосконалення внутрішнього процесу закупівель.
Правило, яке варто запам’ятати перед наступним оформленням платежу
Перед введенням даних картки знайте:
Хто здійснює покупку?
Хто погодив витрати?
Хто може пройти автентифікацію 3D Secure?
Відповідальна за автентифікацію особа повинна самостійно перевірити запит у підтримуваному інтерфейсі емітента та підтвердити продавця, суму й валюту.
Якщо дані не збігаються або потрібна особа недоступна, зупиніть процес і перевірте статус замовлення перед повторною спробою.
Успішний процес — це не просто «код спрацював».
Це: Дійсна покупка + правильна автентифікація + підтверджене замовлення продавця + чіткий розподіл відповідальності за кожне рішення.
