A Customer Sent a Payment Screenshot: What Support Should Verify

Header image: conceptual illustration.

A payment screenshot can help support understand what the customer saw. It cannot establish that the correct merchant received the correct amount for the correct order. Even an authentic image may describe a different transaction, a pending transfer or a debit that was subsequently reversed.

The practical question is not whether support can judge an image convincingly. It is how support uses the image to locate and verify an authoritative merchant-side record without collecting unnecessary personal information.

Treat the screenshot as a claim to investigate

Record a short description of the customer's issue and the order reference already available in the authenticated support context. If the screenshot contains a transaction reference, use it as a search clue. Do not assume a particular length or format applies to every wallet or provider.

Avoid asking for additional images when the merchant already has enough information to search its records. If evidence is needed, explain which limited non-secret details are useful. Never request PINs, OTPs, passwords or full payment-card details. A screenshot that exposes them should be handled through the organization's protected process, not copied into a public team chat.

An image-based extraction tool, if used, produces candidate text. It does not verify funds. Human-readable receipt wording is also not a substitute for the financial record.

Search inside the correct merchant context

Begin with the order and its known payment attempts. Then check the supplied reference against the appropriate provider account and environment. Confirm that any result belongs to the receiving merchant, not just that the reference exists somewhere.

If one order has multiple attempts, inspect all relevant attempts before concluding it is unpaid. If the same reference appears against multiple orders, hold the ambiguity for review. Do not choose the order with the closest timestamp or amount automatically.

SSLCommerz's official documentation requires validating the transaction and amount using its Order Validation API. Stripe's status guide describes inspecting the payment resource's actual status. These are concrete examples of merchant-side verification, not evidence that PayEurasia offers either integration.

Check the full confirmation set

• The provider-defined successful final state applies to the payment operation.
• The resource belongs to the expected merchant/account and environment.
• The merchant order or linked payment reference matches the intended purchase.
• The amount and currency match the obligation being credited.
• The financial credit has not already been applied for this provider resource.
• No contradictory refund, dispute or reversal information requires a separate review.

A valid notification signature proves something about origin and integrity; it does not independently establish this entire set. Once verified, credit idempotently using the payment identity. Support should not manually add a second credit because the customer submitted an additional image.

Worked hypothetical support case

Invented example: A customer reports paying BDT 1,200 for DEMO-ORDER-S. The screenshot shows BDT 1,200 and a plausible reference. The merchant-side search finds that reference attached to another demo order in the same test scenario.

Support marks the claim unresolved and asks only for the missing order context through the approved channel. It does not move the payment between orders without authorization. A second search later identifies the correct successful resource for DEMO-ORDER-S, matching merchant, amount and currency. The ordinary crediting process confirms that the order was already credited, so no new credit is added.

The final explanation tells the customer the verified order status. It avoids accusing the customer of fraud merely because the initial image was insufficient.

What to do when no record matches

Distinguish an unavailable search from a completed search with no matching record. Check whether the correct account, environment and date range were used. Review pending attempts and delivery problems before directing the customer toward another payment.

If the customer's wallet shows a debit but the merchant cannot verify receipt, escalate the uncertainty to the appropriate provider using a sanitized case reference. Do not promise a refund or claim a transaction has been located when it has not.

For wallet-specific onboarding and verification questions, consult the bKash merchant guide. For broader controls, use the payment fraud prevention guide, while keeping routine support investigation separate from a formal fraud allegation.

Support verification checklist

• Search clues and verified facts are visibly distinguished.
• References are checked in the correct merchant context.
• Amount-only matching never grants fulfillment.
• Duplicate or already-credited results do not create additional value.
• Screenshots are not used to request credentials or unnecessary identity data.
• Unresolved cases have an owner and an evidence-based next step.
• Customer replies describe actual observations, not guessed payment outcomes.

Frequently asked questions

Can an authentic screenshot still be insufficient?

Yes. Authenticity does not prove the receiving merchant, order match or final status.

Should support automatically reject screenshot submissions?

No. They can be useful clues. The decision must depend on verified merchant-side records, not the image alone.