OpenRouter को क्रिप्टो भेजी लेकिन Credits कभी नहीं आए? वजह और अगला कदम

यह AI API billing में सबसे common और सबसे कम समझे जाने वाले failure में से एक है, और यह आपके wallet का bug नहीं है। यह एक structural mismatch है — crypto users जो सोचते हैं वे कर रहे हैं, और checkout के पीछे वाला payment processor असल में क्या accept करता है, इन दोनों के बीच। यह page वजह समझाता है, एक realistic recovery process देता है, और timeline को लेकर ईमानदार उम्मीदें सेट करता है।

10 अगस्त 2026 को verified। Payment processor का व्यवहार और supported chain की list बदलती रहती है, इसलिए भेजने से पहले live checkout page पर accepted network फिर से confirm करें।

छोटी सी बात

OpenRouter खुद crypto payments process नहीं करता। यह एक hosted crypto checkout — Coinbase Commerce — इस्तेमाल करता है, जो payment को तभी credit करता है जब आने वाला transfer उस specific invoice के लिए तय chain और token के exact combination से मैच करे।

सही token गलत chain पर भेज दें, या गलत token सही chain पर, तो पैसा एक असली address पर पहुंचता है जिसे एक असली processor control करता है, लेकिन system में कुछ भी उसे आपके invoice से जोड़ नहीं पाता। कोई error screen नहीं आती। Transaction succeed होता है। Invoice unpaid पड़ा रहता है जब तक expire नहीं हो जाता।

यही gap — एक successful on-chain transfer जो फिर भी एक unrecognised payment है — यही वह जगह है जहां लगभग हर ऐसा case फंसता है।

असल में क्या गड़बड़ होती है, frequency के हिसाब से

1. सही token, गलत network। सबसे common। USDC Ethereum, Base, Polygon, Solana, Arbitrum, Optimism, Avalanche और भी कई chains पर मौजूद है। ये अलग-अलग tokens हैं, अलग contract addresses के साथ, जिनका नाम और price बस मिलता-जुलता है। एक typical case: कोई user किसी बड़े exchange से USDC withdraw करता है, Polygon चुनता है क्योंकि withdrawal fee सबसे कम है, लगभग $15 भेजता है, और transfer सेकंडों में confirm हो जाता है। Invoice किसी और network का इंतज़ार कर रहा था। Funds processor के Polygon address पर पहुंच जाते हैं, जिसे invoice कभी देखता ही नहीं। कुछ भी credit नहीं होता, और कोई error भी नहीं आती। यह decision exchange के withdrawal screen पर होता है, और लगभग हमेशा fee के आधार पर होता है, invoice क्या मांग रहा था उसके आधार पर नहीं।
2. USDT जहां सिर्फ USDC accept होता है। Users USDT और USDC को interchangeable मानते हैं क्योंकि दोनों dollar को track करते हैं। Payment processors ऐसा नहीं मानते। USDC में denominated invoice USDT को accept नहीं करेगा, वही chain होने पर भी। हमने बार-बार यह pattern देखा है: Solana पर एक USDT transfer on-chain confirm हो जाता है, sender के पास valid signature और wallet में green checkmark होता है, और OpenRouter balance कभी हिलता ही नहीं। एक और: Polygon पर भेजी गई एक छोटी USDT amount, एक हफ्ते बाद भी uncredited, ticket पर अब तक कोई जवाब नहीं।
3. किसी aggregator या swap route से payment। Direct wallet transfer की बजाय किसी swap aggregator या DEX router से pay करने पर receiving address को असल में जो दिखता है वह बदल सकता है — sender address, token path, और कभी-कभी token खुद भी। एक user ने Solana aggregator के ज़रिए लगभग 15 USDC pay किए; swap execute हुआ, funds move हुए, और कोई credit नहीं आया। Invoice payments के लिए आपके अपने control वाले wallet से direct transfers कहीं ज़्यादा सुरक्षित हैं, किसी swap के through route किए गए किसी भी तरीके से।
4. Amount mismatch, overpayment समेत। Underpay करने पर invoice open रहता है, यह तो साफ है। लेकिन overpaying भी कुछ processor configurations पर automatic crediting को तोड़ सकती है, क्योंकि received amount expected amount से मैच नहीं करता और payment auto-settle होने की बजाय manual handling के लिए flag हो जाता है। Fees cover करने के लिए थोड़ा ज़्यादा भेजना उतना safe move नहीं है जितना लगता है।
5. Transfer confirm होने से पहले ही invoice expire हो गई। Hosted crypto invoices का एक time window होता है, आमतौर पर 15 से 60 मिनट। अगर आप invoice generate करके कुछ और काम करने चले जाएं और एक घंटे बाद भेजें — या अगर network congestion के दौरान भेजें — तो transfer window बंद होने के बाद पहुंच सकता है। Address अब भी असली है। बस invoice अब सुन नहीं रहा।

