Understand how Selstack records the canonical offer, customer email, amount, currency, time, reference and current status, what requires review and how to reach a support-ready case without exposing card data or one-time codes.
Selstack separates checkout attempts, paid orders, wallet balances and payout activity so merchants can act from confirmed records rather than screenshots or assumptions.
Start with the recorded transaction
Open the relevant Selstack order, payment or wallet entry and match the reference, customer, amount, currency, gateway and current status. A bank alert or customer screenshot can support an investigation, but it does not replace the platform record or authorise fulfilment, refund or payout action.
Keep each amount in its own currency
For this topic, pay attention to the canonical offer, customer email, amount, currency, time, reference and current status. Preserve the customer-facing amount, fees, merchant remittance and wallet credit as separate labelled values. Do not overwrite a recorded amount with a hand-calculated conversion or describe pending funds as available cash.
Wait for final states before acting
Pending payments, verification reviews, balance holds and provider callbacks need a defined waiting path. Refresh the canonical record once, note the time and avoid duplicate submissions. Act only when the status and available controls support the next step.
Resolve exceptions through the original record
Use the order or payout record that created the issue. Check for an existing refund, withdrawal or provider attempt before creating another. Keep customer communication factual: say what Selstack currently shows, what is being checked and when the next update will be given.
Protect sensitive financial information
Never ask for passwords, OTPs, full card details or identity numbers in ordinary email, chat or a custom form. Share only safe references and masked evidence with official support. Changes to payout identity, destination or permissions deserve additional verification and an audit trail.
Reconcile and prevent recurrence
A complete review should explain what the customer paid, what the provider confirmed, what Selstack credited and what remains pending or disputed. The intended outcome is a support-ready case without exposing card data or one-time codes. Record the lesson in the operating process and avoid asking the customer to pay repeatedly before the original attempt reaches a final state.
Put Trace a Payment That a Customer Says Is Missing into practice
Search with the safe order reference, customer email, amount, currency and time, then read the provider-backed status.
If Trace a Payment That a Customer Says Is Missing breaks down
Do not ask for another payment while the original attempt is pending; escalate the existing reference if it does not reach a final state.
Final checks for Trace a Payment That a Customer Says Is Missing
- The active business, customer or transaction is the intended one.
- The public promise and internal process describe the same outcome.
- Amounts, currencies, dates and statuses are read from their labelled Selstack records.
- No password, OTP, full card detail or identity number is copied into ordinary notes or messages.
- An owner and a clear next review point are recorded for anything still pending.
What good looks like
a support-ready case without exposing card data or one-time codes. The main mistake to prevent is asking the customer to pay repeatedly before the original attempt reaches a final state.