Інтеграція Simplex: де ламається приймання карток
Картковий платіж на біржі — це ланцюжок із чотирьох ланок: платіжна сторінка, фіатний шлюз, підтвердження банку-емітента та зарахування крипти на баланс.
Ламається зазвичай не вхід, а стик: банк гроші списав, шлюз не віддав фінальний статус, і операція зависає між «оплачено» та «не оплачено». Клієнт бачить списання, балансу немає — і йде в підтримку або відразу в банк.
Далі вмикається механіка чарджбеку. Право оспорити платіж має клієнт, і якщо біржа не представить докази в строк, суму повертають примусово — вже разом із криптою, яка пішла на гаманець. Завислий платіж перетворюється на подвійний збиток: актив видано, гроші повернулися.
Частина кейсів розбирається вручну: листування, вивантаження, звірка хешів транзакцій — при потоці в сотні операцій це години роботи підтримки щодня.
Інтеграція Simplex і подібних фіатних шлюзів знімає половину проблеми на рівні повідомлень про зміну статусу та захисту від повторних зарахувань — але тільки якщо правила повернення коштів клієнту, таймаути та порядок ручного розбору прописані заздалегідь.
Інакше повторні запити створюють дублі, а спірні операції накопичуються в черзі без відповідального.
Ціна помилки — не одне повернення, а довіра: клієнт, який чекав зарахування два дні й отримав відмову, вдруге карткою не заплатить. Розбираємо, як це закривається в інтеграції — покроково.
Що змінює підключення фіатного шлюзу до біржі
Фіатний шлюз стоїть між клієнтом та його балансом на біржі, і саме на цьому відрізку вирішується доля платежу.
Підключення зовнішнього провайдера — у нашому випадку Simplex — переводить приймання карток і переказів у керований потік: біржа дізнається про зміну статусу операції в момент події, а не коли клієнт уже написав у підтримку.
Швидкість зарахування та конверсія оплати
Провайдер надсилає повідомлення про кожен перехід статусу, біржа обробляє їх і нараховує кошти автоматично — шлях від підтвердження платежу до балансу скорочується з годин до хвилин.
Це прямо впливає на конверсію приймання платежів: клієнт бачить проміжні стани («обробляється», «підтверджено»), а не порожній екран очікування, і не йде шукати інший спосіб введення.
Другий фактор — набір методів оплати під регіон і валюту клієнта. Коли доступні способи не збігаються з тим, що людина реально має на руках, відмова трапляється ще до введення даних і у звітності виглядає не відмовою, а невдалою спробою.
Зниження частки повернень і навантаження на підтримку
Повернення платежу майже завжди впирається в докази: хто, коли і на якій підставі провів операцію. Інтеграція зберігає по кожній транзакції ідентифікатор, статус, час і прив'язку до клієнта — цього набору достатньо, щоб оспорити претензію, а не закрити її за свій рахунок.
Як наслідок, частка повернень падає, а навантаження на підтримку знижується: типові питання «де гроші» закриваються статусом в особистому кабінеті, а не листуванням.
Звірка операцій теж перестає бути ручною — вона відбувається зіставленням вивантажень провайдера і внутрішнього реєстру, і розбіжності спливають відразу, а не накопичувальним підсумком.
Режими підключення платіжного шлюзу: що вибрати
Режим підключення визначає, де користувач проходить перевірку особи і вводить платіжні дані, — від цього залежать терміни запуску та частка покинутих оплат.
При інтеграції Simplex доступні три схеми: редирект на сторінку провайдера, вбудоване вікно оплати всередині біржі та пряме підключення по API.
Редирект на сторінку провайдера
Користувач переходить на хост провайдера, а біржа отримує підсумковий статус по вебхуку і повертає його за узгодженою адресою. Платіжні дані та підписання оферти залишаються на стороні провайдера, тому це найшвидший варіант за термінами.
Ціна — розрив сесії, а адресу повернення потрібно перевіряти за підписом, інакше статус оплати можна підробити.
Вбудоване вікно оплати всередині біржі
Вікно відкривається поверх інтерфейсу, і користувач не залишає біржу до кінця сценарію. Список доступних країн і перевірки надходять від провайдера ще до старту, тому недоступний регіон відсікається відразу. Потрібно узгодити домен і обробляти події вікна, зате утримання на кроці оплати вище.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Редирект на сторінку провайдера | Потрібен швидкий запуск і мінімум доопрацювань на стороні біржі | Розрив сесії, повернення строго за підписаною адресою, частина переходів губиться |
| Вбудоване вікно оплати всередині біржі | Важливо утримати користувача і відразу відсікти недоступні регіони | Узгодження домену, обробка подій вікна, частина країн закрита на стороні провайдера |
| Пряме підключення | Свій інтерфейс оплати та аналітика по кожному кроку | Потрібно закрити ідемпотентність, повторні запити та проміжні статуси |
Інтеграція Simplex у біржовий контур: етапи робіт
Роботи йдуть так, щоб не ламати вже діюче приймання карток: спочатку фіксуємо фактичний стан обміну з провайдером, потім збираємо схему потоків платежів і тільки після цього змінюємо код і правила обробки статусів.
Аудит поточного контуру приймання карток
- Знімаємо схему потоків платежів: хто ініціює покупку, де зберігається ліміт на користувача, як зовнішній ідентифікатор угоди зіставляється з внутрішнім ордером і балансом.
- Розбираємо незавершені покупки — завислі, скасовані за таймаутом, відхилені провайдером. Найчастіше саме тут знаходяться розбіжності щодо зарахувань, тому сценарії описуються до початку доопрацювань.
- Налаштовуємо повідомлення про статус: підтвердження приймання, зміна стану угоди, фінальний результат, повторна доставка та події із запізненням. Обробники робимо ідемпотентними — повторний статус не повинен нараховувати актив двічі.
Перевірка сценаріїв повернення
- Проходимо повернення за всіма ініціаторами: сам користувач, підтримка, претензія платіжної системи. Для кожного випадку визначаємо, хто запускає повернення, як списується актив і що клієнт бачить в історії операцій.
- Звіряємо розрахунки: зарахування, комісія провайдера та повернення повинні сходитися зі звітами повністю, розбіжності закриваються до передачі в експлуатацію.
- Передаємо контур в експлуатацію: метрики частки успішних покупок, скасувань за таймаутом і повернень, регламент розбору розбіжностей, інструкція для підтримки та тестові сценарії для перевірки після оновлень.
Пакет передачі: схеми, ключі доступу та регламенти
Інтеграція Simplex не закінчується робочим запитом до провайдера: після запуску у замовника залишається комплект, за яким чергова зміна або новий інженер підніме потік без листування з нами. Нижче — склад пакета передачі.
Схеми потоків і розмежування ролей
- Схема підключення: виклики від створення заявки до зарахування коштів, точки повторних спроб, поведінка при недоступності провайдера.
- Карта середовищ: тестовий і робочий контури, роздільні набори ключів, відмінності в лімітах і логіці перевірок.
- Матриця ролей доступу: хто бачить платіжні дані, хто змінює ліміти та ключі, хто працює тільки з читанням журналу.
- Порядок ротації ключів: періодичність, відповідальні, зміна секретів без зупинки потоку.
Регламенти для підтримки та фінансів
- Інструкція для підтримки: як розбирати завислі та відхилені платежі, що перевірити за перші хвилини, коли ескалувати інженеру.
- Регламент спірних платежів: терміни реакції, доказова база — ідентифікатор операції, статуси, повідомлення провайдера, — порядок спілкування з банком.
- Журнал операцій: склад полів, термін зберігання, вивантаження вибірки за конкретним випадком.
- Чек-ліст приймання: сценарії, які проганяємо разом із командою замовника до передачі.
Комплект залишається у замовника поруч із конфігурацією: потік піднімається за документами, а не за пам'яттю інженера, що пішов.
Кейс: як зняли потік повернень на біржі
Біржа приймала картки напряму через банк-еквайєр, і кожен спірний платіж перетворювався на ручний розбір.
Частка повернень трималася близько 4% від карткових операцій, більше половини — за сценарієм «кошти списані, криптовалюта не зарахована»; перша лінія витрачала на таке звернення до 40 хвилин.
Що було до впровадження
Відповідальність за ризик була розмита: біржа сама приймала претензію, сама запитувала докази і сама вела листування з банком.
Єдиного журналу статусів не було — оператор збирав історію з логів білінгу, виписок еквайєра та пошти, тому відповідь часто виходила за вікно, відведене платіжною системою, і спір закривався не на користь біржі. У пікові дні накопичувалося понад 200 тікетів.
Що стало після
Інтегрували Simplex як шар приймання карток із власним антифродом і передачею статусів по вебхуках. В операції з'явився машиночитний ідентифікатор: оператор бачить причину відмови без вивантаження з логів, а перевірка підпису вебхука відсікає підробку статусу.
Частка оспорених платежів знизилася до 0,6–0,9% — підтвердження власника картки переноситься на етап оплати, а не на етап розбору.
Час розбору спірного платежу скоротився з 40 хвилин до 5–7, звернення в підтримку щодо незарахування — приблизно вчетверо.
Частка успішних операцій зросла з 94 до 98,5%: повторні спроби йдуть автоматично, і стабільність приймання карток більше не залежить від завантаження чергової зміни.
Чим відрізняється пряме підключення від редиректу?
Два способи приймання карток різняться тим, де вводиться номер картки і на чиїй стороні залишається відповідальність за ці дані.
При редиректі клієнт переходить на сторінку платіжного сервісу і повертається з результатом, при прямому підключенні форма живе всередині інтерфейсу біржі, а запити йдуть через API. Звідси випливають обсяг доопрацювань, вимоги провайдера та швидкість зарахування.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Редирект на сторінку провайдера | Швидкий запуск приймання карток, мінімум власних вимог до захисту даних | Користувач залишає інтерфейс біржі, брендування обмежене, статус надходить із затримкою |
| Пряме підключення по API | Повний контроль сценарію покупки, свої статуси та повторні спроби | Більше доопрацювань, свій контур обробки та логування, суворіші перевірки провайдера |
Щодо відповідальності за дані клієнта різниця принципова. На редиректі карткові дані не проходять через вашу інфраструктуру — повертається тільки підписаний статус операції, зберігати нічого.
Пряме підключення через Simplex теж токенізує картку, але логи, контур обробки та перевірки стають вашими.
За обсягом робіт редирект — це підпис запиту, дозволені адреси повернення та обробник вебхука зі статусами, зазвичай кілька днів бекенду.
Пряме підключення потребує віджета, окремого сценарію на кожну відмову, повторної автентифікації по картці та звірки статусів з провайдером — це вже повноцінний платіжний модуль.
Швидкість зарахування залежить від кількості переходів і моменту, коли біржа дізнається фінальний статус. На редиректі користувач переходить на чужий домен, частина людей на цьому кроці губиться, а монети чекають підтвердження. При прямому підключенні статус надходить у той самий інтерфейс, і зарахування відбувається раніше.
Часті технічні питання щодо приймання карток на біржі
Питання, які найчастіше спливають на узгодженні приймання карток, — майже всі про експлуатацію, а не про сам обмін даними. Нижче п'ять типових сумнівів з відповідями по суті: вони визначають, як буде влаштована звірка, доступи та ліміти після запуску.
У нас уже працює інший провайдер — доведеться все переробляти?
Ні. Приймання платежів виноситься за інтерфейс біржі: заявка на виведення надходить із внутрішнього сервісу, а зміни стосуються тільки шару інтеграції.
Паралельний запуск другого каналу на частині трафіку дозволяє порівняти конверсію та частку спірних платежів без зупинки поточного.
Хто відповідає за спірні платежі та повернення?
Відповідальність розмежовується договором із платіжним партнером: він приймає претензію і працює з нею як із картковою операцією. Наша частина — передати доказову базу: статусну історію заявки, підтвердження володіння карткою та дані акаунта. Якщо база зібрана коректно, частка програних спорів падає кратно.
Як перевіряється звірка з провайдером?
Звірка відбувається регулярним завданням: наш журнал операцій зіставляється зі звітом партнера за ідентифікатором платежу, розбіжності потрапляють в окрему чергу.
Кожен статус має однозначний перехід, а повторна доставка повідомлень не створює дублів — це закриває клас помилок, коли заявка висить у проміжному стані.
Як обмежити доступ до ключів і платіжних даних?
Секрети зберігаються в захищеному сховищі і ніколи не потрапляють у код або логи; підпис запитів формується на стороні сервісу. Доступ розділено за ролями та середовищами, звернення обмежені списком довірених адрес, ротація ключів відбувається без зупинки приймання.
Які ліміти та ризики закладати?
Ліміти задаються на суму та частоту операцій за карткою та акаунтом, окремо — за регіонами з підвищеним ризиком. Додатково вмикаються перевірка власника картки та правила ручної перевірки великих виведень.
Підключення в тестовому контурі займає кілька днів, бойовий режим відкривається після прогону сценаріїв відмови та повернення.
Обговоримо вашу схему приймання платежів на біржі
Щоб розмова була предметною, на першому дзвінку розбираємо вашу поточну схему приймання платежів: як надходить оплата, на якому етапі підключається Simplex, хто обробляє повернення та спірні операції. Цього достатньо, щоб побачити вузькі місця і зрозуміти, що закривати в першу чергу.
- Що розбираємо на дзвінку: маршрут платежу від вибору способу оплати до зарахування на баланс, ролі в спірних ситуаціях, поточні ліміти та обмеження.
- Оцінка та план робіт: після дзвінка надсилаємо склад етапів, порядок підключення, точки перевірки та зони відповідальності.
- Пілот на одному напрямку: запускаємо одну валюту або один канал, перевіряємо частку успішних операцій та обробку повернень на реальному потоці.
- Передача документації: схеми проходження платежу, опис налаштувань, регламент дій при чарджбеку та інструкції для підтримки.
- Супровід після запуску: стежимо за показниками та розбираємо інциденти, поки схема не вийде на стабільний режим.
- Доступи та безпека: проговорюємо, які права потрібні на час робіт і як вони закриваються після.
Опишіть задачу в зручному форматі — повернемося з оцінкою та планом робіт і запропонуємо порядок кроків. Далі узгодимо обсяг і стартуємо з пілота.
