Why Indian API Builders Should Care

If you are building an API business from India and serving global users, the payment stack is the ugliest part of the job. Stripe India is gated behind business verification that not every indie founder clears. Razorpay international is improving but still friction-heavy for true pay-per-call pricing. Subscriptions add dunning, failed-card handling, and monthly refund cycles. Invoicing B2B customers outside India means 30 to 60 day payment terms, GST export documentation, and forex conversion losses on every settlement.

Meanwhile, the actual product you are selling is a single HTTP call. A sentiment analysis API. A translation endpoint. A real-time cricket data feed. A code-generation model. A compliance-check microservice. Each call takes milliseconds and is worth a fraction of a cent to a few cents. Trying to wrap that inside a monthly subscription forces you to pick prices that feel either too high for tiny users or too low for heavy users. Most Indian API builders end up leaving money on the table.

x402 solves this by pricing at the HTTP layer. Your server returns a 402 Payment Required status with the exact cost of the specific call being made. The client (a human dev's SDK, or an autonomous agent) signs a USDC payment, retries the request, and the server delivers the resource. No subscription, no contract, no invoice. The USDC lands in your MoltPe wallet seconds after the call completes.

For Indian builders specifically, this pattern matters for four reasons:

How x402 Works — The Protocol

x402 is deliberately simple. It reuses the HTTP 402 Payment Required status code that has been reserved in the HTTP spec since 1999 and finally gives it a concrete meaning. For the full protocol deep-dive, read the complete x402 guide. For Indian devs implementing it today, four bullets cover the core flow:

The elegance of this design is that the entire flow uses vanilla HTTP. You do not need a new transport, a new auth scheme, or a payment-specific middleware in the network path. Any Express, FastAPI, Hono, or Fiber server can add x402 support with a few lines of code.

Code: Expose a Paid API Endpoint

Let's build a real paid API endpoint. Say you have a sentiment analysis endpoint and you want to charge $0.01 USDC per call. The server code below is Node.js + Express, with MoltPe handling wallet management and on-chain verification. The pattern is: check for payment proof, if missing return 402 with requirements, if present verify then serve.

Server: Node.js + Express

// server.js — Indian sentiment API priced at $0.01 USDC per call
import express from "express";
import { MoltPe } from "@moltpe/server-sdk";

const app = express();
app.use(express.json());

const moltpe = new MoltPe({
  apiKey: process.env.MOLTPE_API_KEY,
  recipientWallet: process.env.RECIPIENT_WALLET, // your MoltPe wallet
  network: "polygon",                            // or "base"
});

// Price: $0.01 USDC. USDC has 6 decimals, so 10000 = $0.01
const PRICE_USDC_UNITS = 10000;

app.post("/v1/sentiment", async (req, res) => {
  const proof = req.header("X-PAYMENT");

  // No payment proof — respond with 402 and payment requirements
  if (!proof) {
    return res
      .status(402)
      .set({
        "X-Payment-Amount": PRICE_USDC_UNITS,
        "X-Payment-Token": "0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359", // USDC on Polygon
        "X-Payment-Network": "polygon",
        "X-Payment-Recipient": process.env.RECIPIENT_WALLET,
        "X-Payment-Expiry": Math.floor(Date.now() / 1000) + 300, // 5 min window
      })
      .json({ error: "payment_required", price_usd: "0.01" });
  }

  // Verify the payment on-chain via MoltPe
  const verified = await moltpe.verifyPayment({
    proof,
    expectedAmount: PRICE_USDC_UNITS,
    expectedRecipient: process.env.RECIPIENT_WALLET,
    network: "polygon",
  });

  if (!verified.ok) {
    return res.status(402).json({ error: "invalid_payment", reason: verified.reason });
  }

  // Payment confirmed — do the actual work
  const { text } = req.body;
  const score = await analyzeSentiment(text); // your model / heuristic

  return res.status(200).json({
    sentiment: score,
    paid: true,
    tx: verified.txHash,
  });
});

app.listen(3000, () => console.log("x402 sentiment API on :3000"));

That is the entire server. No Stripe webhook handler, no customer table, no invoice generator. The USDC lands in your MoltPe wallet within seconds of the verifyPayment call returning ok.

Client: calling the paid endpoint with retry

// client.js — calls the sentiment API, handles 402, signs, retries
import { MoltPeClient } from "@moltpe/client-sdk";

const wallet = new MoltPeClient({
  agentKey: process.env.AGENT_KEY,
  maxPerCallUsd: 0.05, // safety cap — never pay more than this per call
});

async function getSentiment(text) {
  const url = "https://api.yourcompany.in/v1/sentiment";
  const body = JSON.stringify({ text });

  // First attempt — expect 402
  let res = await fetch(url, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body,
  });

  if (res.status === 402) {
    // Sign payment matching the server's requirements
    const proof = await wallet.signX402Payment({
      amount: res.headers.get("X-Payment-Amount"),
      token: res.headers.get("X-Payment-Token"),
      network: res.headers.get("X-Payment-Network"),
      recipient: res.headers.get("X-Payment-Recipient"),
    });

    // Retry with proof attached
    res = await fetch(url, {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "X-PAYMENT": proof,
      },
      body,
    });
  }

  return res.json();
}

