1. Did potential customers reach a product they can buy?
Compare complete, equivalent time windows and separate public product or guide pages from admin, merchant and payment pages. Staff, QA and existing merchants are not automatically new customers. Where historical internal visits cannot be identified, disclose that limitation rather than claiming they were removed.
Check the actual sales page, language, product demonstration, price and purchase button. A page view is not a purchase-button click. Missing click tracking means unknown, not zero. Anonymous analytics visitors cannot be matched to applications or orders without a valid linkage; do not manufacture a precise conversion rate from unrelated totals.
2. Does the purchase button reach the intended Checkout?
Follow the current public sales link on desktop and mobile without submitting a payment. Confirm the intended Store, product, active Price, amount and currency. A published link that is absent from the sales page, an old plan URL, or a button that silently fails can stop purchases before payment processing begins.
For an API integration, distinguish a click from a successfully created session. Keep the redacted request or session ID and the server response. For hosted links, inspect the actual destination and error shown. Fix the observed entry problem; do not change approval conditions or create new live prices merely to make a test pass.
3. Where does the buyer stop in the Russian payment flow?
Record whether Checkout opened, the buyer selected a method, reached bank confirmation, and the server recorded a final payment result. The Bank of Russia describes SBP purchases using methods including QR codes, links and buttons, with the buyer checking the recipient and amount before confirmation. This describes the general buyer flow, not every Store’s enabled capabilities.
Confirm the methods and billing model approved for the specific Store. A working one-time RUB purchase does not prove recurring billing is enabled. Keep pending, failed, expired and paid separate. If the result is uncertain, reconcile the existing order before suggesting another purchase; a browser return or screenshot alone is not authoritative payment evidence.
4. Was payment confirmed but access not delivered?
Trace the verified payment event to the same order and customer, then to a licence, download permission, quota or access-period record. Verify signatures and order identity and handle duplicate events idempotently. HTTP 200 establishes a response from an endpoint, not that the customer received the entitlement.
For manual delivery, keep an accountable owner and an order-linked completion record. Analytics purchase events are a separate measurement layer: Yandex documents ecommerce event data, while Google documents transaction IDs for purchase deduplication. Neither a browser analytics event nor its absence replaces the payment and delivery records.
5. What counts as the first real customer order?
Classify evidence as a genuine customer purchase, an internal/QA/sandbox or controlled payment test, or insufficient information. An order marked paid, a Live session, or absence of a test flag alone cannot settle the classification. Check the order, payment event, test markers and actual customer-business context; do not count an unresolved classification as a confirmed commercial first order.
Checkout publication, merchant confirmation that selling has begun, payment and successful delivery are separate milestones. Keep a later refund distinct from the original payment history. This diagnostic checklist does not impose a mandatory real payment or an additional approval stage before every launch.
6. What is the smallest useful support report?
Send the time with timezone, Test/Live mode, affected Store and product/Price reference, redacted order/session/event/request IDs, expected versus actual behaviour, and the last confirmed step. Include the purchase-page URL and a redacted error screenshot where useful. State whether the entitlement was actually granted and whether the issue is reproducible without paying.
Do not send secret keys, full payment credentials or identity documents in ordinary support messages. Review the evidence with your agreed support contact before repeating an uncertain payment. Improve the observed weak step before buying more traffic; if no relevant visitors have reached a working entry, payment failure has not yet been demonstrated.