Udah Kirim Crypto ke OpenRouter Tapi Credits Nggak Masuk? Ini Sebabnya, dan Solusinya

Ini salah satu failure mode paling umum dan paling jarang dijelaskan dengan jelas di dunia AI API billing, dan ini bukan bug di wallet kamu. Ini mismatch struktural antara apa yang dikira pengguna crypto sedang mereka lakukan, dengan apa yang sebenarnya diterima oleh payment processor di balik checkout itu. Halaman ini menjelaskan penyebabnya, kasih kamu prosedur recovery yang realistis, dan kasih ekspektasi waktu yang jujur.

Diverifikasi 10 Agustus 2026. Perilaku payment processor dan daftar chain yang didukung bisa berubah, jadi cek dulu network yang diterima di halaman checkout live sebelum kirim apa pun.

Versi singkatnya

OpenRouter sendiri nggak memproses pembayaran crypto. Mereka pakai hosted crypto checkout — Coinbase Commerce — yang hanya mencatat pembayaran kalau transfer yang masuk cocok persis dengan kombinasi chain dan token yang memang di-set untuk invoice tersebut.

Kirim token yang benar di chain yang salah, atau token yang salah di chain yang benar, dan uangnya tetap sampai di alamat asli yang dikontrol processor beneran, tapi nggak ada apa pun di sistem yang menghubungkannya ke invoice kamu. Nggak ada error screen. Transaksinya sukses. Invoice-nya tetap unpaid sampai expired.

Celah itu — transfer on-chain yang sukses tapi tetap dianggap pembayaran yang tidak dikenali — adalah tempat hampir semua kasus seperti ini terjadi.

Apa yang sebenarnya salah, diurutkan dari yang paling sering

1. Token benar, network salah. Ini yang paling sering terjadi, jauh di atas yang lain. USDC ada di Ethereum, Base, Polygon, Solana, Arbitrum, Optimism, Avalanche, dan lainnya. Semuanya token berbeda dengan contract address berbeda yang kebetulan punya nama dan harga yang sama. Contoh khasnya: pengguna withdraw USDC dari exchange besar, pilih Polygon karena withdrawal fee-nya paling murah, kirim sekitar $15, dan transfer confirmed dalam hitungan detik. Padahal invoice-nya menunggu network yang berbeda. Dananya mendarat di alamat Polygon milik processor, yang nggak pernah diawasi oleh invoice itu. Nggak ada yang tercatat, dan nggak ada error. Keputusan ini diambil di halaman withdrawal exchange, dan hampir selalu berdasarkan fee, bukan berdasarkan apa yang diminta invoice.
2. Kirim USDT padahal cuma terima USDC. Pengguna menganggap USDT dan USDC bisa saling tukar karena sama-sama mengikuti harga dolar. Payment processor nggak berpikir begitu. Invoice yang denominasinya USDC nggak akan menerima USDT sekalipun di chain yang sama. Pola yang sering kami lihat: transfer USDT lewat Solana confirmed on-chain, pengirimnya punya signature valid dan centang hijau di wallet-nya, tapi saldo OpenRouter nggak bergerak sama sekali. Contoh lain: USDT jumlah kecil dikirim lewat Polygon, seminggu kemudian masih belum masuk, dan tiket support-nya juga belum dibalas.
3. Bayar lewat aggregator atau swap route. Bayar lewat swap aggregator atau DEX router, bukan transfer wallet langsung, bisa mengubah apa yang sebenarnya diterima di alamat tujuan — alamat pengirim, jalur token, dan kadang bahkan token itu sendiri berubah. Ada pengguna yang bayar sekitar 15 USDC lewat aggregator Solana; swap-nya jalan, dananya bergerak, tapi credits-nya nggak muncul sama sekali. Transfer langsung dari wallet yang kamu kontrol jauh lebih aman untuk bayar invoice dibanding apa pun yang lewat swap.
4. Jumlah nggak cocok, termasuk kelebihan bayar. Kurang bayar, invoice-nya jelas tetap terbuka. Tapi kelebihan bayar juga bisa merusak auto-crediting di beberapa konfigurasi processor, karena jumlah yang diterima nggak cocok dengan yang diharapkan, dan pembayarannya di-flag untuk ditangani manual, bukan auto-settled. Kirim sedikit lebih untuk nutup fee itu bukan langkah aman seperti yang terasa.
5. Invoice expired sebelum transfer confirmed. Invoice crypto hosted punya jendela waktu, biasanya 15 sampai 60 menit. Kalau kamu generate invoice, terus pergi ngerjain hal lain, lalu kirim satu jam kemudian — atau kirim pas network lagi macet — transfer-nya bisa mendarat setelah jendelanya tutup. Alamatnya masih valid. Invoice-nya aja yang sudah nggak dengerin lagi.

Langkah 1: Pastikan apa yang sebenarnya kamu kirim

Sebelum menghubungi siapa pun, kumpulkan fakta-faktanya dulu. Support nggak bisa bantu tanpa itu, dan kamu mungkin bisa nemuin jawabannya sendiri dalam lima menit.

Buka block explorer untuk chain yang kamu pakai dan tarik transaksi kamu. Catat:

• Transaction hash — string lengkapnya, bukan screenshot yang terpotong.
• Network — chain sebenarnya, misalnya Polygon PoS, Solana mainnet, Base.
• Token contract address — ini field yang bisa memastikan secara pasti apakah itu USDC atau USDT.
• Jumlah pastinya — sampai desimal penuh.
• Alamat penerima — ke mana dananya berakhir.
• Timestamp — dalam UTC.
• Alamat pengirim — wallet yang kamu pakai buat bayar.

