Виявлення транзакції, підтвердження в ланцюгу, зв'язування із замовленням і надання послуги — це окремі кроки. Перевірте правильний ланцюг, актив, отримувача та суму; застосуйте задокументовану політику приймання; зробіть звіряння ідемпотентним. Посилання на транзакцію, скриншот або кнопка в браузері самі по собі не можуть підтвердити, що конкретне замовлення оплачено.
Відокремте подію в блокчейні від події замовлення
Повідомлення гаманця про надсилання переказу є свідченням його власної дії, а не остаточним рішенням про оплату. Приймальний бекенд має спостерігати за потрібною мережею, перевірити фактичний переказ і пов'язати його із замовленням. Лише після цього замовлення може застосувати свою політику приймання. Надання інфраструктури — це ще один операційний крок після приймання оплати.
Зберігайте ці переходи явними як у коді, так і в мові для клієнтів. Екран може показувати очікування, виявлення або підтвердження, не називаючи замовлення оплаченим. Не дозволяйте браузеру надавати прийняту суму або перезаписувати авторитетний статус. Зберігайте створену сервером пропозицію та її інструкції, щоб подальше звіряння можна було оцінювати щодо початкового замовлення, а не кошика, що змінюється.
Використовуйте правила впевненості, специфічні для блокчейну
Різні мережі описують впевненість у транзакції по-різному. Посібник для розробників Bitcoin пояснює, як вузли обирають ланцюг із найбільшим накопиченим доказом роботи та як можуть виникати конкуруючі блоки. Тому транзакція, побачена нещодавно, потребує політики щодо глибини підтвердження та можливих змін ланцюга. Не існує єдиної кількості підтверджень, придатної для кожного активу й комерційного ризику.
Документація Ethereum щодо доказу частки пояснює фінальність контрольних точок, а Solana документує стани зобов'язань processed, confirmed і finalized. Не перекладайте ці терміни необдумано в одну універсальну кількість блоків. Записуйте правило, специфічне для мережі, джерело інформації та поведінку в разі невизначеності. Оператор має визначати пороги приймання відповідно до ризику оплати й доставки, а не копіювати число з не пов'язаного оформлення замовлення.
Перевірте фактичне корисне навантаження переказу
Визначте отримувача, актив і суму в правильному ланцюгу. Платежі токенами потребують ідентичності потрібного токена, а не лише успішної транзакції на адресу. Перевірте відповідний успіх виконання та докази переказу згідно з моделлю ланцюга. Розбирайте цілочисельні суми з належною точністю активу, а не довіряйте відформатованому десятковому значенню, наданому браузером.
Платіжна інструкція має залишатися прив'язаною до свого початкового маршруту. Переказ в іншій мережі, інший токен із такою самою назвою або не пов'язане посилання на транзакцію не повинні її задовольняти. Запис перевірки має пояснювати, що було перевірено, і зберігати докази, потрібні для перегляду рішення. Цей посібник описує загальні принципи звіряння платежів, а не конкретну реалізацію сервісу.
Зробіть зв'язок із замовленням однозначним
Фіксовані адреси отримання можуть приймати кілька замовлень із подібними сумами. Наявність відповідного переказу не доводить, якому клієнту чи замовленню слід зарахувати оплату. Визначте метод зв'язування до початку приймання реальних платежів і передбачте обробку колізій. Надане користувачем посилання на транзакцію все одно потребує перевірки, що той самий переказ ще не призначено деінде.
Уявіть два рахунки на однакову суму на тому самому маршруті протягом періоду, що перекривається. Спостерігач бачить один переказ. Автоматично позначити обидва оплаченими неправильно; вибрати один без достатніх доказів також небезпечно. Залишайте переказ непризначеним або на перевірці, доки політика оператора не дозволить встановити дійсне зв'язування. Неоднозначний збіг — це стан, який потрібно обробити, а не причина вигадувати впевненість.
Визначте стани, які допускають пізні та змінні докази
Платіжний процес виграє від невеликого набору чітких станів, де докази з ланцюга відокремлені від рішення прийняти замовлення. Ця ілюстративна таблиця пояснює можливі етапи, а не описує назви статусів конкретного сервісу. Кожен перехід має мати перевірену причину, а приймання оплати має залишатися відокремленим від надання інфраструктури.
Враховуйте пізні, часткові та надлишкові перекази, закінчення строку дії пропозиції та тимчасову недоступність даних ланцюга. Закінчення строку не змушує реальний переказ зникнути. Пізній платіж може потребувати перевірки, а не автоматичного приймання чи відхилення. Якщо раніше побачена подія в ланцюгу змінюється, переоцініть стан за задокументованою політикою, а не вважайте кожне повідомлення спостерігача незворотною істиною.
| Ілюстративний стан | Значення | Наступне рішення |
|---|---|---|
| Очікування | Немає перевіреного відповідного переказу | Продовжуйте спостерігати за дійсним рахунком |
| Виявлено | Спостережено відповідний переказ | Перевірте впевненість ланцюга та зв'язування |
| Підтвердження | Правило приймання ще не виконано | Спостерігайте, доки політика не дозволить рішення |
| Перевірка | Пізні, часткові або неоднозначні докази | Вирішіть згідно з політикою оператора |
| Прийнято | Перевірений і звірений платіж | Перейдіть до окремого робочого процесу доставки |
Зробіть повторні спроби безпечними та спостережуваними
Спостерігачі та завдання звіряння повторюватимуть спроби після перерваних з'єднань або перезапусків процесу. Використовуйте стабільну ідентичність переказу, як-от ланцюг і відповідний ідентифікатор транзакції чи переказу, щоб запобігти подвійним зарахуванням. Зберігайте прогрес і рішення, щоб ту саму подію можна було обробити знову без надання другої послуги чи зміни прийнятої пропозиції.
Відрізняйте невідомий результат від невдалої операції. Якщо запит до нижчого рівня завершується тайм-аутом, перевірте його авторитетний результат перед повторним надсиланням. Зберігайте довговічні записи про прийняті та невизначені дії. Обмежуйте доступ до токенів замовлень і внутрішніх доказів, зберігаючи достатньо інформації для розслідування спірного платежу. Надійність тут означає повторювані рішення, а не плавну анімацію в оформленні замовлення.
Знайте, що ще потрібно замовленню в очікуванні
Замовлення може залишатися в очікуванні, бо переказ не спостережено, потрібну впевненість ланцюга не досягнуто або його зв'язування з рахунком потребує перевірки. Зберігайте рахунок і публічне посилання на транзакцію, перевірте зазначені правила приймання та скористайтеся передбаченим для замовлення процесом допомоги. Затримка оновлення статусу сама по собі не є причиною надсилати ще один платіж.
Дотримуйтеся інструкцій і перевіреного статусу для фактичного замовлення. Підтвердження оплати має вказувати на приймання звіреного переказу, тоді як доставка послуги має окремий статус. Не включайте приватні токени доступу та секрети гаманця в запити про допомогу.
Ваш практичний контрольний список.
- Зберігайте незмінну створену сервером пропозицію.
- Перевірте ланцюг, отримувача, актив і цілочисельну суму.
- Задокументуйте правила приймання, специфічні для ланцюга.
- Обробляйте колізії фіксованих адрес без здогадок.
- Запобігайте подвійним зарахуванням і небезпечним повторним надсиланням.
- Перевіряйте випадки пізніх, часткових, неправильних маршрутів і змінених доказів.
Деталі, які мають значення.
Чи достатньо хешу транзакції для підтвердження оплати?+
Ні. Перевірте переказ у потрібному ланцюгу, його вміст і впевненість, а потім встановіть, що він належить замовленню і ще не був зарахований.
Чи може кожна мережа використовувати однаковий поріг підтвердження?+
Ні. Мережі надають різні моделі впевненості та фінальності. Оператор має визначити й перевірити політику приймання, придатну для кожного маршруту.
Чи означає підтверджена оплата, що сервер надано?+
Ні. Приймання оплати та доставка — це окремі події робочого процесу. Повідомляйте статус надання з його власного авторитетного процесу.
Перейдіть до джерела.
Ці джерела підкріплюють технічні концепції в цьому посібнику. Дотримуйтеся поточної документації перед зміною робочої системи.
- Посібник для розробників Bitcoin: поведінка блокчейну developer.bitcoin.org
- Ethereum: доказ частки та фінальність ethereum.org
- Solana: зобов'язання стану RPC solana.com
Редакційне керівництво від SwissOctet. Приклади є ілюстративними. Специфікації послуг, доступні опції та договірні умови потрібно перевіряти окремо.