← Developer home

AuthenticationAuthentication (အထောက်အထားစိစစ်ခြင်း)

Merchant integrations authenticate with a merchant API key as a bearer token (a shop's own consumer app uses the consumer plane instead):

Merchant integration များ သည် merchant API key ကို bearer token အဖြစ် အသုံးပြု၍ authenticate လုပ်သည် (ဆိုင်၏ ကိုယ်ပိုင် consumer app သည် consumer plane ကို အသုံးပြုသည်) —

Authorization: Bearer sk_live_<keyid>_<secret>

Keys

Key များ

• Format: sk_<env>_<keyid>_<secret> — env is live or test.
• Keys are created in the portal — by the shop owner, or by a developer account the shop has delegated to you (see Portal access): name the app, choose scopes and branch access, then copy the secret — it is shown once and never retrievable again.
• live and test keys are disjoint; a key works only in its own environment.
• Rotate or revoke at any time in the portal. Revocation is immediate.

• ပုံစံ — sk_<env>_<keyid>_<secret> — env သည် live သို့မဟုတ် test။
• Key များကို portal တွင် ဖန်တီးသည် — ဆိုင် ပိုင်ရှင် က ဖြစ်စေ၊ ဆိုင်က သင့်ကို လွှဲအပ်ထားသော developer account ဖြင့် ဖြစ်စေ (Portal access ကို ကြည့်ပါ) — app ကို အမည်ပေး၊ scope နှင့် branch access ရွေး၊ ထို့နောက် secret ကို ကူးယူပါ — ၎င်းကို တစ်ကြိမ်သာ ပြသပြီး နောက်တစ်ဖန် ပြန်ယူ၍မရတော့ပါ။
• live နှင့် test key များ သီးခြားဖြစ်သည်။ key တစ်ခုသည် ၎င်း၏ environment ထဲတွင်သာ အလုပ်လုပ်သည်။
• portal တွင် အချိန်မရွေး rotate သို့မဟုတ် revoke လုပ်နိုင်သည်။ revoke လုပ်လျှင် ချက်ချင်း သက်ရောက်သည်။

Portal access — two ways to sign in

Portal access — sign in ဝင်နိုင်သော နည်းလမ်း နှစ်မျိုး

You do not need the merchant's POS password to manage that shop's API keys. The portal accepts two separate identities:

ဆိုင်၏ API key များကို စီမံရန် merchant ၏ POS စကားဝှက် မလိုအပ်ပါ။ portal သည် သီးခြား identity နှစ်မျိုးကို လက်ခံသည် —

• Shop owner — the owner's POS login, at /portal. This is the merchant's own full credential.
• Delegated developer account — email + password, at /portal/developer/login. A portal-only identity, issued by DOEH at the shop's request. It is bound to exactly one shop and it cannot sign in to the POS at all — so an integrator gets key issuance for that shop and nothing else.

• ဆိုင်ပိုင်ရှင် — ပိုင်ရှင်၏ POS login၊ /portal တွင်။ ၎င်းသည် merchant ၏ ကိုယ်ပိုင် credential အပြည့် ဖြစ်သည်။
• လွှဲအပ်ထားသော developer account — email + password၊ /portal/developer/login တွင်။ ဆိုင်၏ တောင်းဆိုချက်ဖြင့် DOEH က ထုတ်ပေးသော portal-only identity ဖြစ်သည်။ ဆိုင်တစ်ခုတည်း နှင့်သာ ချည်နှောင်ထားပြီး POS သို့ လုံးဝ sign in ဝင်၍ မရပါ — ထို့ကြောင့် integrator သည် ထိုဆိုင်အတွက် key ထုတ်ခြင်းသာ ရရှိပြီး အခြားမည်သည့် အခွင့်အရေးမျှ မရပါ။

First sign-in on a developer account

Developer account ဖြင့် ပထမဆုံး sign in ဝင်ခြင်း

• You receive your email address and a one-time bootstrap password. It is shown to the operator once at provisioning and is never recoverable — if it is lost, the account is re-issued.
• Your first sign-in lands on a forced password change. The portal stays closed until you complete it — key issuance is not reachable before then.
• Choose a password of at least 12 characters, containing letters and numbers. Re-using the bootstrap password is refused.
• Once changed, the bootstrap password is dead and later sign-ins go straight to the portal.

• သင့် email လိပ်စာနှင့် တစ်ကြိမ်သုံး bootstrap စကားဝှက် ကို လက်ခံရရှိမည်။ ၎င်းကို ထုတ်ပေးချိန်တွင် operator အား တစ်ကြိမ်သာ ပြသပြီး နောက်ပြန် ရယူ၍ မရပါ — ပျောက်ဆုံးလျှင် account ကို အသစ်ပြန်ထုတ်ရသည်။
• ပထမဆုံး sign in ဝင်ချိန်တွင် စကားဝှက် မဖြစ်မနေ ပြောင်းရသော စာမျက်နှာသို့ ရောက်သည်။ ၎င်းကို မပြီးမချင်း portal ပိတ်နေမည် — key ထုတ်ခြင်းကို ထိုအချိန်မတိုင်မီ လုပ်၍ မရပါ။
• အနည်းဆုံး စာလုံး ၁၂ လုံး ရှိပြီး စာလုံးနှင့် ဂဏန်း ပါဝင်သော စကားဝှက် ရွေးပါ။ bootstrap စကားဝှက်ကို ပြန်သုံးလျှင် ငြင်းပယ်သည်။
• ပြောင်းပြီးသည်နှင့် bootstrap စကားဝှက် သေဆုံး ပြီး နောက်ပိုင်း sign in ဝင်လျှင် portal သို့ တိုက်ရိုက် ရောက်သည်။

A developer account sees only its own shop's applications and keys — the shop is derived from the account server-side, exactly as it is from a key. To request one, ask the merchant to contact DOEH; the merchant authorises it, not you.

Developer account တစ်ခုသည် မိမိဆိုင်၏ application နှင့် key များကိုသာ မြင်ရသည် — key မှ တွက်ယူသကဲ့သို့ ဆိုင်ကို account မှ server ဘက်တွင် တွက်ယူသည်။ တောင်းခံလိုလျှင် merchant အား DOEH သို့ ဆက်သွယ်ခိုင်းပါ — ခွင့်ပြုသူမှာ merchant ဖြစ်ပြီး သင် မဟုတ်ပါ။

Scope is server-derived

Scope ကို server ဘက်တွင် တွက်ချက်သည်

Clients send only the bearer token. The shop and branch a key may act on are derived server-side from the key — you never send X-Shop-Id or X-Branch-Id. A request is allowed only if the operation's required scope is within the key's effective scope and the target branch is within the key's branch policy; otherwise it is refused (see the error reference).

Client များသည် bearer token တစ်ခုတည်း ကိုသာ ပို့သည်။ key တစ်ခု ဆောင်ရွက်နိုင်သော ဆိုင်နှင့် branch ကို key မှ server ဘက်တွင် တွက်ချက်သည် — X-Shop-Id သို့မဟုတ် X-Branch-Id ကို ဘယ်တော့မှ မပို့ရပါ။ operation ၏ လိုအပ်သော scope သည် key ၏ scope အတွင်း ရှိ၍ နှင့် ပစ်မှတ် branch သည် key ၏ branch policy အတွင်း ရှိမှသာ request ကို ခွင့်ပြုသည်။ မဟုတ်လျှင် ငြင်းပယ်သည် (error အကိုးအကား ကို ကြည့်ပါ)။

Idempotency

Supply an Idempotency-Key header on POSTs; a retry with the same key returns the original result instead of creating a duplicate.

POST များတွင် Idempotency-Key header ထည့်ပါ။ key တူဖြင့် ပြန်လည်ကြိုးစားလျှင် ထပ်နေသော record အသစ် မဖန်တီးဘဲ မူရင်းရလဒ်ကိုသာ ပြန်ပေးသည်။

Consumer plane — publishable keys

Consumer plane — publishable key များ

A shop's own customer-facing app authenticates differently: a publishable key (pk_test_… / pk_live_…) sent as X-Publishable-Key, plus the signed-in customer's bearer token on each request. The publishable key is safe to embed in the app build — it grants nothing by itself, and the shop it may act for is derived server-side from the key. The two kinds are strictly separated: a pk_ is never accepted where a sk_ is required, and vice versa. See the Consumer Mobile API reference and the @beyondplusmm/doeh-consumer-sdk section of the SDK quickstart. Sandbox only for now — the production consumer plane is not yet enabled.

ဆိုင်၏ ကိုယ်ပိုင် customer-facing app သည် ကွဲပြားစွာ authenticate လုပ်သည် — publishable key (pk_test_… / pk_live_…) ကို X-Publishable-Key အဖြစ် ပို့ပြီး request တိုင်းတွင် sign in ဝင်ထားသော customer ၏ bearer token ပါ ထည့်သည်။ publishable key ကို app build ထဲ ထည့်ရန် စိတ်ချရသည် — key တစ်ခုတည်းဖြင့် ဘာမှ လုပ်၍မရပါ၊ ၎င်း ဆောင်ရွက်နိုင်သော ဆိုင်ကို key မှ server ဘက်တွင် တွက်ယူသည်။ key အမျိုးအစား နှစ်ခုကို တင်းကြပ်စွာ ခွဲခြားထားသည် — sk_ လိုအပ်သော နေရာတွင် pk_ ကို ဘယ်တော့မှ လက်မခံပါ၊ ပြောင်းပြန်လည်း ထိုနည်းတူ။ Consumer Mobile API အကိုးအကား နှင့် SDK quickstart ၏ @beyondplusmm/doeh-consumer-sdk အပိုင်းကို ကြည့်ပါ။ ယခုအချိန်တွင် sandbox သာ — production consumer plane မဖွင့်ရသေးပါ။

Customer identity — OAuth 2.1 hosted sign-in

Customer identity — OAuth 2.1 hosted sign-in

The customer bearer token comes from the DOEH Identity Platform: OAuth 2.1 authorization-code + PKCE (S256 only) with hosted login and consent — the customer signs in on a DOEH page, your app never sees or collects their credentials. Discovery: https://auth.doehpos.com/.well-known/openid-configuration.

Customer bearer token ကို DOEH Identity Platform မှ ထုတ်ပေးသည် — OAuth 2.1 authorization-code + PKCE (S256 သာ) ဖြင့် hosted login နှင့် consent — customer သည် DOEH ၏ page တွင် sign in ဝင်သည်။ သင့် app သည် သူတို့၏ စကားဝှက်ကို ဘယ်တော့မှ မမြင်ရ၊ မသိမ်းရပါ။ Discovery — https://auth.doehpos.com/.well-known/openid-configuration။

your app                        auth.doehpos.com                    api.doehpos.com
   |                                   |                                  |
   |-- GET /authorize + PKCE -------->|                                  |
   |                                   |-- hosted login (OTP)             |
   |                                   |-- consent screen                 |
   |<-- redirect: code ---------------|                                  |
   |-- POST /token (code+verifier) -->|                                  |
   |<-- dat_ access + drt_ refresh ---|                                  |
   |                                   |                                  |
   |-- X-Publishable-Key: pk_...  +  Authorization: Bearer dat_... ----->|
   |<-- the customer's data, scoped to your grant ------------------------|

• Tokens are opaque (dat_…) and short-lived: access 10 minutes; the refresh token is one-time-use and rotates on every refresh — reusing an old one revokes the whole family. Refresh lifetime: 30 days idle, 90 days absolute; after that the customer signs in again.
• Audience-bound: consumer tokens are minted for the consumer API only. A token presented to any other DOEH surface — or any other token presented here — is refused as CUSTOMER_TOKEN_INVALID, with no further detail.
• Consent is live, not a one-time stamp: every request re-checks the customer's grant. When a customer revokes your app, their resources immediately become invisible — reads answer 404 NOT_FOUND, and "not a member" and "not consented" are deliberately the same answer (a revoked app must not be able to probe shop membership). If you get an unexpected 404, send the customer through /authorize again — it renews consent when consent is what's missing.
• DPoP (sender-constrained tokens, RFC 9449): coming with the native-client release. It will be required for future sensitive scopes (wallet, profile PII); the current scope set stays bearer. Nothing to change today — the requirement will only ever apply to scopes you cannot request yet.

• Token များသည် opaque (dat_…) ဖြစ်ပြီး သက်တမ်းတို — access ၁၀ မိနစ်။ refresh token သည် တစ်ကြိမ်သုံး ဖြစ်ပြီး refresh တိုင်းတွင် အသစ်လဲသည် — အဟောင်းကို ပြန်သုံးလျှင် family တစ်ခုလုံး revoke ဖြစ်သည်။ refresh သက်တမ်း — အသုံးမပြုလျှင် ရက် ၃၀၊ အများဆုံး ရက် ၉၀။ ထို့နောက် customer ပြန် sign in ဝင်ရသည်။
• Audience ချည်နှောင်ထားသည် — consumer token များကို consumer API အတွက်သာ ထုတ်ပေးသည်။ အခြား DOEH surface သို့ တင်ပြလျှင် — သို့မဟုတ် အခြား token ကို ဤနေရာတွင် တင်ပြလျှင် — CUSTOMER_TOKEN_INVALID ဖြင့် ငြင်းပယ်သည်။ အသေးစိတ် အကြောင်းပြချက် မပေးပါ။
• Consent သည် အသက်ရှင်နေသည် — request တိုင်းတွင် customer ၏ ခွင့်ပြုချက်ကို ပြန်စစ်သည်။ customer က သင့် app ကို revoke လုပ်လျှင် သူတို့၏ data ချက်ချင်း မမြင်ရ ဖြစ်သွားသည် — 404 NOT_FOUND ပြန်ရသည်။ "member မဟုတ်" နှင့် "consent မပေးထား" ကို တမင် တူညီသော အဖြေ ထားသည် (revoke ခံရသော app သည် ဆိုင် member ဖြစ်မဖြစ် စုံစမ်း၍ မရစေရ)။ မမျှော်လင့်သော 404 ရလျှင် customer ကို /authorize သို့ ပြန်ပို့ပါ — consent လိုနေလျှင် ၎င်းက အသစ်ပြန်ရယူပေးသည်။
• DPoP (sender-constrained token, RFC 9449) — native-client ထွက်ရှိချိန်တွင် ပါလာမည်။ နောင်လာမည့် sensitive scope များ (wallet, profile PII) အတွက် မဖြစ်မနေ လိုအပ်မည်။ လက်ရှိ scope များ bearer အတိုင်း ဆက်သုံးနိုင်သည်။ ယနေ့ ပြောင်းစရာ မရှိပါ။