console.log(await getSentiment("The new Bangalore metro is fantastic"));

Two HTTP calls. One signed payment. One USDC deposit to your Indian-founded company's wallet. That is the whole loop.

Code: Consume a Paid API From an Agent

The other direction is equally important. Say you are building an AI agent from India — a research assistant, a code reviewer, a customer-support bot — and it needs to call paid external APIs: a premium data feed, a specialized LLM, a compliance lookup service. You want the agent to pay per call, cache results, and enforce a daily budget so a runaway loop does not drain your wallet.

Here is a minimal autonomous consumer pattern using MoltPe's agent runtime.

// agent.js — Indian-built research agent calling paid external APIs
import { MoltPeAgent } from "@moltpe/agent-sdk";
import { LRUCache } from "lru-cache";

const agent = new MoltPeAgent({
  agentId: "research-bot-v1",
  wallet: process.env.AGENT_WALLET,
  policies: {
    maxPerCallUsd: 0.02,       // never pay more than 2 cents in one call
    maxPerDayUsd: 5.0,         // hard daily cap
    allowedNetworks: ["polygon", "base"],
  },
});

// Cache successful paid responses for 1 hour
const cache = new LRUCache({ max: 500, ttl: 1000 * 60 * 60 });

async function fetchPaidData(endpoint, params) {
  const key = endpoint + JSON.stringify(params);
  if (cache.has(key)) return cache.get(key);

  // MoltPe agent automatically handles 402: detects, signs, retries, verifies
  const response = await agent.callX402({
    url: endpoint,
    method: "GET",
    query: params,
  });

  if (response.status !== 200) {
    throw new Error(`paid call failed: ${response.status} ${response.error}`);
  }

  cache.set(key, response.data);
  return response.data;
}

// Example: agent queries a premium stock-fundamentals API per ticker
const fundamentals = await fetchPaidData(
  "https://api.finprovider.com/v1/fundamentals",
  { ticker: "TCS", exchange: "NSE" }
);

console.log("Revenue growth:", fundamentals.revenueGrowth);

A few things to notice. The policies block is doing real work: if an upstream server suddenly demands $0.50 per call, the agent refuses before any payment is signed. The daily cap protects against infinite loops. The cache means you never pay twice for the same query in an hour. Together, these three controls make it safe to let an autonomous agent spend real money on behalf of your Indian startup.

Indian Use Cases

Four categories of Indian builders are the earliest winners from x402. Each sidesteps a specific pain point that subscription billing cannot solve.

Indian AI SaaS charging per inference. You have fine-tuned a small language model in Hyderabad that does Hindi-to-English legal translation better than any generic provider. Instead of $29/month tiers, charge $0.001 per paragraph. Global law firms, Indian legal-tech startups, and research agents all pay the same way. Revenue scales exactly with usage, and you never have to argue about plan limits.

Indian data providers selling to global AI agents. You have built a real-time feed of Indian equity market data, weather for agritech, or cricket statistics. Traditionally your customer list is a handful of hedge funds you landed through Delhi business-development lunches. With x402, any autonomous agent in the world can discover your endpoint and pay $0.005 per data point, no sales cycle, no contract. A new market opens: agent-driven clients who buy data the way a human buys a bottle of water.

Indian dev tools with pay-per-use pricing. You maintain a high-quality code search index, a security scanner, or a dependency-graph API. Instead of forcing small teams into enterprise plans, price it per call. Indian indie devs building side projects, solo consultants in Tier-2 cities, and global CI pipelines all pay in proportion to their usage.

Freelance Indian devs monetizing micro-APIs. You wrote a tiny service that solves one thing well — a GSTIN validator, a Pincode-to-coordinates lookup, a shipping-cost estimator. Deploy it once, price it at $0.0005, point the endpoint through MoltPe, and leave it running. No company registration required to accept payment. No Stripe approval. No GST export documentation until your volume crosses thresholds where you should talk to a CA anyway.

All four patterns share the same shape: a small, fast HTTP service, priced per call, paid in USDC, settled automatically. x402 is the piping that makes this feasible for Indian founders who cannot or will not build the classical subscription stack on day one.