One purchase. Five moments.
When the service fails,
what happens next?
An agent buys an API result. It gets an error. Follow the refund right agreed before payment, all the way to a separate refund.
No sign-in needed. This is an illustrative tour of the workspace flow. It creates no records and moves no money.
01 / Merchant + buyer
The promise comes before the payment.
An agent wants one result from a fictional data service, Atlas API, for 100 DEMO. It reads and accepts the merchant’s refund terms before paying.
Why this matters
The buyer can inspect what is covered, who decides and where a refund could come from. The merchant commits in advance to a bounded refund path.
In an integrationThe merchant application creates the purchase; the buyer or agent accepts its exact terms.
See the workspace API action
Example request body for POST /api/sandbox on this host. Use your authenticated workspace, its returned IDs and a unique Idempotency-Key. Reading or copying this example sends nothing.
{
"workspace_id": "<workspace_id>",
"action": "create",
"input": {
"amount": 100,
"order_id": "atlas-example",
"beneficiary": "demo-buyer"
}
}The buyer then sends action “accept” with the returned purchase_id.
Read the API manifest →02 / Buyer + payment integration
The payment settles. The terms stay attached.
The buyer pays 100 DEMO to the merchant. The payment integration links that settlement to the exact accepted purchase.
Why this matters
A later refund will be a separate payment. The original transfer stays final throughout this story.
In an integrationAn integrated payment observer would report settlement. In your workspace, you explicitly record a synthetic test payment.
See the workspace API action
Example request body for POST /api/sandbox on this host. Use your authenticated workspace, its returned IDs and a unique Idempotency-Key. Reading or copying this example sends nothing.
{
"workspace_id": "<workspace_id>",
"action": "settle",
"input": {
"purchase_id": "<purchase_id>",
"settlement_ref": "synthetic:<purchase_id>",
"amount": 100,
"asset": "DEMO",
"network": "simulation-only",
"destination": "<workspace_id>"
}
}03 / Buyer or agent
The result fails. The buyer files a claim.
Atlas API returns an error instead of the agreed result. The agent submits a claim for 100 DEMO with a fictional failure report.
Why this matters
A claim records what happened and what is requested. It does not, by itself, approve a refund.
In an integrationThe buyer application or agent submits the purchase reference, reason, requested amount and evidence.
See the workspace API action
Example request body for POST /api/sandbox on this host. Use your authenticated workspace, its returned IDs and a unique Idempotency-Key. Reading or copying this example sends nothing.
{
"workspace_id": "<workspace_id>",
"action": "claim",
"input": {
"purchase_id": "<purchase_id>",
"requested": 100,
"reason": "api_result_failure",
"evidence": "Fictional example: the API returned an error instead of the result."
}
}04 / Agreed reviewer → Cleard
100 approved. 40 paid. 60 still owed.
The named reviewer approves the claim. Cleard checks the decision against the purchase and records a separate 40 DEMO refund from the available reserve.
Why this matters
The merchant is not asked to approve again. The prior terms authorize the path. Available funds still limit the amount that can be paid.
In an integrationThe reviewer issues one bounded decision. The execution service checks the purchase, beneficiary, amount, authority and prior payouts.
See the workspace API action
Example request body for POST /api/sandbox on this host. Use your authenticated workspace, its returned IDs and a unique Idempotency-Key. Reading or copying this example sends nothing.
{
"workspace_id": "<workspace_id>",
"action": "decide",
"input": {
"purchase_id": "<purchase_id>",
"approved": 100,
"beneficiary": "demo-buyer",
"reason": "Fictional example: service failure confirmed."
}
}05 / Enrolled source → Cleard
New eligible funds. The same decision.
Later, 60 DEMO is added to the enrolled reserve. Cleard records a second refund for exactly the amount still owed, using the existing approval.
Why this matters
The ledger now shows 100 approved, 100 paid and nothing owed. The buyer did not need a second claim, and the original payment was never reversed.
In an integrationA supported collection source would make new funds available. The sandbox models this with a fictional reserve top-up and request-driven processing.
See the workspace API action
Example request body for POST /api/sandbox on this host. Use your authenticated workspace, its returned IDs and a unique Idempotency-Key. Reading or copying this example sends nothing.
{
"workspace_id": "<workspace_id>",
"action": "topup",
"input": {
"amount": 60
}
}From example to experiment
Your own purchase.
Your saved results.
Open your workspace to create different purchases, review claims and test funding shortfalls. Sign-in keeps your records private and saves your progress.
Advanced controls let you act as each fictional participant. The backend records simulated payments and test signatures. Real collection and BLISK execution are not connected.
Open your workspace