Step 1: पहले confirm करें कि आपने असल में क्या भेजा

किसी से contact करने से पहले पूरी जानकारी इकट्ठा करें। Support इनके बिना मदद नहीं कर सकता, और हो सकता है आपको खुद ही पांच मिनट में जवाब मिल जाए।

जिस chain का इस्तेमाल किया उसका block explorer खोलें और अपना transaction निकालें। यह नोट करें:

• Transaction hash — पूरा string, किसी truncated screenshot का नहीं।
• Network — असली chain, जैसे Polygon PoS, Solana mainnet, Base।
• Token contract address — यह वह field है जो USDC-बनाम-USDT का सवाल पक्के तौर पर सुलझाती है।
• Exact amount — पूरी decimal precision के साथ।
• Receiving address — जहां funds पहुंचे।
• Timestamp — UTC में।
• Sending address — जिस wallet से आपने pay किया।

फिर इसे invoice से compare करें: checkout page ने कौन सी chain और token मांगी थी, और invoice का expiry time क्या था? अगर आपके पास अब भी invoice page या email है, तो यह जानकारी उसमें है। इस स्टेज पर आमतौर पर आपको पता चल जाता है कि आप ऊपर बताए पांच कारणों में से किससे टकराए।

Step 2: जांचें कि funds कहीं पहले से दिख तो नहीं रहे

Escalate करने से पहले दो चीज़ें जांचने लायक हैं।

क्या checkout में payment pending या unresolved दिखा रहा है? Hosted crypto checkouts में अक्सर underpaid, overpaid, या delayed जैसी states होती हैं जिन्हें कोई इंसान resolve कर सकता है। अगर आपका payment वहां किसी भी रूप में दिखता है, तो आपका case काफी मजबूत है।

क्या payment processor से कोई email आई? Coinbase Commerce अपनी notifications OpenRouter से अलग खुद भेजता है। अपना inbox — spam भी शामिल करके — इस invoice के लिए search करें।

अगर funds किसी ऐसी chain पर पहुंचे जिसे invoice कभी देखता ही नहीं था, तो वे checkout में कहीं नहीं दिखेंगे। यह ज़्यादा मुश्किल case है, और ईमानदारी की मांग है कि यह साफ कहा जाए: किसी unsupported network पर processor के address को भेजे गए funds सिर्फ processor की मर्ज़ी पर recover हो सकते हैं। इन्हें वापस खींचने का कोई protocol-level mechanism नहीं है। कुछ processors उन्हें recover कर देते हैं; यह एक manual, धीमी, best-effort process है।

Step 3: Support से सही तरीके से contact करें

किसी ticket के resolve होने और एक हफ्ते तक पड़े रहने में अंतर लगभग पूरी तरह इस बात पर टिका है कि पहला message कैसे लिखा गया। एक छोटा message और फिर पांच clarifications भेजने की बजाय, सब कुछ एक ही message में भेजें।

इस क्रम में शामिल करें:

