Verifying payments before launchПроверка платежей до запуска
A successful-payment message and money arriving in an account describe different events. Implementation must establish which evidence changes an order, how an uncertain result is investigated, and how a provider settlement is explained. Start with one payment path and its exceptions.Сообщение об успешной оплате и поступление денег на счёт описывают разные события. При внедрении нужно согласовать, какое подтверждение меняет заказ, как разбирают неизвестный результат и чем объясняется выплата провайдера. Начните с одного платёжного пути и его исключений.
Record the payment pathЗафиксировать платёжный путь
The finance owner and configurator list the channel, provider, terminal model, operating country and available payment methods. Map the chain: order, payment attempt, confirmed outcome, refund where needed and settlement. Each transition needs an evidence source and an identifier that allows records to be matched.Финансовый владелец и настройщик перечисляют канал, провайдера, модель терминала, страну работы и доступные способы расчёта. Составьте цепочку: заказ, платёжная попытка, подтверждённый результат, возврат при необходимости и выплата. Для каждого перехода нужен источник сведений и идентификатор для сопоставления.
Verify connectivity for the specific combination of conditions. Support for one device or country does not establish support for another. SABSUS describes payments linked to orders, sources, shifts and fees; before launch, confirm which fields your provider actually supplies and where gaps remain.Подключение проверяйте для конкретного сочетания условий. Поддержка одного устройства или страны не подтверждает другое. В SABSUS платёж описан в связи с заказом, источником, сменой и комиссией; перед запуском подтвердите, какие сведения действительно приходят из вашего провайдера и где остаются пробелы.
Define what confirmations meanОпределить смысл подтверждений
Keep examples of provider responses and define their operational meaning: pending, confirmed success, failure or unknown outcome. Do not treat a missing response as failure. The process owner decides when fulfillment may continue, and the tester verifies that the actual exchange follows that decision.Сохраните примеры ответа провайдера и объясните их рабочий смысл: ожидание, подтверждённый успех, отказ или неизвестный результат. Не подменяйте отсутствие ответа отказом. Владелец процесса определяет, когда можно продолжить исполнение заказа, а проверяющий подтверждает соответствие этой логики фактическому обмену.
Check a late confirmation and repeated delivery of the same event. Reconcile payment attempts, orders and actual charges. When the result is ambiguous, staff first establish the outcome of the original attempt; requesting payment again should not be the routine remedy for an unclear status.Проверьте позднее подтверждение и повторную доставку одного события. Сопоставьте число платёжных попыток, заказов и фактических списаний. Если результат неоднозначен, сотрудник сначала выясняет исход исходной попытки; повторный запрос денег не должен быть стандартным способом устранения непонятного статуса.
Link refunds to the original paymentСвязать возврат с исходной оплатой
Prepare illustrative full and partial refunds in an agreed safe environment. Verify the original transaction, permitted amount, approver and final confirmation. Creating a refund request does not mean the refund has completed; customer wording must reflect the actual stage rather than merely a staff action.Подготовьте условный полный и частичный возврат в согласованной безопасной среде. Проверьте исходную операцию, разрешённую сумму, согласующего и окончательное подтверждение. Создание запроса на возврат не означает его завершения; клиентский текст должен учитывать фактический этап, а не только действие сотрудника.
Examine rejection, delay and a repeated click. The reconciliation owner needs to distinguish money already refunded from money still under review. Specific capabilities, timing and rules depend on the verified connection and provider terms; this guide does not establish universal refund conditions.Разберите отказ, задержку и повторное нажатие. Владелец сверки должен видеть, какая сумма уже возвращена и какая ещё на рассмотрении. Конкретные возможности, сроки и правила задаются подтверждённым подключением и условиями провайдера; статья не устанавливает универсальные условия возврата.
Explain the provider settlementОбъяснить выплату провайдера
Select a closed settlement period and reconcile confirmed payments, refunds, fees and the actual payout. In an illustrative example, payments are 100, refunds 20, fees 3 and the payout 77. Every amount uses the same illustrative currency unit; these numbers demonstrate arithmetic, not a provider tariff.Возьмите один закрытый расчётный период и сопоставьте подтверждённые оплаты, возвраты, комиссии и фактическую выплату. В условном примере оплаты составляют 100, возвраты 20, комиссия 3, а выплата 77. Все суммы выражены в одной условной денежной единице; это арифметика примера, не тариф провайдера.
If the real payout differs, inspect period boundaries, holds and late transactions using available provider evidence. Do not add an unexplained adjustment merely to force agreement. The finance owner accepts reconciliation with a separate discrepancy list, sources and an owner for investigating each case.Если реальная выплата отличается, проверьте границы периода, удержания и поздние операции по доступным сведениям провайдера. Не добавляйте необъяснённую поправку ради совпадения. Финансовый владелец принимает сверку с отдельным списком расхождений, источниками и ответственными за уточнение каждого случая.
Accept evidence for each channelПринять доказательства по каналу
Acceptance identifies tested devices, methods, states and refund scenarios. The cashier confirms workable actions, the configurator verifies event delivery, and the finance owner verifies reconciliation. An untested channel is not ready merely because it resembles a tested one; it needs its own evidence.Приёмка перечисляет проверенные устройства, методы, статусы и сценарии возврата. Кассир подтверждает понятность действий, настройщик — передачу событий, финансовый владелец — возможность сверки. Непроверенный канал не считается готовым по сходству с проверенным; ему нужен собственный набор подтверждений.
Keep an unknown-outcome instruction naming responsible contacts and preventing uncontrolled retries. Tests must not initiate live charges without separate agreement. After changing a provider, terminal or status mapping, repeat the affected scenarios before expanding the volume of operations.Сохраните инструкцию для неизвестного результата с контактами ответственных и запретом бесконтрольных повторов. Проверки не должны сами создавать реальные списания без отдельного согласования. После смены провайдера, терминала или логики статусов повторите затронутые сценарии, прежде чем расширять объём операций.
Quick answersКороткие ответы
Is payment success the same as settlement?Успешная оплата равна выплате?
No. They have different evidence sources and dates. Reconcile them through transactions, refunds, fees and settlement-period boundaries.Нет. Это разные события с разными источниками и датами. Сопоставляйте их через операции, возвраты, комиссии и границы расчётного периода.
What should happen with an unknown status?Что делать при неизвестном статусе?
A designated worker checks the original attempt against available evidence. Until resolved, the payment is neither proven successful nor conclusively failed.Назначенный сотрудник проверяет исходную попытку у доступного источника. До выяснения результата нельзя считать платёж ни успешным, ни окончательно отклонённым.
Can all terminals use the same evidence?Все терминалы проверяются одинаково?
No. Verify the particular model, provider, country and scenario. A common method helps preparation but does not prove compatibility.Нет. Подтверждайте конкретную модель, провайдера, страну и сценарий. Общая схема помогает подготовиться, но не доказывает совместимость.