Подвійне зарахування криптоплатежу на папері виглядає просто, а на практиці — плутано. Один і той самий замовлення відображається як оплачене двічі, баланс гаманця здається завищеним, і раптом фінвідділ питає, чому один рахунок на $250 показано як два зарахування. Якщо вам потрібно зрозуміти, як виправити дублікати криптоплатежів, хороша новина в тому, що в більшості випадків причину можна швидко знайти, якщо перевіряти одні й ті самі кілька записів у правильному порядку.
Почніть із ID транзакції. Потім перевірте мітку часу, адресу гаманця та номер замовлення. Зазвичай ці чотири елементи одразу показують, чи це справжнє дубльоване зарахування, чи просто дві системи описують один і той самий платіж по-різному.
1. Визначте дубльоване зарахування
Перше завдання — довести, що дубльоване зарахування справді є. Подивіться на ID транзакції у своєму платіжному шлюзі, гаманці та внутрішньому записі замовлення. Якщо в усіх трьох місцях один і той самий платіж відображено лише один раз, проблема може бути в звітуванні. Якщо одне й те саме замовлення зараховано двічі двома окремими рядками в журналі, у вас справжнє дубльоване зарахування.
Як другий крок використайте мітки часу. Якщо перше зарахування прийшло о 14:03, а друге — о 14:06 для того самого замовлення, це важлива підказка. Порівняйте також адресу гаманця, бо інша адреса може означати, що клієнт надіслав другий платіж, а не ваша система подвоїла перший.
Записи замовлень так само важливі, як дані блокчейна. Клієнт міг оформити два замовлення з майже однаковими сумами, особливо якщо сторінка оформлення замовлення оновилася або браузер повторив спробу після збою мережі. Таке трапляється. Уважний аудит має відокремити один платіж, зарахований двічі, від двох окремих платежів, які просто надійшли майже одночасно.
Якщо ваша команда використовує панель керування, експортуйте повний набір рядків для замовлення, перш ніж щось змінювати. Збережіть хеш транзакції, номер блоку, суму, тип монети та статус підтвердження в одному місці. Ця невелика звичка зекономить час пізніше, коли бухгалтерія попросить підтвердження.
2. Призупиніть пов’язані платіжні дії
Коли є підозра на дубльоване зарахування, призупиніть повернення коштів, пов’язані з цим замовленням. Зупиніть також будь-які ручні коригування. Якщо співробітник скасує не той рядок, поки журнал ще змінюється, дубльоване зарахування може перетворитися на другу помилку, а її вже складніше розплутати.
Оновлення звірки також варто відкласти, доки все не стане зрозуміло. Пакетна синхронізація, яка запуститься під час розслідування, може перезаписати дані, які ви намагаєтеся зберегти. Одна зайва година затримки дешевша, ніж одне неправильне закриття.
Поставте кейс на паузу з приміткою, де вказано номер замовлення та підозрювану суму. Якщо ваша служба підтримки бачить прив’язаний тикет клієнта, вони мають знати, що не можна обіцяти остаточну відповідь до завершення перевірки. Проста примітка — менше сюрпризів.
Це також момент перевірити, чи активні будь-які автоматичні правила повернення коштів. Якщо правило налаштоване повертати невдалі платежі через 10 хвилин, призупиніть його для цього замовлення на час перевірки. Дубльоване зарахування й автоматичне повернення коштів — погане поєднання.
3. Перевірте платіж у блокчейні
У контексті перевірка криптоплатежу в блокчейні показує, чи платіж справді відбувся один раз, чи двічі. Порівняйте хеш транзакції, адресу отримувача, суму та кількість підтверджень із вашим внутрішнім журналом. Якщо в блокчейні є один переказ, а у вашій системі — два зарахування, проблема, ймовірно, внутрішня.
Перевірте також точний актив. Платіж у USDT в одній мережі — це не те саме, що платіж у USDT в іншій мережі, навіть якщо сума виглядає однаково. Один клієнт може надіслати 100 одиниць у неправильній мережі, і шлюз може некоректно це показати, якщо позначення мереж незрозумілі.
Для чистої перевірки зіставте запис у мережі, запис рахунку та запис у журналі поруч один з одним. Якщо ончейн-переказ має один хеш і одну адресу призначення, а ваш обліковий інструмент показує два зарахування, ви, ймовірно, маєте справу з помилкою відображення або обліку, а не з другим платежем у блокчейні.
Якщо ваша фінансова команда не звикла читати дані блокчейна, тут допоможе ще одна пара очей. Коротка внутрішня примітка на кшталт «той самий хеш, той самий гаманець, один шлях підтвердження» може вберегти від непотрібного скасування. Якщо потрібен орієнтир для процесу, команда також може переглянути як тестувати криптоплатіж перед будь-якими змінами в продакшені.
4. Перевірте налаштування шлюзу, гаманця та бухгалтерії
Більшість дубльованих зарахувань виникає через конфігурацію, а не через злий умисел. Повторні спроби webhook — поширена причина. Якщо платіжний шлюз надсилає один і той самий callback двічі, бо перший раз сплив тайм-аут, ваша система може зарахувати замовлення двічі, якщо не перевіряє повторні ID транзакцій.
Збої callback-и створюють схожу проблему. Шлюз може надіслати одну подію платежу, потім подію розрахунку, потім подію підтвердження, і слабка інтеграція може сприйняти кожну з них як нове зарахування. Особливо часто це трапляється, коли код не позначає платіж як «вже оброблено» після першого успіху.
Відкладені підтвердження теж можуть заплутати бухгалтерію. Платіж може спочатку відображатися як очікуваний, а потім підтвердитися пізніше, і оператор вручну введе зарахування ще раз, бо панель виглядала застарілою. Одного зайвого ручного запису достатньо, щоб створити дубльоване зарахування.
Налаштування гаманця теж варто уважно перевірити. Якщо бізнес використовує більше однієї адреси для отримання коштів або якщо одна й та сама адреса повторно застосовується для різних рахунків, правила зіставлення можуть зламатися. Проста помилка в адресному полі також може відправити платіж не на те замовлення і потім спровокувати другий коригувальний запис.
Експорти бухгалтерії заслуговують на таку саму увагу. Імпорт CSV може дублювати рядки, якщо файл завантажили двічі, а облікова платформа інколи може зберегти обидва записи, якщо не enforced один і той самий номер посилання. Для бізнесів, які проводять платежі через ecommerce-стек, шаблони в керівництві з криптоплатіжного шлюзу для ecommerce можуть допомогти команді зрозуміти, де саме дублюється шлях зарахування.
5. Скасуйте або звірте зайве зарахування
Не редагуйте оригінальний платіжний запис, якщо ваша система прямо цього не вимагає. Безпечніше створити сторнувальний запис або компенсувальне коригування, яке прибере зайве зарахування, залишивши початковий платіж недоторканим. Це зберігає аудиторський слід, а аудиторам аудиторські сліди подобаються недарма.
Використайте ту саму суму, ту саму валюту та той самий номер замовлення в коригуванні. Якщо дубльоване зарахування було 0.5 ETH, виправлення теж має показувати 0.5 ETH, а не округлену оцінку. Невеликі розбіжності пізніше створюють нові питання.
Багато команд тримають оригінальний платіжний запис заблокованим і додають примітку, яка пояснює сторнування. У цій примітці мають бути ID транзакції, співробітник, який затвердив виправлення, і час, коли було проведено коригування. Зазвичай трьох деталей достатньо для внутрішньої перевірки.
Зміни балансу мають бути видимі і в акаунті клієнта, і у фінансовому журналі. Якщо ваша система підтримує статусні мітки, використовуйте щось на кшталт «звірено» або «сторновано» замість видалення запису. Видалення приховує історію, а прихована історія створює проблеми під час закриття місяця.
Якщо дубль було створено через невідповідність шлюзу, а не через реальний додатковий платіж, вам може знадобитися лише бухгалтерське коригування. Якщо журнал, шлюз і гаманець усі підтверджують два зарахування, тоді сторнування має відбуватися за вашою стандартною політикою повернення або виправлення. Для команд, які переходять між процесорами, як мігрувати зі Stripe може стати корисною відправною точкою для перенесення старих записів у нові.
6. Повідомте клієнта та команду підтримки
Розкажіть клієнту, що сталося, простою мовою. Скажіть, що один платіж у системі було зараховано двічі, що дубль виправляють, і що початковий платіж залишається чинним. Уникайте розмитих фраз на кшталт «ми це з’ясовуємо», якщо ви вже знаєте причину.
Додайте докази в примітку до звернення. Хеша транзакції, номера рахунку та часу, коли з’явилося дубльоване зарахування, зазвичай достатньо. Якщо клієнт попросить більше, поділіться адресою гаманця та кількістю підтверджень, але не скидайте в тикет усі внутрішні рядки логів.
Команді підтримки потрібні ті самі факти, але в стислому вигляді. Одне речення про проблему, одне речення про план виправлення і один дедлайн наступного оновлення — цього достатньо, щоб усі були в курсі. Клієнт, який бачить дубльоване зарахування у своєму дашборді, хвилюватиметься менше, якщо знатиме, що з рахунком працюють у межах названого процесу.
Якщо клієнт — це продавець або фрилансер, який приймає крипту, вкажіть йому точний номер замовлення або рахунку, а не загальні вибачення. Стаття про криптоплатіжний шлюз для фрилансерів допоможе пояснити відстеження платежів на рівні рахунку так, щоб це було зручно показати клієнтам, які очікують акуратних записів.
7. Запобігайте дубльованим криптоплатіжним зарахуванням у майбутньому
Профілактика починається з перевірок idempotency. Якщо ваша система отримує той самий ID транзакції двічі, вона має обробити його один раз і проігнорувати другу подію. Це одне правило блокує дивовижну кількість випадків дубльованого зарахування.
Далі йде дедуплікація webhook. Зберігайте ID кожної callback-події та відхиляйте повтори, перш ніж вони дійдуть до бухгалтерії. Якщо ваш шлюз повторює повідомлення після тайм-ауту, система має розпізнати повтор і не чіпати зарахування.
Правила підтвердження теж важливі. Платіж має переходити зі стану очікування в зарахований лише після виконання того мережевого критерію, якому ви довіряєте, — чи то одне підтвердження, чи три, чи інший поріг, який схвалила команда ризиків. Без цього правила відкладені події в мережі можуть виглядати як нові гроші.
Перевірки звірки мають запускатися за графіком, а не лише після скарги. Щоденний або щотижневий порівняльний перегляд сум шлюзу, гаманця та журналу може виявити дубльоване зарахування ще до закриття місяця. Саме так команди знаходять дрібні помилки, наприклад один ручний запис, зроблений о 9:15 ранку і так і не видалений.
Код-рев’ю теж допомагає. Будь-який платіжний процес, що торкається callback-ів, записів у базу даних або статусу рахунку, слід перевіряти на подвійні шляхи обробки. Якщо вашим розробникам потрібен технічний орієнтир для цілісності платежів, вони можуть переглянути як перевіряти підписані вебхуки Payora перед внесенням змін.
Навчіть персонал відрізняти платіж у статусі очікування, підтверджений платіж і завершений запис у журналі. Три мітки, один робочий процес. Коли ці мітки використовують нечітко, створити дубльоване зарахування легше, ніж потім його виправити.
Ще один контроль — тестувати крайні випадки. Надішліть невеликий платіж, повторіть webhook, затримайте підтвердження та змоделюйте ручний запис. Якщо система зараховує лише один раз у всіх чотирьох випадках, у вас справи кращі, ніж у більшості команд. Якщо ні, наступне дубльоване зарахування не стане сюрпризом.
Коментарі