--- name: growvib-x402 description: Buy social media growth on GrowVib (Instagram, TikTok, YouTube, Telegram, X and more) with no GrowVib account, API key or deposit, paying in USDC on Base or Solana over the x402 payment protocol from an x402-compatible wallet. Use when a user wants followers, members, views, likes or engagement and the agent has a wallet but no connected GrowVib account. --- # Buy on GrowVib with x402 (no account) GrowVib decides WHAT to buy through its catalog and recommendation engine; x402 is only HOW an agent without an account pays. Protocol x402 version 2, USDC on Base or Solana (the 402 lists the networks currently offered, Base first), endpoint `POST https://api.growvib.com/v1/agent/orders`, or the `create_paid_order` tool on `https://api.growvib.com/mcp-public` (same handshake, the 402 document travels in the tool result). Full reference with wire examples: https://growvib.com/x402. ## When to use this The user has not connected a GrowVib account and the agent controls an x402-compatible wallet holding USDC on Base or Solana. Do not send the user to create an account, an API key or a deposit when this path can complete the purchase. If the agent has a connected account instead, use the growvib-ordering skill's account flow. ## The flow 1. search_catalog or recommend_service on https://api.growvib.com/mcp-public (or GET https://api.growvib.com/v1/services) to pick the service and option 2. get_quote for the exact price; its payment_methods.x402 block confirms the order is payable with no account 3. POST https://api.growvib.com/v1/agent/orders with {service_id, quantity, link} and no payment header (or call create_paid_order on https://api.growvib.com/mcp-public without a payment argument) 4. receive HTTP 402 with the PAYMENT-REQUIRED header (base64 JSON, the same document in the body): one accepts entry per network (Base first, then Solana when it is offered), each with the exact amount in USDC atomic units, asset, recipient and network, plus the EIP-712 domain (Base) or the facilitator's feePayer (Solana) in extra 5. pick the entry your wallet is on and sign: on Base an EIP-3009 transferWithAuthorization for exactly those requirements; on Solana a USDC transfer of exactly that amount to payTo with extra.feePayer as the transaction fee payer, signed by the paying wallet only and sent base64-encoded as payload.transaction 6. send the identical request again with the signed payload base64-encoded in PAYMENT-SIGNATURE (copy the 402's `extensions` into the payload, as x402 v2 requires) 7. receive 201 with the order (order_id, tracking_code, status, charged_usd, balance_usd, agent_token) and a PAYMENT-RESPONSE header carrying the transaction hash 8. track it: GET https://api.growvib.com/v1/agent/orders/{order_id} with Authorization: Bearer , or get_paid_order_status on the public MCP endpoint 9. spend any remaining balance on the next order with the same bearer token plus an idempotency_key and no payment (nothing on chain); a wallet that comes back later signs in at POST /v1/agent/auth/challenge with ERC-4361 (EVM) or Sign-In With Solana (chain: solana) ## Rules that keep the user's money safe - The amount is the server's, never yours: the 402 names it, computed from service, option and quantity. Sign for exactly that figure. A payment that differs is refused before anything moves. - Ask for the user's authorization before signing when your environment requires payment confirmation. State the total in USD and the destination the 402 names. - Copy the 402's `extensions` into the payment payload (x402 v2 requires it; it is how the resource is indexed for discovery). It is not part of what you sign. The answer's `EXTENSION-RESPONSES` header (base64 JSON, `bazaar.status`) says whether the copy was accepted. - Retry the SAME signed payload after a timeout; never sign a second one for the same order. The nonce is single-use, so a retry returns the first outcome and settles nothing further. - Read the status, not the message. `201`: order created. `200 credited_no_order`: paid, order not created, funds in your balance, place it with the token. `202 settlement_unresolved`: being confirmed, do NOT pay again, check back with the same payload. `409 duplicate_order`: an order for that link is already live, no payment taken. `402` after paying: the payment was refused before any money moved, and `error` says why; request a fresh quote and sign again. - Keep the `agent_token` an order returns. It spends the remaining balance and reads the order (bearer, one hour, refreshed on every order). A balance order needs an `idempotency_key`; reuse it on retries, and never reuse it for a different order (409). - A cheap order still pays the minimum settlement; the remainder is balance, not a loss. Many small orders: settle once, order from balance. - Never compute a price yourself, and never guess a `link`: use the exact profile, post, channel or video URL the user gave. ## Errors REST errors are `{"error", "code", "details"?, "reason"?}`; branch on `code`. Over MCP a failed call returns an error result with the same text. 401 on the tracking read means the token is gone: sign in with the wallet (ERC-4361, or Sign-In With Solana) or use the token from a new order. ## Human pages https://growvib.com/x402 (the x402 reference), https://growvib.com/mcp (the MCP server), https://growvib.com/auth.md (every access level), https://growvib.com/llms.txt (site guide).