1. आपका OpenRouter account email।
2. समस्या बताने वाला एक वाक्य: on-chain transfer confirmed, credits apply नहीं हुए।
3. Invoice या payment link identifier।
4. Transaction hash, network, token contract address, exact amount, UTC में timestamp।
5. Transaction का block explorer URL।
6. आप क्या चाहते हैं: credits apply हों, या sending address पर refund।

जहां relevant हो, दोनों पक्षों से contact करें। Credit side OpenRouter support संभालता है; funds payment processor के पास होते हैं। अगर आपका transfer किसी ऐसे network पर गया जिसे invoice cover नहीं करता था, तो processor ही वह पक्ष है जो असल में पैसा locate कर सकता है।

हमने जो cases track किए हैं उनके आधार पर realistic timelines: वे straightforward cases जहां payment checkout में underpaid या delayed के रूप में दिखता है, आमतौर पर कुछ business days में resolve हो जाते हैं। Wrong-network और wrong-token cases अक्सर एक से तीन हफ्ते लेते हैं, और कुछ का जवाब ही नहीं आता। कई users ने इस category के ticket पर पूरे एक हफ्ते तक कोई पहला जवाब न मिलने की रिपोर्ट दी है। उसी हिसाब से plan करें — अगर production traffic उस balance पर depend करता है, तो ticket के भरोसे न बैठें। Account को किसी और तरीके से fund करें और अटके हुए transfer को एक अलग recovery effort मानें।

विनम्रता से escalate करना ज़ोर से escalate करने से बेहतर काम करता है। हर तीन-चार business days में अपने ही ticket पर एक-line का bump भेजें जिसमें transaction hash फिर से बताएं। Duplicate tickets न खोलें; ज़्यादातर helpdesk पर इससे आपकी queue position फिर से reset हो जाती है।

Step 4: अगली बार इससे बचें

तीन approaches, सबसे conservative से सबसे convenient तक।

Invoice जो chain और token बताए, ठीक वही इस्तेमाल करें, और कुछ नहीं। Wallet छूने से पहले checkout page पढ़ें। Confirm करें कि network का नाम आपके withdrawal screen से exactly मैच करता है — आपके exchange के dropdown में सिर्फ USDC लिखा होना काफी जानकारी नहीं है। Exact amount भेजें, गोल-मोल round-up किया हुआ नहीं। Invoice generate करने के तुरंत बाद भेजें, एक घंटे बाद नहीं।

ऐसे account से fund करें जो आपको network deliberately चुनने दे। अगर आपका सारा USDC किसी ऐसी chain पर है जो invoice नहीं लेता, तो invoice generate करने से पहले bridge करें, उसके दौरान नहीं। Invoice generate करके फिर 20 मिनट का bridge शुरू करना — इसी से expiries होती हैं।

या फिर ऐसा checkout इस्तेमाल करें जो वही accept करे जो आपके पास असल में है। यह problem इसी category में आती है: failure इसलिए होती है क्योंकि accepted-asset list संकरी है, इसलिए एक wider list इसे हटा देती है। checkout.rozo.ai पर ROZO Checkout यहां एक option है — आप अपना OpenRouter payment link paste करते हैं और USDT, Solana या Stellar या BNB Chain पर USDC, या Bitcoin Lightning के ज़रिए pay करते हैं, और यह आपकी तरफ से USDC में settle कर देता है। Wrong-network वाली failure class पैदा ही नहीं होती क्योंकि आपसे किसी एक specific chain से मैच करने के लिए नहीं कहा जाता।

यह इकलौता option नहीं है, और tradeoff बताना ज़रूरी है: आप merchant के processor को सीधे pay करने की बजाय एक third party के through route कर रहे हैं, और ROZO OpenRouter और Coinbase से independent है। कुछ लोग careful network selection के साथ direct path पसंद करेंगे, और यह बिल्कुल reasonable choice है। कुछ लोगों के पास पहले से USDT या sats हैं और कोई direct path है ही नहीं। इसी आधार पर चुनें।

जो भी route चुनें, durable habit एक ही है: sign करने से पहले network और token contract जांचें, सिर्फ ticker और number नहीं।