Peer-to-Peer Session · 20 min

Account Recovery: Approving Cases

A complete guide to criteria, documentation, and decision-making for approving Account Recovery requests after identity and ownership are verified.

01 · Overview

What Account Recovery is (and isn't)

Account Recovery (AR) is the process of verifying that a customer is the legitimate owner of a Hostinger account when they have lost access to it. Our job is to protect both the customer and Hostinger by ensuring only the real owner regains access.

Three valid AR situations

🔑 Lost 2FA

Customer lost access to their authenticator app (phone reset, app deleted).

📧 Lost email access

Can't access the email linked to their Hostinger account (expired domain, hacked, etc.).

❓ Forgot email

Doesn't remember which email they used to register.

NOT Account Recovery: if the customer still has access to their email or 2FA app — they should self-recover. Don't open an AR case. Guide them to auth.hostinger.com → Forgot Password, social login, or incognito tab.
Key principle: Payment proof is the primary verification method. Government ID is supplementary — it alone is never enough to approve a case.
02 · Foundation

The 3 approval pillars

Every account recovery must satisfy three checks: identity + ownership + valid recovery email.

💳 Payment proof

From bank statement or payment app. Must show date, amount, destination. Beneficiary details required for full bank statements. Never from Hostinger invoices or emails.

🪪 Identity document

Government-issued ID, passport, or business registration — used when no payment proof, for empty accounts, or high-risk cases. Must match account name. AI-generated = immediate decline.

📧 Valid recovery email

Must not be on the blocked list and must not already be registered in Hostinger.

How many payment proofs to request

1
1 payment on account → ask for 1 proof
2
2+ payments → ask for 2 proofs
From different dates or services.
3
Developer account or 3+ services → ask for more than 2 proofs
4
Payments older than 3 years → government-issued ID matching account name is acceptable instead
03 · Documents

Accepted vs never accepted

Know exactly what to accept and what to reject on sight.

✅ Accepted

  • 🏦 Bank statement / banking app screenshot showing date, amount, destination (Hostinger)
  • 💳 Card photo — first 6 + last 4 digits visible, rest covered
  • 🅿️ PayPal dashboard screenshot with transaction ID, merchant name, order ID
  • 🪙 Crypto: Coingate payment URL or transaction hash
  • 🪪 Government-issued ID (passport, national ID) — supplementary only
  • 🏢 Business registration document — supplementary only
  • 🧾 Utility bill (within 3 months) with name & address visible

❌ Never accepted

  • 📧 Email screenshots (including Hostinger emails)
  • 📋 Hostinger invoices from hPanel
  • 📱 SMS screenshots
  • 🖥️ hPanel dashboard screenshots
  • 💳 Virtual card images (unless with full bank statement)
  • 🔗 Third-party service proof (e.g., Hostgator receipts)
  • 🏦 Bank statements without beneficiary details visible
🤖 AI-generated payment proof or government ID = immediate decline. No matter what else they provide. Reason: "Multiple invalid proofs provided." Do not give additional chances.
📐 Technical requirements: File formats JPG/PNG/PDF only · max 2 MB per file, 8 MB total · documents must be clear and legible · sensitive info not needed for verification should be redacted.

Blocked recovery email domains

@QQ.COM @PM.ME @PROTONMAIL.COM @PROTON.ME @PROTON.COM @163.COM @139.COM @126.COM Any email already in Hostinger
04 · Documentation

Payment proof by gateway

Always identify the payment method first before requesting proof. Each gateway has specific requirements — check CRM Receipts to identify how they paid.

💳 Stripe / Checkout / Dlocal (CC)

Bank statement showing date, amount, destination. Alternative: card photo showing first 6 + last 4 digits. Payments up to 3 years old accepted.

🅿️ PayPal

PayPal dashboard screenshot. Must include: transaction ID, merchant ID, order ID. Formats: hb_XXXX, hh_XXXX, H_XXXXX.

🪙 Coingate (crypto)

Proof from app + payment link (Orders tab in CRM). If no payment link → transaction hash.

🇧🇷 PIX / Boleto (Brazil)

Payment proof + government-issued document showing CPF (individual) or CNPJ (company).

🇮🇳 Razorpay / PayTM

App proof showing UPI or UTR code. Alternative: bank statement showing *RAZ* at start. Must show Payment ID (pay_XXXXX) or Order ID (order_XXXXXXX).

🇮🇩 Virtual Account · Netbanking · JazzCash

VA & JazzCash: proof directly from the app. Netbanking: bank statement.

🔍 How to verify in CRM: Go to CRM → Receipts. Match: Total (amount), Paid at (date — may differ by up to 3 days due to timezone), and Credit card last 4 digits if applicable. If currency differs, check IP log and currency value.
Bank statement rule: Beneficiary details must be visible to match with CRM account/WHOIS. Statement without beneficiary info = not acceptable. Card payments may show up to 3-day delay vs Hostinger invoice — normal. Always check customer timezone.
05 · Situation guide

Approval criteria by situation

Each situation has a specific set of required documents. Match the customer's case to the right row.

Situation Primary proof Alternative / supplementary Outcome if approved
🔑 Lost 2FA
Phone reset / app deleted		 Payment proof matching date, amount & destination If no payment proof: Government ID or Business Registration matching account name 2FA removed; customer regains access
📧 Lost email access
Expired domain, hacked, mistyped		 Payment proof (single = sufficient; 2+ payments = 2 proofs) New email must NOT already exist in CRM Account email changed; customer resets password
❓ Forgot email Payment proof Reverse search in CRM (domain, invoice ID) Account email revealed / changed
🏦 Bank closed
Can't provide payment proof		 Proof of bank closure + Bank closure doc OR Gov ID + selfie holding it (if name matches) OR Business registration Case-by-case; AR team reviews
🏢 Business account
Account under company name		 Payment proof + Business registration document Access restored to verified representative
🏢 Business closed Proof of business closure / liquidation + Bank closure document AR team reviews; escalate if needed
⚠️ Developer dispute: If a customer wants access because their developer is unreachable — do NOT proceed with AR. Direct them to local authorities. This is not an AR case.
06 · Deep dive

Special situations requiring extra care

Higher-complexity situations with specific document requirements and handling procedures.

👤 Hacked email / hacked Hostinger account

1
Check IP logs and Profile History first
Look for suspicious logins and account changes. Do not use "Recent IP login" predefine if suspicious IP is found.
2
Ask for payment proof; if suspicious → additionally ask for card (first 6 + last 4)
No card used → consult AR specialists — may need government-issued ID instead.
3
If everything valid → recover and change email

👨‍💻 Developer / third-party disputes

Confirm it is a developer account: multiple unrelated sites = developer; one related site = personal. Cannot proceed with payment proof for a confirmed developer account. Exception: ID + selfie + proof of authorization + business registration all matching domain registrant → can transfer domains only (not full account access).

📭 Empty accounts

Check for shared access to another account → ask for payment proof for that account. No proof possible → ask for government-issued ID if account has a verifiable name. No verifiable data at all → ask to create a new account.

🌐 Domain recovery (stolen domain)

Selfie with government-issued ID/passport required. Business registration if applicable. Direct to compliance@hostinger.com. Do not handle as standard AR.

🕊️ Deceased developer / account owner

Full access requires all of: Death certificate (official civil registration) · Proof of work with deceased (signed agreement) · Government-issued ID · Proof of authorization · Business registration.

If unable to provide all → may still transfer domains only if contact info matches: ID + selfie + proof of authorization + business registration.

When unclear → ping the AR team on Slack.

📅 Custom domain email — domain expired

Same logic as mistyped email. If domain and email are on Hostinger → same payment proof quantity rules. Amount + date + destination match → proceed.

07 · 2FA rules

2FA removal — 3 types, 3 different flows

The action after approval depends on which 2FA type the customer has.

📧 Email 2FA

Disable immediately once Account Recovery with email change is approved.

🔵 Google Authenticator app 2FA

Also disable immediately — Google 2FA apps are tied to the Gmail address, so a verified email change already confirms identity.

📱 Mobile 2FA (non-Google)

Must be requested through the Account Recovery form separately. Cannot be removed directly in the same approval flow.

No 2FA on the account? Do not process as Account Recovery. Ask the customer to: contact support@hostinger.com, try social login (Google/Facebook), or try an incognito tab. Lost email access → submit "Lost Access To Email" request instead.
08 · Process

The 6-step decision flow

How to process every AR case, in order. Skipping a step is what causes most escalations.

1
Validate the request type
Confirm this is a genuine AR case. Does the customer have access to their email or 2FA app? If YES → not an AR case, guide them to self-recover. Check CRM for 2FA type (email vs. app).
2
Check for previously submitted documents
⚠️ Always check CRM first! Has the customer already submitted valid documents? Don't ask for documents they've already provided — this delays resolution and frustrates customers.
3
Identify payment method & request correct proof
Check CRM Receipts to identify how they paid. Request the appropriate proof based on the gateway. Snooze the ticket — AR reviews within 2 business days.
4
Verify the submitted proof
Match: date ✓, amount ✓, destination (Hostinger) ✓. Minor timezone/currency differences are acceptable — check IP log. If proof is shared in chat, compare against CRM Receipts fields: Total, Paid at, last 4 digits.
5
Make the decision
Proof matches → Approve. Doesn't match → Request correct proof (max 2 attempts). Suspicious → Escalate to AR team before requesting critical documents. AI-generated → Decline immediately.
6
Post-approval actions
Lost 2FA: remove 2FA, customer regains access. Lost Email: customer receives approval email → goes to auth.hostinger.com → Forgot Password → resets with new email. Document the outcome in CRM.

🌳 Quick decision tree

Is payment proof provided?
├─ YES → Does it match CRM (date, amount, destination)?
│   ├─ YES → ✅ APPROVE
│   └─ NO → Is it the 2nd invalid attempt?
│      ├─ YES → ❌ DECLINE
│      └─ NO → 🔄 Request again
└─ NO → Is there a valid alternative (bank closed, 2+ years inactive, etc.)?
    ├─ YES → ⬆️ ESCALATE to AR
    └─ NO → ❌ DECLINE
09 · Exceptions & declines

Workarounds & when to decline / escalate

When payment proof isn't available, only two documented workarounds exist. All other cases still require payment proof.

Workarounds apply only to these specific documented scenarios. If the situation does not match either scenario exactly, payment proof is still required. Do not create new workarounds.

📋 Scenario 1 — Low-risk user

All 4 must apply:

  • ✓ Genuine mistype or minor email issue
  • ✓ IP or UID match between request and account
  • ✓ Fewer than 3 services on the account
  • ✓ Account shows emails have "bounced"

Accepted instead:

  • 📄 Government-issued ID or business registration + selfie
  • 💳 Card photo showing first 6 and last 4 digits only

⏳ Scenario 2 — No logins for ~2 years or more

Must apply:

  • ✓ Long-inactive account. Not related to death dispute or developer dispute.

Accepted instead:

  • 📄 Government-issued ID or business registration + selfie
  • 💳 Card showing first 6 and last 4 digits
  • 🏠 (Only if above docs match AND account has address info) Proof of address — utility bill max 3 months old

When to decline — clear rules for saying NO

🤖 AI-generated proof

Any AI-generated document (payment proof or ID). Decline immediately. Reason: "Multiple invalid proofs provided."

🔁 Two invalid attempts

Customer submitted unrelated evidence twice (emails, Hostinger invoices, third-party receipts). Decline with same reason.

👤 Not Account Recovery

Request is actually about website login, unrelated issue, or customer has access to email/2FA.

📵 No 2FA set up

Account has no 2FA configured (OTP was sent via email, not app). Not a valid AR case.

📬 Account already exists

Account is already under the requested email address.

👻 User not found

The provided email has no Hostinger account in CRM.

📋 Duplicate request

A duplicate AR request exists. Keep one active, decline the other.

💤 Inactivity (14 days)

Customer didn't respond within 14 days. Auto-declined. They must submit a new request.

⬆️ When to escalate instead of decline: If a case looks suspicious but you're not sure, check with the AR team first before requesting critical documents (ID/business registration). Don't make the call alone on edge cases. Create a support ticket with a full case summary.
10 · Case studies

Real cases from the team

Actual Slack discussions from #abuse-fraud-team and #brand-reputation-internal. Each case ends with a key lesson.

✅ Approved

Case 1: Payment proof matches, but bank holder name differs

Situation

Customer lost access to email (custom domain expired). Payment proof matched the last transaction in CRM. However, the bank holder name on the ID didn't match the account name — only the bank holder matched.

Discussion (Gusti, Karolina, Rokas — July 22, 2026)

Gusti initially thought single payment proof was sufficient per IW. Karolina flagged: "The bank statement is from another person's name — I'd ask for company docs to be safe." Rokas confirmed: "Ask for business registration since we're verifying account ownership, not just the bank. Alternative: card photo if not a business."

💡 Payment proof matching CRM is the primary requirement. But if the name on the proof doesn't match the account, request business registration or card photo to confirm ownership — not just the bank holder's identity.
📎 #brand-reputation-internal thread, July 22, 2026
✅ Approved

Case 2: Payment matches CRM — approved despite incomplete other docs

Situation

Customer contacted via social media. Payment proof matched the last transaction in CRM. However, none of the other documents (ID, business registration) matched CRM info — only the bank holder matched the ID.

Discussion (Gusti, AR Team — July 24, 2026)

Gusti asked: "In this case, they must upload the ID and no other alternatives?" AR team responded: "Approved."

💡 When payment proof clearly matches CRM (date, amount, destination), that is sufficient for approval — even if supplementary documents are incomplete. Payment proof is the primary verification method.
📎 #abuse-fraud-team thread, July 24, 2026
❌ Declined

Case 3: Declined due to inactivity + two invalid proofs

Situation

Customer had been trying to recover their account for almost a year. Investigation revealed: Payment proof matched CRM ✅ / Card photo did NOT match CRM details ❌ / Customer had submitted a Hostgator receipt (wrong company!) ❌.

Discussion (Marina, Fiona — July 21, 2026)

Fiona's analysis: "Two invalid proofs were provided previously (card mismatch + Hostgator receipt). Additional proof was requested, but the case was auto-declined for inactivity."

Recommendation

Open a new AR request. Customer must provide: (1) most recent payment proof, (2) correct card photo with first 6 + last 4 digits visible.

💡 Always verify all submitted documents carefully. A matching payment proof doesn't override a mismatched card photo. Two invalid proofs = decline. Inactivity = auto-decline after 14 days.
📎 #abuse-fraud-team thread, July 21, 2026
📚 Learning

Case 4: Always check previously submitted documents first!

Situation

A KYC suspension case. The specialist requested additional documents from the customer — but the customer had already submitted a valid ID on July 1st. This caused unnecessary delays.

Feedback (Ana Pinto → Team, July 24, 2026)

"For future cases, please always check for previously submitted documents before requesting new ones — it saves time for both the customer and the team." Additional context: The previous suspension was a false positive — the account had no suspicious websites and no fraudulent relations.

💡 Step 2 of the flow is critical: Always check CRM for previously submitted documents before requesting anything. Also review the full account history — a high risk score alone doesn't confirm fraud.
📎 #abuse-fraud-team thread, July 24, 2026
❌ Declined

Case 5: Suspicious sites + high risk score — business docs required

Situation

Customer submitted ID and selfie holding ID. However, the websites hosted on the account were suspicious (potential gambling/phishing sites). Risk score: 89%.

Decision (Fiona, July 21, 2026)

"I will still need business registration proof for each website in order to unsuspend. The statement 'I use your hosting service and the domains belong to my clients' is not sufficient."

💡 When an account has suspicious websites AND a high risk score, ID alone is not enough. Business registration for each website is required. Customer's verbal explanation is insufficient — documentation must be provided.
📎 #abuse-fraud-team, July 21, 2026
11 · Practice

Pre-approval checklist & knowledge check

Use this checklist before every approval decision, then test your understanding with the quiz below.

☑️ Pre-approval checklist

  • Confirmed this is a genuine AR case (customer cannot access email or 2FA app)
  • Checked CRM for previously submitted documents — no need to re-request
  • Identified the payment method used (check CRM Receipts)
  • Requested the correct proof type for that payment gateway
  • Verified: payment amount matches CRM "Total"
  • Verified: payment date matches CRM "Paid at" (±3 days for timezone)
  • Verified: destination is Hostinger (not another company)
  • Confirmed document is NOT AI-generated
  • Confirmed document is NOT a Hostinger invoice, email, or hPanel screenshot
  • If name mismatch: requested business registration or card photo
  • If suspicious: escalated to AR team before requesting critical documents
  • Documented outcome in CRM

🧠 Knowledge check

Pick an answer for each question — feedback appears immediately.

0 / 4 answered
Q1. A customer submits a Hostinger invoice from their hPanel as payment proof. What do you do?
Q2. A customer's payment proof matches CRM perfectly (date, amount, destination). However, their government ID doesn't match the account name. Should you approve?
Q3. A customer submits payment proof twice, but both times it's their email confirmation from Hostinger. What's the correct action?
Q4. Before requesting documents from a customer, what should you ALWAYS check first?

🎯 Key takeaways

✅ DO

  • Treat payment proof as the primary verification
  • Check CRM for previously submitted docs first
  • Match date + amount + destination — with timezone tolerance
  • Escalate suspicious cases before requesting critical docs
  • Follow the 6-step decision flow every time
  • Document the outcome in CRM

❌ DON'T

  • Accept Hostinger invoices, emails, or SMS as proof
  • Give AI-generated documents a second chance — decline immediately
  • Approve based on ID alone when name doesn't match the account
  • Ask for docs the customer already provided
  • Create new workarounds — only 2 documented exceptions exist
  • Process a case as AR if the customer still has email/2FA access
When in doubt: suspicious requests → AR team · deceased disputes + unclear cases → ping AR team on Slack · domain recovery → compliance@hostinger.com.