Sandbox

စမ်းသပ်ရန် သီးခြားခွဲထားသော API ပတ်ဝန်းကျင်

The sandbox is a full, isolated copy of the Merchant API for building and testing integrations without touching real shop data. It speaks the same contract as production — same endpoints, same request/response shapes, same error codes — so code proven against the sandbox runs unchanged against production.

sandbox သည် အစစ်အမှန် ဆိုင် data ကို မထိဘဲ integration များ တည်ဆောက်စမ်းသပ်ရန် Merchant API ၏ ပြည့်စုံ၍ သီးခြားခွဲထားသော မိတ္တူတစ်ခု ဖြစ်သည်။ ၎င်းသည် production နှင့် contract တူ ပြောဆိုသည် — endpoint တူ၊ request/response ပုံစံတူ၊ error code တူ — သို့ဖြစ်၍ sandbox ပေါ်တွင် သက်သေပြထားသော code သည် production ပေါ်တွင် မပြောင်းဘဲ အလုပ်လုပ်သည်။

1 · Base URL

၁ · Base URL

Point your client at the sandbox host instead of production:

သင့် client ကို production အစား sandbox host သို့ ညွှန်ပါ —

https://sandbox-api.doehpos.com

2 · Test keys

၂ · Test key များ

A shop owner creates a key in the portal with environment set to test; the secret is a sk_test_… key (production keys are sk_live_…). The two planes are strictly separated:

ဆိုင် ပိုင်ရှင် က portal တွင် environment ကို test သတ်မှတ်၍ key တစ်ခု ဖန်တီးသည်။ secret သည် sk_test_… key (production key များမှာ sk_live_…)။ plane နှစ်ခုကို တင်းကြပ်စွာ ခွဲထားသည် —

A sk_test_… key works only on sandbox-api.doehpos.com.
A sk_live_… key works only on api.doehpos.com.
Crossing the streams is refused with API_KEY_ENV_MISMATCH (HTTP 401).

sk_test_… key သည် sandbox-api.doehpos.com ပေါ်တွင် သာ အလုပ်လုပ်သည်။
sk_live_… key သည် api.doehpos.com ပေါ်တွင် သာ အလုပ်လုပ်သည်။
တစ်ခုနှင့်တစ်ခု ဖြတ်ကျော်သုံးလျှင် API_KEY_ENV_MISMATCH (HTTP 401) ဖြင့် ငြင်းပယ်သည်။

curl https://sandbox-api.doehpos.com/v1/delivery/orders \
  -H "Authorization: Bearer sk_test_<keyid>_<secret>" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{"currency":"MMK","amount_minor":1500}'

3 · Test data is reset daily

၃ · Test data ကို နေ့စဉ် reset လုပ်သည်

Sandbox data is wiped and reseeded to a fixed baseline every day at ~03:30 UTC (Stripe-style). Anything you create is disposable: do not store sandbox IDs long-term, and expect a clean, deterministic starting state each day. The sandbox never holds real customer or order data.

Sandbox data ကို နေ့စဉ် ~03:30 UTC တွင် ဖျက်ပြီး သတ်မှတ် baseline သို့ ပြန်ဖြည့်သည် (Stripe ပုံစံ)။ သင်ဖန်တီးသမျှ ဖျက်ပစ်ရန်အတွက်သာ — sandbox ID များကို ရေရှည် မသိမ်းပါနှင့်၊ နေ့တိုင်း သန့်ရှင်းသော အစအနေအထား ရှိမည်ဟု မျှော်လင့်ပါ။ sandbox သည် အစစ်အမှန် customer သို့မဟုတ် order data ကို ဘယ်တော့မှ မသိမ်းပါ။

4 · Same everything else

၄ · ကျန်အရာအားလုံး တူညီသည်

Authentication, server-derived shop/branch scope, idempotency, rate limits, and the error envelope are identical to production — see Getting started, Authentication, and the error reference. The only differences are the base URL and the test key environment.

Authentication၊ server ဘက်တွင်တွက်သော shop/branch scope၊ idempotency၊ rate limit များနှင့် error envelope တို့သည် production နှင့် တထေရာတည်း တူသည် — စတင်ခြင်း၊ Authentication နှင့် error အကိုးအကား ကို ကြည့်ပါ။ ကွာခြားချက်မှာ base URL နှင့် test key environment သာ ဖြစ်သည်။

5 · Sandbox experiences

၅ · Sandbox တွင် သုံးနိုင်သည်များ

Public Merchant API surfaces you can exercise on the sandbox today:

ယနေ့ sandbox ပေါ်တွင် စမ်းသပ်နိုင်သော အများသုံး Merchant API မျက်နှာစာများ —

Surface	Status	Reference
Loyalty	Available	Loyalty API
Delivery	Available	Delivery API
Orders (sales submission)	Experimental	Orders

6 · One-command smoke test

၆ · command တစ်ခုတည်းဖြင့် smoke test

The Loyalty Starter ships a smoke check that drives the full loyalty flow through the published SDK against this sandbox — proof your integration is healthy end to end:

Loyalty Starter တွင် ထုတ်ဝေပြီး SDK မှတစ်ဆင့် loyalty flow အပြည့်အစုံကို ဤ sandbox ပေါ်၌ မောင်းနှင်သော smoke check ပါသည် — သင့် integration အစအဆုံး ကောင်းမွန်ကြောင်း သက်သေ —

export DOEH_API_KEY=sk_test_<keyid>_<secret>
pnpm smoke:sandbox
# key present → reachable → earn → balance → redeem → 409 → idempotent → PASS