Give Your AI a $5 Budget: Compare, Buy, and Track SMM Services

An AI assistant can help you compare services. With the right tools, it can also prepare a purchase, ask for approval, pay, and check the order afterward.

That’s a workflow you can build with GrowVib’s x402 integration. This guide uses a small example budget of 5 USDC and explains how the pieces fit together, including what your application needs to enforce on its own.

Imagine asking:

Find a suitable service for this URL and quantity. Explain the options, keep the settlement within 5 USDC, and ask before buying. After approval, track the order.

The goal is to spend less time browsing catalogs and checking delivery manually. You can explore services and request quotes before connecting payment.

How the pieces fit together

MCP gives the assistant tools for finding services and requesting quotes. x402 adds a payment step to an HTTP request. Your wallet signs the payment, and GrowVib uses PayAI as its facilitator to verify and settle it.

You do not need to run a facilitator to buy from GrowVib. The facilitator connection is handled on GrowVib’s side. Your buyer application needs a compatible x402 client and wallet signer.

What you need

This guide focuses on Base. The 5 USDC budget covers service payments, while model usage, subscriptions, and wallet funding costs are separate.

Use a target you control and a service you understand. Check the destination platform’s rules before ordering. Automating a purchase does not guarantee genuine audience interest, organic reach, or sales.

1. Compare services without paying

Connect your compatible MCP client to:

https://api.growvib.com/mcp-public

Follow your client’s remote-MCP setup instructions. The GrowVib x402 documentation also links to the HTTP API.

Try this prompt:

Help me compare GrowVib services without buying anything.

Platform: [platform]
Service type: [specific service]
Target URL: [a target I control]
Quantity: [quantity]
Audience requirements: [requirements or no preference]
Maximum wallet settlement: 5 USDC

Use the current tool schemas and actual catalog data.
Show up to three suitable options, with exact prices and
documented differences. Tell me if nothing matches.

Do not submit a paid request or sign any payment.

Use search_catalog or recommend_service, then get_quote. Let the assistant read the current schemas instead of guessing arguments.

Check that the proposal identifies the service, target, quantity, conditions, and price before continuing.

2. Inspect an HTTP 402 response

This is an unpaid order request. Replace the placeholders with valid values from the selected service:

curl -i -X POST https://api.growvib.com/v1/agent/orders \
  -H 'Content-Type: application/json' \
  -d '{
    "service_id": "<selected-service-id>",
    "quantity": 1000,
    "link": "<authorized-target-url>"
  }'

The quantity is illustrative and must satisfy the service’s limits. A valid payable request without payment returns a 402 challenge. Invalid inputs may return a validation error instead.

Inspect the amount, asset, network, recipient, and expiration window. Use ordinary HTTP for this preview. A payment-enabled wrapper may automatically pay when it receives a challenge.

3. Set up the buyer client

You need two things: an x402 client that speaks version 2 of the protocol, and a wallet signer it can use.

You do not need anything from PayAI. In this flow, the buyer does not contact the facilitator. Your client signs a payment and sends it to GrowVib, GrowVib calls its facilitator to verify and settle, and the outcome comes back in GrowVib's response. The facilitator is a server-side detail of the merchant's setup, so facilitator installation guides are not buyer setup.

Version 2 is not optional here. GrowVib puts the payment terms in a PAYMENT-REQUIRED header and expects the signed payload in PAYMENT-SIGNATURE. A version 1 client sends X-PAYMENT instead, and that request is rejected with a validation error rather than quietly downgraded. If you are evaluating a library, check which header it sends before anything else.

Set it up in this order:

Keep the wallet key and any bearer token GrowVib returns out of chat transcripts, source control, and logs.

4. Make the $5 limit real

"Never spend more than $5" states your intent. The application has to enforce it before it signs anything.

Track wallet settlements and account balance separately.

Wallet settlements. USDC that has left your wallet. The 5 USDC cap applies to this total. Keep it across requests and application restarts.

Account balance. Money that has already settled and now sits with GrowVib under your wallet address. Spending it debits your GrowVib balance without a new on-chain settlement. Balance purchases still need approval for the exact order.

The second number exists because GrowVib sets a $1 minimum settlement while orders are priced at whatever the catalog says. For example, an order costing $0.40 still settles $1, and the remaining $0.60 stays as account balance. Treat every order as a fresh settlement and you will pay the $1 floor over and over while stranding the remainders.

Spending that balance is a different request, with no signature and nothing on chain. A successful order response returns an agent_token. Send it back as a bearer token with an idempotency_key and no payment payload:

curl -X POST https://api.growvib.com/v1/agent/orders \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer <agent-token>' \
  -d '{
    "service_id": "<selected-service-id>",
    "quantity": 1000,
    "link": "<authorized-target-url>",
    "idempotency_key": "<your-unique-key>"
  }'

The idempotency_key is required on this path and is not decorative. A paying request gets its retry protection from the signed authorization, which can only be used once. A balance order has no equivalent, so the key is what stops a timeout and a retry from placing two orders and debiting twice. Generate one per intended purchase and reuse it on retries of that purchase.

If the balance does not cover the order, this request returns an ordinary 402 challenge. Handle that as a new payment decision: inspect the requested settlement, check the remaining budget, and obtain approval before signing.

The budget check for the settling path:

// Illustrative application logic, not x402 SDK code.
// USDC has six decimal places.
const budget = 5_000_000n;

