Use account support for account decisions and website reporting for website problems
If the page loads but an account is restricted, rejected or requires recovery, follow the support route shown by the account service. If an internal menu, page, image or link on this information website is broken, a website report should describe that page and the visible problem without including credentials.
What to include in a website problem report
- The page title or URL path you were using.
- The device type and browser.
- What you expected to happen and what happened instead.
- The approximate time the issue occurred.
- Whether the issue also happens in another browser or connection.
- A screenshot only after personal information has been removed.
What not to send
Do not include a password, OTP, bank password, card PIN, full payment details or identity document in a general website report. Those details are not required to describe a broken menu, blank page, layout issue or incorrect internal link.
Account-specific issues need the service that owns the account
Credential recovery, identity verification, account restrictions, transaction disputes and account-status decisions depend on the service handling the account. This information website does not create a substitute recovery process and cannot safely guess the steps for a live account condition.
If the account route shows a support or contact method, verify that you opened the intended service before using it. Avoid contact details copied from unrelated messages or social posts when you cannot connect them to the route you intentionally opened.
Why no email address or messaging handle is guessed
A made-up contact address is worse than no address because it can direct users to the wrong person and encourage disclosure of private information. This page therefore explains the contact decision without inventing a phone number, email address or chat handle.
For a problem with these information pages, use the website contact method only when one is visibly and verifiably provided. Until then, the Support page gives the safest route for classifying the issue.
Use the right page before reporting
| Cannot sign in | Use Login and complete the route and browser checks first. |
|---|---|
| Cannot finish registration | Use Register and note whether the problem is loading or validation. |
| App will not open | Use App and compare the browser route before reinstalling. |
| Installer or permission question | Use Download before opening or replacing the file. |
| Broken internal page or menu | Use Support and record the page name, device, browser and visible symptom. |
Next best action
If you are not sure what kind of issue you have, return to Support. If the issue is a common login, registration or mobile question, FAQ may answer it without any contact step.
Keep website reports reproducible
If a public page problem happens every time, describe the shortest sequence that reproduces it: open the page, tap the menu, choose a link, see the error. A reproducible sequence is more useful than a long narrative and does not require private account information.
If the issue happens only once, note that too. Intermittent failures can point to caching, a temporary connection problem or an external dependency rather than a permanent page defect.
Do not use contact as a shortcut around account security
A general website contact route should not be used to send credentials or ask someone to bypass an account check. If the service requires verification, use the verification route it supplies. Protecting the account is more important than resolving the issue quickly through an unverified contact.
Give support enough context to avoid repeated questions
A concise report can still be complete. Include the page or task, device, browser, time, exact non-sensitive symptom and the one or two troubleshooting comparisons you already tried. That gives support enough context without burying the issue in unrelated account history.