Lalu bandingkan dengan invoice-nya: chain dan token apa yang diminta halaman checkout, dan kapan waktu expired invoice-nya? Kalau kamu masih punya halaman invoice atau emailnya, informasi ini ada di situ. Di titik ini kamu biasanya sudah tahu kamu kena penyebab yang mana dari lima yang ada.

Langkah 2: Cek apakah dananya sudah kelihatan di suatu tempat

Ada dua hal yang perlu dicek dulu sebelum eskalasi.

Apakah pembayarannya muncul sebagai pending atau unresolved di checkout? Hosted crypto checkout sering punya status underpaid, overpaid, atau delayed yang bisa diselesaikan manusia. Kalau pembayaran kamu muncul di situ, kasus kamu jauh lebih kuat.

Apakah kamu dapat email dari payment processor-nya? Coinbase Commerce mengirim notifikasi sendiri, terpisah dari OpenRouter. Cari di inbox kamu — termasuk folder spam — untuk invoice-nya.

Kalau dananya mendarat di chain yang nggak pernah diawasi invoice, dananya nggak akan muncul di mana pun dalam checkout. Ini kasus yang lebih susah, dan jujur harus dikatakan: dana yang dikirim di network yang nggak didukung ke alamat processor hanya bisa dikembalikan atas kebijakan processor sendiri. Nggak ada mekanisme di level protokol untuk menariknya kembali. Beberapa processor memang mengembalikannya; itu proses manual, lambat, dan best-effort.

Langkah 3: Hubungi support dengan benar

Perbedaan antara tiket yang selesai dan tiket yang mangkrak seminggu hampir sepenuhnya ada di cara pesan pertama ditulis. Kirim satu pesan yang berisi semua informasi, bukan pesan pendek diikuti lima kali klarifikasi.

Sertakan, urut seperti ini:

1. Email akun OpenRouter kamu.
2. Satu kalimat yang menyatakan masalahnya: transfer on-chain confirmed, credits belum masuk.
3. Identifier invoice atau payment link-nya.
4. Transaction hash, network, token contract address, jumlah pasti, timestamp dalam UTC.
5. URL block explorer ke transaksi tersebut.
6. Apa yang kamu mau: credits dimasukkan, atau refund ke alamat pengirim.

Hubungi kedua pihak kalau relevan. Support OpenRouter menangani sisi credits; payment processor yang pegang dananya. Kalau transfer kamu masuk ke network yang nggak dicover invoice, processor-lah pihak yang benar-benar bisa melacak uangnya.

Berdasarkan kasus-kasus yang pernah kami pantau, ekspektasi waktu yang realistis: kasus yang simpel di mana pembayarannya kelihatan di checkout sebagai underpaid atau delayed biasanya selesai dalam beberapa hari kerja. Kasus salah network dan salah token sering butuh satu sampai tiga minggu, dan ada yang nggak pernah dibalas sama sekali. Beberapa pengguna melaporkan seminggu penuh tanpa balasan pertama untuk kategori tiket ini. Rencanakan sesuai itu — kalau kamu punya production traffic yang bergantung pada saldo itu, jangan nunggu tiketnya. Isi akun lewat cara lain dan anggap transfer yang macet itu sebagai upaya recovery terpisah.

Eskalasi dengan sopan lebih efektif daripada eskalasi dengan keras. Balas di tiket kamu sendiri setiap tiga sampai empat hari kerja dengan satu baris singkat yang mengulang transaction hash. Jangan buka tiket duplikat; di kebanyakan helpdesk itu malah bikin posisi antrean kamu reset.

Langkah 4: Cara menghindarinya lain kali

Tiga pendekatan, dari yang paling konservatif sampai yang paling praktis.

Pakai persis chain dan token yang diminta invoice, jangan yang lain. Baca halaman checkout sebelum pegang wallet kamu. Pastikan nama network cocok persis dengan halaman withdrawal kamu — tulisan USDC di dropdown exchange kamu saja nggak cukup. Kirim jumlah yang pas, jangan dibulatkan ke atas. Kirim segera setelah generate invoice, jangan tunggu satu jam.

Dana dari akun yang bisa memilih network secara sengaja. Kalau USDC kamu cuma ada di chain yang nggak diterima invoice, bridge dulu sebelum generate invoice, jangan di tengah proses. Generate invoice lalu mulai bridge 20 menit adalah cara paling umum bikin invoice expired.

Atau pakai checkout yang menerima aset yang kamu pegang beneran. Ini kategori masalah yang sedang dibahas: penyebabnya adalah daftar aset yang diterima terlalu sempit, jadi daftar yang lebih luas menghilangkan masalahnya. ROZO Checkout di checkout.rozo.ai adalah salah satu opsi di sini — kamu paste payment link OpenRouter kamu dan bayar pakai USDT, USDC di Solana atau Stellar atau BNB Chain, atau Bitcoin lewat Lightning, dan sistemnya settle ke USDC atas nama kamu. Kegagalan kelas salah-network ini nggak akan terjadi karena kamu nggak diminta untuk mencocokkan satu chain spesifik.

Ini bukan satu-satunya opsi, dan trade-off-nya perlu dinyatakan dengan jelas: kamu jadi lewat pihak ketiga, bukan langsung ke processor merchant, dan ROZO independen dari OpenRouter dan Coinbase. Beberapa orang lebih suka jalur langsung dengan pemilihan network yang hati-hati, dan itu pilihan yang masuk akal. Yang lain sudah punya USDT atau sats dan nggak punya jalur langsung sama sekali. Pilih berdasarkan itu.

Apa pun rute yang kamu pilih, kebiasaan yang tahan lama tetap sama: sebelum sign, cek network dan token contract-nya, bukan cuma ticker dan angkanya.