function assertWithinBudget(
  settled: bigint,
  reserved: bigint,
  requested: bigint,
) {
  if (requested <= 0n) {
    throw new Error("Invalid payment amount");
  }

  if (settled + reserved + requested > budget) {
    throw new Error("Not enough budget remaining");
  }
}

Persist the budget and reserve atomically before signing. Otherwise two concurrent requests can pass the same check and overspend together.

Two more rules for the approval itself.

Bind approval to the exact terms: service, target, quantity, network, asset, recipient, and amount. If any of them changes, ask again. Restrict payments to the intended API host.

Watch the clock. The payment terms carry an expiry, five minutes by default. A manual approval step is exactly the thing that outlives it. Get approval first, then request fresh payment terms. Compare them with the approved service, target, quantity, network, asset, recipient, and amount. If those details still match, sign within the new validity window. If they changed, ask again.

5. Approve one purchase

Keep the confirmation easy to review:

Service: [selected service]
Target: [approved URL]
Quantity: [approved quantity]

Order charge: [quoted amount]
Available GrowVib balance: [current amount]
Payment route: [account balance or new wallet settlement]
Wallet settlement: [required amount, or zero for a balance order]
Remaining settlement budget: [remaining amount]

For a new settlement:
Network: [network from live payment terms]
Asset: [asset from live payment terms]
Recipient: [recipient from live payment terms]

Approve this exact purchase?

These are placeholders for live values. For a balance order, submit the bearer token and the purchase’s idempotency key without a payment signature. For a new settlement, fetch fresh payment terms after approval, check that the approved details still match, and only then sign.

Keep approval manual for the first version. You can learn the protocol without starting with unattended spending.

6. Track delivery after payment

Here is an illustrative successful order response for the $0.40 example:

{
  "order_id": "...",
  "tracking_code": "...",
  "status": "PENDING",
  "charged_usd": 0.40,
  "balance_usd": 0.60,
  "payment_id": "...",
  "agent_token": "..."
}

charged_usd is what the order cost. balance_usd is what the settlement left over, spendable without paying again. Store both, plus order_id and agent_token.

Read delivery status with the order id and the token:

curl 'https://api.growvib.com/v1/agent/orders/<order-id>' \
  -H 'Authorization: Bearer <agent-token>'

This read accepts the bearer token as its credential; a payment signature does not replace it. Without one you get a 401, and another account's order is a 404. GET /v1/agent/orders returns a page of your orders, newest first, with optional status, page, and page_size, which is how you recover after losing an order id. Both reads are safe to poll. Respect any Retry-After response and back off on rate limits. The endpoint is rate limited to 20 requests per minute per IP, so poll on a sane interval rather than in a loop.

The token expires after an hour. It is refreshed on every order, so an application that places orders within that window and saves the returned token can keep its credentials current, but a digest checking in tomorrow gets a 401. When that happens, sign in with the wallet instead of paying again:

curl -X POST https://api.growvib.com/v1/agent/auth/challenge \
  -H 'Content-Type: application/json' \
  -d '{"address": "<your-wallet-address>"}'

That returns a nonce and a message. For the Base wallet used here, sign the message bytes unchanged with personal_sign, then exchange them:

curl -X POST https://api.growvib.com/v1/agent/auth/token \
  -H 'Content-Type: application/json' \
  -d '{"nonce": "<nonce>", "signature": "<signature>"}'

You get a fresh agent_token and the wallet's current balance_usd. No payment, nothing on chain. The nonce is single use and a failed attempt burns it, so request a new challenge per attempt. A Solana wallet sends "chain": "solana" on the challenge request and signs with signMessage.

Payment success does not mean delivery is complete. Three responses are worth handling by name:

For partial delivery or a refund, report what the API says. Refunds are credited to your GrowVib account balance, not returned to the paying wallet, and refunds are not automatic.

What could you build next?

A scheduled digest needs a running application or scheduler. A chat does not keep checking orders after it ends.

Start with one clear task and one approved purchase. Add automation after you understand how the workflow behaves when something goes wrong.

Frequently asked questions

Do I need a GrowVib account or API key?

GrowVib’s x402 route supports purchasing without prior signup or a GrowVib API key. The paying wallet identifies the buyer. Your AI tool or wallet provider may require its own account or credentials.

Do I need to set up PayAI myself?

For this buyer workflow, GrowVib handles the PayAI facilitator connection. Your application needs a compatible x402 v2 client and wallet signer. Do not copy merchant-side facilitator setup into your buyer application.

Is $5 the minimum purchase?

No. It is the example spending budget. The selected service and quantity determine the order price. GrowVib documents a $1 minimum settlement, which can leave account balance when the order costs less. Leftover balance is spendable on later orders without another settlement, using the token an order returns and an idempotency key.

Why does the endpoint return 404?

The x402 route is feature flagged and returns 404 while it is switched off. Check GrowVib’s x402 documentation for current availability before assuming the URL is wrong. A 404 can also mean an unknown service, or an order that does not belong to the authenticated account, depending on the request.

Can I use Solana?

GrowVib also documents Solana support. This guide focuses on Base. A Solana implementation needs the appropriate signer and client support; follow the network entries in the live payment challenge.

Will this increase my sales?

The workflow helps with selection, purchasing, and tracking. It does not guarantee sales, organic growth, or compatibility with every platform’s rules.

Try one approved order

Choose a task you already understand. Compare the available options, review the quote, and follow one small purchase through delivery. Use that experience to decide whether the assistant earns a place in your routine.

Explore GrowVib’s x402 integration and documentation