Карткові платежі
Карткові платежі: від термінала до еквайра й назад до облікової книги
Термінали EMV і платіжні шлюзи, підключені до еквайрів через ISO 8583 чи API, зі звірянням файлів розрахунків в ERP.
Архітектурний план
Прокрутіть убік, щоб побачити весь малюнок.
Карткові платежі: авторизація на касі, розрахунки пізніше, звіряння в ERP
Термінал або оформлення замовлення звертається до шлюзу, шлюз до еквайра, а еквайр маршрутизує до карткової мережі та емітента. Файли розрахунків надходять пізніше й зіставляються з продажами та комісіями в ERP. Тайм-аут запускає скасування, щоб із клієнта ніколи не стягнули двічі.
- Основний потік
- Асинхронний
- Шлях винятків
Потік у 8 кроках
Потік крок за кроком
- Від Термінал EMV або онлайн-оформлення до Платіжний шлюз: Запит авторизації, через EMV · REST/JSON (основний потік).
- Від Платіжний шлюз до Еквайр: Авторизація, через ISO 8583 (основний потік).
- Від Еквайр до Карткова мережа й емітент: Маршрутизовано до емітента, через ISO 8583 (основний потік).
- Від Еквайр до Платіжний шлюз: Схвалено або відхилено, через ISO 8583 (асинхронний).
- Від Еквайр до Шар інтеграції: Файли розрахунків і комісій, через SFTP (асинхронний).
- Від Шар інтеграції до ERP: Розраховані продажі, комісії та виплати, через REST/JSON (основний потік).
- Від Платіжний шлюз до Термінал EMV або онлайн-оформлення: Немає відповіді вчасно: автоматичне скасування, через ISO 8583 0400 (шлях винятків).
- Від Шар інтеграції до Операційна команда платежів: Розбіжність розрахунків або чарджбек (шлях винятків).
Огляд
Це шлях карткового платежу, від термінала чи онлайн-каси до еквайра, карткової схеми й емітента та назад. Клієнт чекає на відповідь біля каси. Гроші, за вирахуванням комісій, надходять пізніше у файлі розрахунків, який треба зіставити з продажами у вашій ERP.
Еталонний проєкт спрямовує авторизації через платіжний шлюз, що токенізує картку й маршрутизує запит до еквайра через ISO 8583 чи API еквайра. Інтеграційний шар збирає файли розрахунків і комісій, зіставляє їх із початковими продажами й проводить в ERP продажі, комісії та виплати.
Проєкт також охоплює те, що йде не так. Запит без відповіді вчасно скасовується, щоб клієнта не списали двічі. Розрахунок, що не зіставляється, чи чарджбек потрапляє до вашої операційної платіжної команди з прикріпленим початковим продажем.
Як працює потік
Почніть із термінала чи каси
Термінал EMV читає чип чи безконтактну картку, або онлайн-каса приймає картку через розміщену сторінку й надсилає запит авторизації до шлюзу.
Авторизуйте через шлюз
Шлюз замінює номер картки токеном і надсилає авторизацію еквайру через ISO 8583 чи API еквайра.
Маршрутизуйте до емітента
Еквайр маршрутизує запит через карткову схему до емітента, який його схвалює чи відхиляє.
Поверніть відповідь
Схвалення чи відмова повертається тим самим шляхом до термінала чи каси з кодом відповіді.
Отримайте розрахунок
Пізніше еквайр надсилає файли розрахунків і комісій, які інтеграційний шар збирає й перевіряє.
Зіставте й проведіть
Шар зіставляє розраховані транзакції з початковими продажами й проводить в ERP продажі, комісії та виплати.
Коли щось збоїть
Немає відповіді вчасно
Якщо шлюз не отримує відповіді в межах ліміту часу еквайра, він надсилає скасування, повідомлення ISO 8583 0400 чи його аналог в API, щоб клієнта ніколи не списали за продаж, що не завершився.
Платіж відхилено
Код відповіді доходить до каси чи оформлення замовлення з чітким повідомленням. Частка відмов відстежується, тож стрибок, що вказує на технічний збій, піднімає оповіщення.
Розрахунок не зіставляється
Розрахована сума, що відрізняється від продажу, або продаж без розрахунку потрапляє до списку на перегляд для вашої операційної платіжної команди, з обома записами поряд.
Держатель картки оспорює платіж
Звіт еквайра про спір імпортується й повʼязується з початковим продажем і розрахунком, щоб ваша команда могла відповісти з доказами в одному місці.
Стандарти й системи
- Банківські стандарти й канали
- SFTP (H2H)
- Платежі
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
- Інтеграція
- REST
- Webhooks
Запитання й відповіді
Яка різниця між шлюзом і еквайром?
Еквайр є банком чи ліцензованою установою, що обробляє ваші карткові платежі й виплачує вам кошти. Шлюз є технічним сервісом перед ним, що приймає запити від терміналів і сторінок оплати, токенізує картки й маршрутизує їх. Деякі провайдери виконують обидві ролі. Архітектура працює в будь-якому разі й чітко розмежовує ці дві ролі.
Чи не потрапляють карткові дані в наші системи?
Це мета проєкту. Номери карток приймає сертифікований термінал чи розміщена платіжна сторінка й замінює токенами на шлюзі, тож ваш POS, ERP і сховища даних бачать лише токени. Це зменшує частину вашої інфраструктури, до якої застосовується PCI DSS. Остаточний обсяг підтверджує ваш оцінювач.
Чи однаковий ISO 8583 для кожного еквайра?
Ні. ISO 8583 визначає структуру, а кожен еквайр чи мережа публікує власну специфікацію полів, типів повідомлень і кодів. Тому ми будуємо за специфікацією еквайра й виконуємо його сертифікаційні тести. API шлюзу перед еквайром приховує ці відмінності, що часто простіше для рітейлерів.
Чому розрахунок надходить пізніше за продаж?
Авторизація лише резервує кошти. Еквайр розраховується пакетами, відраховуючи свої комісії й будь-які збори схеми, і виплачує за власним графіком. Тому проєкт трактує авторизацію й розрахунок як окремі події та зіставляє їх, щоб фінанси бачили, що продано, що розраховано й що ще надійде.
Чи підтримуєте ви EMV 3-D Secure для онлайн-платежів?
Так. Для онлайн-карткових платежів ми інтегруємо EMV 3-D Secure через шлюз, щоб емітент міг автентифікувати держателя картки там, де цього вимагає регуляція чи ризик. Ми обробляємо потоки з викликом і без нього в оформленні замовлення й тестуємо обидва тестовими картками провайдера.
Чи можемо ми використовувати більше ніж одного платіжного провайдера?
Так. Інтеграційний шар тримає одну внутрішню модель платежу й зіставляє її з кожним провайдером, тож ви можете маршрутизувати за каналом, країною чи типом картки або переміщати обсяг між провайдерами. Кожен провайдер усе одно потребує власної інтеграції й сертифікації, які ми плануємо провайдер за провайдером.
Почніть із розмови, а не з договору.
Розкажіть, що вам треба побудувати, зʼєднати чи захистити. Архітектор пройде це з вами, а потім порадить, з чого почати.
Що буде далі
Узгодження часу
Наша команда напише вам, щоб узгодити час сесії.
Попередня консультація
Формат: безкоштовна 30-хвилинна онлайн-консультація перед співпрацею. Ми разом розбираємо ваші цілі, системи й обмеження.
Оцінка готовності
На кроці «безкоштовна 48-годинна оцінка готовності» головний архітектор перевіряє ваш проєкт за 6 пунктами Definition of Ready і рекомендує відповідний трек.
Вибір треку
Проєкти з готовим обсягом отримують обовʼязкову пропозицію протягом від 3 до 5 робочих днів. Проєкти на стадії концепції починаються в Blueprint Studio. Робоча система, яка дає збої, не має документації або потребує інтеграції, починається з діагностики тривалістю від 1 до 2 тижнів. Blueprint Studio і діагностика мають фіксовану плату, зазначену в пропозиції.