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.
- 01Explicit context
- 02Deliberate approval
- 03A recoverable result
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 documentationcurl 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.
-
01
Keep context explicit.
Carry your company and customer identity through the documented flow. Use the credentials configured for that context.
-
02
Give the operation an identity.
Use one idempotency key for the same operation. Save the purchase and conversation identifiers returned to your application.
-
03
Review before continuing.
Bind confirmation to the current observed cart. Keep the merchant, item and total inside the original request boundary.
-
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.