अपने AI एजेंट से USDC पेमेंट कैसे स्वीकार करवाएँ

Rozo की Agent Merchant API इस धारणा को हटा देती है। एक EVM EOA एक ही wallet सिग्नेचर से मर्चेंट के रूप में रजिस्टर हो सकता है; एक्सेस स्वीकृत होने के बाद, एक दूसरा, नया सिग्नेचर इनवॉइस जारी करने और पेमेंट स्टेटस पढ़ने के लिए केवल-Orders वाली API key अधिकृत करता है। रकम Base पर USDC के रूप में साइन करने वाले पते पर सेटल होती है, और एजेंट payout_completed आने तक API को पोल कर सकता है। यह गाइड पूरा लूप समझाती है।

एजेंट को असल में क्या मिलता है

• उसके wallet से जुड़ा एक मर्चेंट खाता: पहला वैध सिग्नेचर उसे बनाता है, दोहराए गए सिग्नेचर वही खाता दोबारा खोलते हैं — डुप्लिकेट कभी नहीं बनता।
• सेटलमेंट सर्वर की ओर से साइन करने वाले पते पर Base के USDC पर लॉक है। कोई भी API कॉल पैसे का रास्ता नहीं बदल सकती।
• केवल-Orders वाली API key: मौजूदा कॉन्ट्रैक्ट के तहत यह अपने खाते के लिए इनवॉइस बना सकती है और पेमेंट स्टेटस पढ़ सकती है। यह Admin क्रेडेंशियल जारी नहीं कर सकती, खाता सेटिंग नहीं संभाल सकती, और सेटलमेंट नहीं बदल सकती।
• हर इनवॉइस के लिए एक पेमेंट लिंक, जिसे एजेंट ग्राहक के साथ साझा करता है। इस alpha में EVM मर्चेंट के लिए सेटलमेंट Base पर USDC के रूप में मिलता है।

पाँच कदमों का लूप

1. Challenge माँगें: GET /account-nonce?chain=evm&address=$ADDRESS&intent=merchant_onboard. सर्वर साइन करने के लिए सटीक संदेश लौटाता है; बेनाम nonce अस्वीकार होते हैं।
2. लोकल साइन करके ऑनबोर्ड करें: POST /account-onboard में पता, सिग्नेचर और nonce भेजें। प्राइवेट की एजेंट के रनटाइम से कभी बाहर नहीं जाती।
3. एक्सेस माँगें और सीमित क्रेडेंशियल जारी करें: wallet सेशन से POST /account-credentials/request कॉल करें और स्टेटस जाँचने के लिए वही अनुरोध दिन में कुछ ही बार दोहराएँ। स्वीकृति मिलने पर नया credential_issue challenge साइन करें और scope "orders" के साथ POST /account-credentials कॉल करें। जारी क्रेडेंशियल Orders स्कोप का होता है; Orders क्रेडेंशियल Admin key नहीं बना सकते।
4. इनवॉइस बनाएँ: POST /payment-api में स्थिर orderId, Idempotency-Key, डिस्प्ले जानकारी और USDC राशि भेजें। destination न भेजें। नेटवर्क विफलता के बाद उसी orderId और idempotency key से दोबारा प्रयास करें।
5. पेमेंट स्टेटस पोल करें: Orders key और स्थिर orderId से payout_completed तक पोल करें। webhook या ईमेल डिलीवरी विफल हो जाए तो भी लौटाए गए पेमेंट स्टेटस को ही प्रामाणिक मानें। अगर जवाब में payout ट्रांज़ैक्शन hash हो, तो उसे Base पर अतिरिक्त रूप से सत्यापित कर सकते हैं।

मशीन-पठनीय पूरा कॉन्ट्रैक्ट https://partners.rozo.ai/llms.txt पर है — इसे सीधे एजेंट में पेस्ट करने के लिए ही लिखा गया है।

अनुमतियाँ जान-बूझकर सीमित क्यों हैं

किसी स्वायत्त एजेंट को पेमेंट क्रेडेंशियल देना ठीक वही जगह है जहाँ शक्की होना चाहिए। API इस तरह बनाई गई है कि लीक हुई एजेंट key का नुकसान-दायरा छोटा रहे:

• केवल-Orders keys दूसरी keys नहीं बना सकतीं, सेटलमेंट नहीं बदल सकतीं, और इनकी रीड सिर्फ़ अपने खाते तक सीमित है। wallet से जारी क्रेडेंशियल की सूची देखने और रद्द करने के लिए नया, उद्देश्य-बद्ध wallet सिग्नेचर चाहिए।
• क्रेडेंशियल जारी करने के लिए नया wallet सिग्नेचर ज़रूरी है — सिर्फ़ चुराए गए सेशन टोकन से key नहीं बनती।
• हर challenge एक बार इस्तेमाल होने वाला, तय उद्देश्य वाला और सर्वर द्वारा दी गई समय-सीमा वाला होता है।
• पेआउट पता साइन करने वाले पते के बराबर है और सर्वर इसे लागू करता है। लीक हुई Orders key कॉन्फ़िगर किया गया सेटलमेंट पता नहीं बदल सकती, पर अनचाहे इनवॉइस बना सकती है और पेमेंट स्टेटस उजागर कर सकती है — नए wallet प्रूफ़ से उसे तुरंत रद्द करें।

एक्सेस कैसे पाएँ (alpha)

alpha के दौरान क्रेडेंशियल प्रोग्राम इनवाइट-आधारित है। ऑनबोर्डिंग के बाद एजेंट POST /account-credentials/request कॉल करता है और स्टेटस जाँचने के लिए वही अनुरोध दिन में कुछ ही बार दोहराता है। स्वीकृति Rozo की ओर से एक इंसान का फ़ैसला है, पर ईमेल या डायरेक्ट मैसेज की ज़रूरत नहीं। मौजूदा क्रेडेंशियल-और-इनवॉइस लूप Base पर USDC सेटल करने वाले EVM EOA को सपोर्ट करता है। Solana और Stellar EOA ऑनबोर्ड होकर अपने-अपने साइनिंग पते की चेन पर USDC पा सकते हैं, पर वे इस क्रेडेंशियल लूप से बाहर हैं।

इस alpha में EVM कॉन्ट्रैक्ट wallet सपोर्टेड नहीं हैं, और केवल-wallet खातों के लिए कोई रिकवरी रास्ता नहीं है: साइनिंग key खो जाए तो Rozo मर्चेंट को बहाल नहीं कर सकता और न ही मैन्युअल स्वामित्व-हस्तांतरण करता है।

शुरुआत करें: https://partners.rozo.ai/agent