“I paid. Here’s the receipt”: verify the payment without an interrogation

A bank-branded screenshot can look convincing and still leave the fulfilment decision unresolved. It may help locate the transfer. A good procedure helps a genuine customer receive their order while preventing the same image from authorising delivery twice. Start by finding the recipient-side record independently.

There are ordinary reasons for a mismatch: processing is incomplete, the wrong recipient was selected, or the customer attached a receipt from an earlier purchase. Accusing someone of fraud is a poor starting point. A consistent procedure works better, including when the customer is impatient or the image looks convincingly official.

Two equal payments: a hypothetical matching problem

Imagine two open orders, each for 7,500 roubles. The first customer sends a screenshot, and one transaction for 7,500 appears in the receiving account. Matching by amount alone could assign that transaction to the wrong order, or allow the same receipt to support both.

In this invented case, the operator compares the recipient, currency, timestamp, transaction reference and appropriate identifying information from the authorised record. The reference belongs to the second order. The first remains awaiting confirmation. An exact amount is a useful search filter, but it does not create a unique relationship.

If the connection remains unclear, keep the order in a review state and explain the next step: “We're checking the incoming payment. Please send the transaction reference and the time it was sent. You can hide unrelated transactions and your account balance.” Promise a next update only within a timeframe the team can actually meet.

Specify the decision you are making

Payment confirmation should answer four questions. Did the expected recipient receive the relevant transaction? Does it belong to this order? Are the amount and currency correct? Does the current state meet the fulfilment rule for this payment method?

Open the bank or provider through a known app or address, or use an authorised integration. PayPal advises sellers to log in and check their account activity before shipping. That supports independent verification; it does not establish a universal rule that every visible credit can never be reversed.

Three levels of evidence in one review queue

Separate information by what it establishes. A customer message or image helps start the search. A recipient-side record establishes a particular movement and its current state. Linking that record to an order lets the team apply its fulfilment rule. Make those transitions visible: Receipt received does not mean Transaction found, and Transaction found does not mean Order matched.

Keep three separate fields: where the check took place, which transaction was found, and why it belongs to this order. This is more useful than a free-text note saying “Looks fine”. Another colleague can review the conclusion without repeating the customer conversation or inspecting the screenshot again.

If a recipient-side record exists but the connection is uncertain, place it in an unidentified-receipts queue. With two identical amounts, request the missing reference that can distinguish them. Do not automatically escalate to a month’s bank statement. More personal data does not compensate for the absence of a useful matching key.

A five-step manual procedure

1. 1.Open the official source independently. Do not use a support number or login link supplied inside the image.
2. 2.Locate the recipient-side record and retain its transaction reference.
3. 3.Match amount, currency and order identity. Check whether the reference has already been used.
4. 4.Interpret the precise status using the provider's rules for that payment method.
5. 5.Record the evidence, decision, operator and time, then execute the authorised fulfilment action once.

Automated systems need the equivalent controls. Stripe recommends handling payment completion server-side, because a customer can leave the page before the merchant's client-side process finishes. A browser redirect to a thank-you page should not be the sole trigger for delivery.

The notification itself also needs validation. PayPal describes how to verify a webhook's authenticity. After verification, match the payment to the correct order and make its fulfilment action safe against repetition.

The awkward case: money arrives after the order closes

Imagine an inventory reservation expires at 2 p.m. and transfer confirmation arrives at 2:07. Automatically restarting fulfilment is risky because the item may no longer be available. Automatically declaring the money an overpayment is premature too. Link the receipt to the closed order and ask an authorised operator to determine whether renewed fulfilment or a refund is appropriate under the shop’s process.

When finishing a manual check, record a short outcome: confirmed, awaiting external confirmation, unmatched, or inconsistent. For an open case, specify the next enquiry and response time. The customer should understand what is being checked without receiving a shipment promise before the evidence is available.

Flag reuse of the same transaction reference. If that reference already supported another order, stop the second fulfilment and investigate the relationship. This controls errors and duplication. It does not by itself establish fraud, so there is no reason to turn the customer message into an accusation. The purpose is a reproducible decision based on a particular transaction.

Handle uncertainty without creating a second problem

Do not ask the customer to repeat a payment before establishing what happened to the first one. Escalate through the provider's official support route with the minimum necessary references. If an extra payment genuinely arrived, use the established refund workflow. For example, Stripe routes refunds to the original payment method; check the applicable method's limitations rather than improvising a transfer.

A request to send an alleged overpayment to a different account deserves a separate review. It should not become an urgent exception to the normal process. Never request a banking password, authentication code, full card details or access to another person's banking application to settle the question.

Keep supporting images only where the approved review process needs them, with access controls and a defined retention policy. Where a transaction reference is sufficient, avoid collecting an entire statement. These are sensible operating controls; exact privacy and recordkeeping obligations require local assessment.

To finish the check, ask another operator to reconstruct the source-to-transaction-to-order link from the retained record. If the relationship is established, apply the authorised fulfilment rule. If all that remains is an impression created by the image, verification is unfinished.

A verified receipt does not eliminate refunds or disputes; subsequent risks depend on the method and terms.