Skip to the content
Agentic.Pay

For the stack you already use

Your agent.
A clear connection.

Request. Review. Recover.

Connect your application to a bounded purchase workflow. Keep the company, customer permission and request identity visible from the first call to the returned result.

  1. 01Explicit context
  2. 02Deliberate approval
  3. 03A recoverable result
Illustrative sandbox experience · No live transaction

An ordinary HTTP request

Your tools.
The same boundary.

Use the existing purchase interface from a browser agent, messaging product or your own application. This example is selectable; it does not execute a request.

Read the API documentation
purchase.sh / example
curl https://api.agentic.pay/v1/purchases \
  -X POST \
  -H 'Authorization: Bearer YOUR_TOKEN' \
  -H 'Idempotency-Key: order-123' \
  -H 'Content-Type: application/json' \
  -d '{
    "merchantOrigin": "https://example.com",
    "merchantCountry": "US",
    "itemDescription": "Wireless headphones",
    "maxTotalUsdMicros": 150000000,
    "currency": "USD"
  }'

Example values only. Use your configured credentials.

The contract around the call

More than a response.
A workflow you can follow.

  1. 01

    Keep context explicit.

    Carry your company and customer identity through the documented flow. Use the credentials configured for that context.

  2. 02

    Give the operation an identity.

    Use one idempotency key for the same operation. Save the purchase and conversation identifiers returned to your application.

  3. 03

    Review before continuing.

    Bind confirmation to the current observed cart. Keep the merchant, item and total inside the original request boundary.

  4. 04

    Recover before retrying.

    Read the saved conversation or original operation after an uncertain response. Inspect its actual status before starting anything else.

A result is a fact.
Read what it says.

Sandbox confirmation returns a durable no-charge result. A request, an approval and a charge are separate facts. Merchant coverage follows the configured allowlist and supported observed layouts; login, challenges and ambiguity require a human handoff.