Webhook ဆိုတာ ဘာလဲ? အက်ပ်များ အချင်းချင်း အသိပေးပုံ
Webhook ဆိုတာ တစ်ခုခု ဖြစ်ပေါ်တဲ့ အချိန်နှင့် တစ်ပြိုင်နက် ဝန်ဆောင်မှုတစ်ခုက သင့်အက်ပ်ထံ ပို့သော အလိုအလျောက် မက်ဆေ့ချ် ဖြစ်ပါတယ်။ ဖောက်သည်တစ်ဦး၏ ငွေပေးချေမှု အောင်မြင်သည့်အခါ Stripe က သင့်အက်ပ်ရှိ လိပ်စာသို့ "ငွေပေးချေမှု အောင်မြင်ပါပြီ၊ အသေးစိတ်ဒီမှာ" ဟု webhook ပို့ပြီး အက်ပ်က တုံ့ပြန်သည် — အော်ဒါကို ပေးချေပြီးဟု အမှတ်အသား ပြုလုပ်၊ ပြေစာ ပို့၊ အကောင့်ကို ဖွင့်ပေးသည်။ အတိုချုပ်ဆိုရလျှင် API သည် သင့်အက်ပ်က အခြားဝန်ဆောင်မှုကို မေးခွန်းမေးခြင်း ဖြစ်ပြီး webhook သည် အခြားဝန်ဆောင်မှုက သင့်အက်ပ်ကို တစ်ခုခု ပြောပြရန် ခေါ်ခြင်း ဖြစ်သည်။
AI နဲ့ တည်ဆောက်တဲ့အခါ ဘာကြောင့် အရေးကြီးလဲ
ငွေပေးချေမှု လက်ခံသော၊ အခြားကိရိယာမှ ဖောင်ပို့မှုများ လက်ခံသော၊ သို့မဟုတ် GitHub၊ Shopify သို့မဟုတ် ပြက္ခဒိန်ကဲ့သို့ ဝန်ဆောင်မှုများနှင့် ချိတ်ဆက်သည့်အခါ webhook များနှင့် တွေ့ရမည်။ ၎င်းတို့သည် တစ်ခုခု ဖြစ်ခဲ့ကြောင်း သိရန် မှန်ကန်သော နည်းလမ်းဖြစ်လေ့ရှိသော်လည်း AI ဖြင့် တည်ဆောက်ထားသော အက်ပ်များ မှားလေ့ရှိသော နေရာလည်း ဖြစ်သည်:
- Endpoint က မည်သည့် request ကိုမဆို လက်ခံသဖြင့် တစ်ယောက်ယောက်က "ငွေပေးချေပြီး" အဖြစ်အပျက်ကို အတုလုပ်နိုင်သည်။
- အက်ပ်က checkout redirect စာမျက်နှာပေါ်တွင် ဝင်ခွင့်ပေးသည်၊ webhook ပေါ်တွင် မဟုတ်ဘဲ။ ထို့ကြောင့် tab ကို စောစောပိတ်သူများ ရရှိမည့်အရာကို မရဘဲ၊ success URL ကို တွေ့သူများ အခမဲ့ ရသည်။
- အဖြစ်အပျက် တစ်ခုတည်း နှစ်ကြိမ် ရောက်လာပြီး ဖောက်သည်က အော်ဒါ နှစ်ခု သို့မဟုတ် အီးမေးလ် နှစ်စောင် ရရှိနိုင်သည်။
Webhook များ မည်သို့ အလုပ်လုပ်သည်ကို သိခြင်းက ကြိုတင် ကာကွယ်မှုများကို တောင်းဆိုနိုင်စေသည်။
လူတွေ နေ့စဉ်သုံးတဲ့ ဥပမာ: ပါဆယ် စာတိုအသိပေးချက်
သင့်ပါဆယ် ရောက်ပြီလား ဆိုသည်ကို နည်းလမ်းနှစ်မျိုးဖြင့် သိနိုင်သည်။ ဆယ်မိနစ်တစ်ခါ တံခါးဝသို့ သွားကြည့်နိုင်သည် (ဤသည်ကို polling ဟုခေါ်သည် — သင့်အက်ပ်က API ကို "အသစ်ရှိလား" ဟု ထပ်ထပ်မေးခြင်း)။ သို့မဟုတ် ပို့ဆောင်သူက ပို့ပြီးသည်နှင့် စာတိုပို့ပေးနိုင်သည် (ဤသည်က webhook ဖြစ်သည်)။
စာတိုက ရှင်းရှင်းပင် ပိုကောင်းသည် — ယုံကြည်နိုင်သရွေ့။ တစ်စုံတစ်ယောက်က "ပါဆယ် ရောက်ပြီ" စာတိုကို ပို့နိုင်ပါက ထိုစာသည် ပို့ဆောင်သူထံမှ တကယ်ဖြစ်ကြောင်း စစ်ဆေးလိုမည်။ ဖုန်းပိတ်ထားစဉ် စာတိုရောက်ခဲ့လျှင် ပို့ဆောင်သူက နောက်မှ ထပ်ကြိုးစားစေလိုမည်။ ထိုကိစ္စ နှစ်ခု — စစ်ဆေးခြင်း နှင့် ပြန်ကြိုးစားခြင်း — သည် webhook ကို ခက်ခဲစေသော အဓိကအချက်များ ဖြစ်သည်။
Webhook အလုပ်လုပ်ပုံ အဆင့်ဆင့်
- Endpoint ဖန်တီးပါ။ အက်ပ် backend တွင်
POSTrequest များကို လက်ခံသော URL တစ်ခု၊ ဥပမာhttps://yourapp.com/webhooks/stripe။ - URL ကို provider တွင် မှတ်ပုံတင်ပြီး သင်လိုချင်သော အဖြစ်အပျက်များကို ရွေးပါ (ဥပမာ "checkout ပြီးဆုံး" နှင့် "subscription ပယ်ဖျက်ခြင်း")။
- Provider က signing secret ပေးသည်။ ၎င်းကို သင့်ဆာဗာတွင် secret အဖြစ် သိမ်းပါ — environment variables နှင့် secrets ကို ကြည့်ပါ။
- အဖြစ်အပျက် ဖြစ်ပေါ်သည်။ Provider က သင့် URL သို့ JSON body ပါသော HTTP request တစ်ခုနှင့် signature header ကို ပို့သည်။
- သင့်အက်ပ်က signature ကို စစ်ဆေးပြီး event ID ကို မှတ်တမ်းတင်ကာ
200အောင်မြင်ကုဒ်ကို အမြန်ပြန်ပို့ပြီးမှ အလုပ်ကို လုပ်သည်။ - အက်ပ်က အောင်မြင်ကုဒ် မပြန်ပါက provider အများအပြားက နောက်မှ ပြန်ကြိုးစားသည်။
လက်မှတ်များ (Signatures)
Signature သည် request ကို provider မှ ရောက်လာပြီး ပြောင်းလဲခြင်း မခံရကြောင်း သက်သေပြသည်။ ဥပမာ Stripe သည် request body နှင့် timestamp အပေါ် signing secret ဖြင့် HMAC (keyed fingerprint အမျိုးအစား) ကို SHA-256 ဖြင့် တွက်ချက်ပြီး Stripe-Signature header တွင် ပို့သည်။ သင့်အက်ပ်သည် သင့်ကိုယ်ပိုင် secret ကော်ပီဖြင့် တူညီစွာ တွက်ချက်သည်။ ရလဒ်များ ကိုက်ညီပါက request သည် အမှန်ဖြစ်သည်။ timestamp ကိုလည်း လက်မှတ်ထိုးထားသောကြောင့် ဟောင်းနွမ်းသော request များကို ပြန်ဖွင့်ခြင်း (replay) မှ ပယ်ချနိုင်သည် — Stripe ၏ library များသည် စာရွက်စာတမ်းအရ ၂၀၂၆ ခုနှစ် စက်တင်ဘာလအထိ မူလအနေဖြင့် ငါးမိနစ် tolerance သုံးသည်။
လက်တွေ့ အသေးစိတ်တစ်ခု — signature ကို raw request body ပေါ်တွင် တွက်သည်။ framework က စစ်ဆေးမီ JSON ကို parse လုပ်ပြီး ပြန်ပုံစံချပါက စစ်ဆေးမှု ကျရှုံးသည်။ ဤသည်မှာ အများဆုံးတွေ့ရသော bug ဖြစ်သည်။
ပြန်ကြိုးစားခြင်း၊ ထပ်တူများနှင့် အစဉ်
Provider တစ်ခုစီ ကွဲပြားသည်။ ၂၀၂၆ စက်တင်ဘာလအထိ အောက်ပါအတိုင်း:
| အပြုအမူ | Stripe | GitHub |
|---|---|---|
| အလိုအလျောက် ပြန်ကြိုးစားခြင်း | ရှိသည်၊ live mode တွင် ရက်သုံးရက်အထိ တဖြည်းဖြည်း ကြားကာလများဖြင့် | မရှိပါ; ကျရှုံးသော ပို့ဆောင်မှုများကို သင်က ကိုယ်တိုင် သို့မဟုတ် script ဖြင့် ပြန်ပို့ရမည် |
| တုံ့ပြန်ချိန် | 2xx အောင်မြင်ကုဒ်ကို အမြန် ပြန်ပြီး နှေးကွေးသော အလုပ်မလုပ်မီ | ၁၀ စက္ကန့်ထက် ကြာသော ပို့ဆောင်မှုကို ကျရှုံးသည်ဟု သတ်မှတ်သည် |
Stripe ၏ စာရွက်စာတမ်းအရ အဖြစ်အပျက်များသည် ဖြစ်ပေါ်သော အစဉ်အတိုင်း ရောက်ရန် အာမမခံပါ၊ တစ်ခါတစ်ရံ အဖြစ်အပျက်တစ်ခုသည် နှစ်ကြိမ် ရောက်လာနိုင်သဖြင့် event ID များကို ခြေရာခံရန် အကြံပြုသည်။
ယေဘုယျသင်ခန်းစာမှာ provider မည်သည်ဖြစ်ဖြစ် အဖြစ်အပျက်များသည် နောက်ကျ၊ နှစ်ကြိမ် နှင့် အစဉ်ပြောင်း ရောက်နိုင်သည်။ သင့် handler သည် idempotent ဖြစ်သင့်သည် — တူညီသော အဖြစ်အပျက်ကို နှစ်ကြိမ် လုပ်ဆောင်သည့်အခါ တစ်ကြိမ်တည်း လုပ်ဆောင်သကဲ့သို့ ရလဒ် တူညီရမည်။
ဥပမာ: ပေးချေထားသော သင်တန်းကို ဖွင့်ပေးခြင်း
သင်သည် အွန်လိုင်း သင်တန်းကို ရောင်းသည်။ ကျောင်းသားတစ်ဦးသည် Buy ကို နှိပ်ပြီး Stripe ၏ hosted checkout စာမျက်နှာတွင် ပေးချေကာ သင့်ဆိုက်သို့ ပြန်ရောက်သည်။
အားနည်းသော နည်းလမ်း: "ကျေးဇူးတင်ပါသည်" စာမျက်နှာက သင်တန်းကို ဖွင့်ပေးသည်။ redirect အတွင်း ကျောင်းသားသည် browser ကို ပိတ်လိုက်ပါက ပေးချေပြီးသော်လည်း ဝင်ခွင့် မရှိပါ။ ကျေးဇူးတင်စာမျက်နှာ URL ကို တစ်ယောက်ယောက် ခန့်မှန်းပါက ပေးချေခြင်းမရှိဘဲ ဝင်ခွင့် ရသည်။
Webhook နည်းလမ်း:
- Stripe က ငွေပေးချေမှု အတည်ပြုသည့်အခါ
/webhooks/stripeသို့checkout.session.completedအဖြစ်အပျက်ကို ပို့သည်။ - သင့် backend က signing secret ဖြင့် signature ကို စစ်ဆေးသည်။ မကိုက်ညီပါက
400ပြန်ပြီး ဘာမျှ မလုပ်ပါ။ - ထို event ID ကို ယခင်က လုပ်ပြီးပြီလား စစ်သည်။ ဟုတ်ပါက
200ပြန်ပြီး ရပ်သည်။ - event ID ကို သိမ်းပြီး
200ပြန်ကာ ကျောင်းသားကို ဝင်ခွင့်ပေးပြီး ကြိုဆိုအီးမေးလ် ပို့သည်။ - ကျေးဇူးတင်စာမျက်နှာက "ငွေပေးချေမှု ရရှိပြီး — သင်တန်းသည် ခဏအတွင်း ပေါ်လာမည်" ဟု ပြပြီး ကျောင်းသား၏ ဝင်ခွင့်အခြေအနေကို စစ်သည်။
နောက်ပိုင်း subscription ကို ပယ်ဖျက်ခြင်း သို့မဟုတ် ကတ် ကျရှုံးခြင်းဖြစ်လျှင် အခြား webhook အဖြစ်အပျက်များက အက်ပ်ကို ဝင်ခွင့် ဖယ်ရှား သို့မဟုတ် ခဏရပ်ရန် ပြောသည်။ subscription ထုတ်ကုန်များ billing နှင့် ကိုက်ညီစွာ ရှိနေပုံ ဖြစ်သည် — SaaS ဆိုတာ ဘာလဲ နှင့် အက်ပ်တွင် ငွေပေးချေမှု ထည့်နည်း ကို ကြည့်ပါ။
သော့ချက် ဝေါဟာရများ
- Endpoint: webhook များ လက်ခံသော အက်ပ်ရှိ URL။
- Event / payload: ဘာဖြစ်ခဲ့သလဲနှင့် ၎င်းကို ဖော်ပြသော data (များသောအားဖြင့် JSON)။
- Signing secret: လက်မှတ် စစ်ဆေးရန် မျှဝေသော လျှို့ဝှက်ချက်။
- Idempotent: တူညီသော ရလဒ်ဖြင့် တစ်ကြိမ်ထက်ပို run ရန် လုံခြုံသည်။
- Polling: webhook ကို စောင့်မည့်အစား ပြောင်းလဲမှုများကို API မှ ထပ်ခါထပ်ခါ မေးခြင်း။
- Tunnel: development အတွင်း webhook များ ရောက်နိုင်ရန် laptop ကို ယာယီ public URL ပေးသော ကိရိယာ။
အဖြစ်များသော အမှားများနှင့် အယူအဆမှားများ
- Signature မစစ်ခြင်း။ endpoint URL သည် လျှို့ဝှက်ချက် မဟုတ်ပါ။ စစ်ဆေးမှုသာ request ကို ယုံကြည်စေသည်။
- တုံ့ပြန်မီ ပင်ပန်းသော အလုပ်လုပ်ခြင်း။ အီးမေးလ် ပို့ခြင်း သို့မဟုတ် PDF ဖန်တီးခြင်းကို မတုံ့ပြန်မီ လုပ်ပါက timeout ဖြစ်ပြီး ပြန်ကြိုးစားမှု၊ ထို့နောက် ထပ်တူများ ဖြစ်စေသည်။
- တစ်ကြိမ်တည်း၊ အစဉ်လိုက် ဟု ယူဆခြင်း။ event ID များကို မှတ်တမ်းတင်ပြီး ရောက်ရှိသည့် အစဉ်ကို မှီခိုမနေပါနှင့်။
- Preview URL သုံးခြင်း။ webhook များသည် တည်ငြိမ်သော public လိပ်စာ လိုအပ်သည်။ private preview နှင့်
localhostသို့ အင်တာနက်မှ မရောက်နိုင်ပါ; ထုတ်ပြန်ထားသော URL (သို့မဟုတ် စမ်းသပ်စဉ် tunnel) ကို သုံးပါ။ - Test နှင့် live secret များ ရောသုံးခြင်း။ Provider များသည် test နှင့် live mode အတွက် signing secret ကွဲပြားစွာ ပေးလေ့ရှိသည်။ နှစ်ခုလုံးကို သိမ်းပြီး မှန်ကန်သည်ကို သုံးပါ။
- အရေးကြီးဆုံး ဆုံးဖြတ်ချက်များအတွက် payload ကို မေးမြန်းမှုမရှိဘဲ ယုံခြင်း။ အန္တရာယ်မြင့်သော လုပ်ဆောင်ချက်များအတွက် အဖြစ်အပျက် လက်ခံပြီးနောက် provider ၏ API မှ နောက်ဆုံး state ကို ပြန်ယူခြင်းသည် သင့်လျော်သည်။
AI builder ကို ဘာတောင်းရမလဲ
POST /webhooks/stripeendpoint ကို ဆာဗာတွင် ထည့်ပါ။ Stripe signature ကို raw request body နှင့်STRIPE_WEBHOOK_SECRETsecret ဖြင့် စစ်ပါ။ မမှန်သော signature ကို 400 ဖြင့် ပယ်ပါ။ event ID တစ်ခုစီကို သိမ်းပြီး ယခင် လုပ်ပြီးသား event များကို ကျော်ပါ။ အမြန် 200 ပြန်ပြီးcheckout.session.completedကို အော်ဒါကို ပေးချေပြီးဟု မှတ်ပြီး ပြေစာပို့ခြင်းဖြင့် ကိုင်တွယ်ပါ။ Event အမျိုးအစားကို log လုပ်ပါ။ Checkout success စာမျက်နှာမှ ဝင်ခွင့် မပေးပါနှင့်။
ထို့နောက် စမ်းကြည့်ပါ: provider ၏ dashboard မှ test event ပို့ပါ၊ တူညီသည်ကို ထပ်ပို့ပါ၊ မှားသော signature ဖြင့် request ပို့ပါ။ ပထမတစ်ခုသာ တစ်စုံတစ်ခုကို ပြောင်းလဲသင့်သည်။
Mythex ရှိ Webhook များ
Mythex တွင် webhook ဝန်ဆောင်မှု သီးခြား မရှိပါ။ သင့်အက်ပ်၏ ကိုယ်ပိုင် backend တွင် webhook endpoint ထည့်ရန် agent ကို တောင်းပြီး provider ကို သင့် publish လုပ်ထားသော URL သို့ ညွှန်ပြပါ၊ webhook များသည် public လိပ်စာ လိုအပ်သောကြောင့်ဖြစ်သည်။ signing secret ကို project secrets တွင် ထည့်ပြီး live အက်ပ်တွင် ပြောင်းလျှင် ထပ် publish လုပ်ပါ။ docs ရှိ webhooks ကို ကိုင်တွယ်ခြင်း recipe တွင် starter prompt ရှိပြီး ငွေပေးချေမှု လက်ခံသော အက်ပ်များအတွက် store templates က စတင်ရန် ကောင်းသည်။
မေးခွန်းများ
Webhook ဆိုတာ ရိုးရိုးရှင်းရှင်း ဘာလဲ?
Webhook ဆိုတာ ငွေပေးချေမှု အောင်မြင်ခြင်း သို့မဟုတ် ဖောင်ပို့ခြင်းကဲ့သို့ တစ်ခုခု ဖြစ်ပေါ်သည့်အခါ ဝန်ဆောင်မှုတစ်ခုက သင့်အက်ပ်ရှိ web address သို့ ပို့သော အလိုအလျောက် မက်ဆေ့ချ်ဖြစ်သည်။ အက်ပ်က အရာအားလုံး ပြောင်းခဲ့သလား မေးနေမည့်အစား အခြားဝန်ဆောင်မှုက သင့်ကို အသိပေးသည်။
Webhook နှင့် API ကွာခြားချက် ဘာလဲ?
API ခေါ်ဆိုမှုတွင် သင့်အက်ပ်က အခြားဝန်ဆောင်မှုကို တစ်ခုခု မေးပြီး အဖြေရသည်။ Webhook တွင် အဖြစ်အပျက် ဖြစ်သည့်အခါ အခြားဝန်ဆောင်မှုက သင့်အက်ပ်ကို ခေါ်သည်။ အများစု integration များသည် နှစ်မျိုးလုံး သုံးသည် — အဖြစ်အပျက်များ သိရန် webhook၊ အသေးစိတ် ယူရန် သို့မဟုတ် လုပ်ဆောင်ရန် API ခေါ်ဆိုမှု။
Webhook များ လုံခြုံပါသလား?
စစ်ဆေးပါက လုံခြုံနိုင်သည်။ ကောင်းမွန်သော provider များသည် သင်နှင့်သာ မျှဝေသော လျှို့ဝှက်ချက်ဖြင့် မက်ဆေ့ချ်တစ်ခုစီကို လက်မှတ်ထိုးပြီး၊ သင့်အက်ပ်သည် လက်မှတ် မကိုက်ညီသော request ကို ငြင်းပယ်ရမည်။ ထိုစစ်ဆေးမှု မရှိပါက URL ကို တွေ့သူ မည်သူမဆို အတု အဖြစ်အပျက်များ ပို့နိုင်သည်။
Webhook ပို့ချိန်တွင် ကျွန်ုပ်၏အက်ပ် ပိတ်ထားလျှင် ဘာဖြစ်မလဲ?
Provider အပေါ် မူတည်သည်။ ဥပမာ Stripe သည် live mode တွင် ရက်သုံးရက်အထိ မအောင်မြင်သော ပို့ဆောင်မှုများကို ပြန်ကြိုးစားသည်။ GitHub သည် အလိုအလျောက် ပြန်မကြိုးစားဘဲ သင်က ပြန်ပို့ရမည်ဟု မျှော်လင့်သည်။ provider တစ်ခုစီ၏ စာရွက်စာတမ်းကို စစ်ပြီး နောက်ကျသော သို့မဟုတ် ထပ်တူ အဖြစ်အပျက်များကို ကိုင်တွယ်နိုင်အောင် handler ကို ဒီဇိုင်းလုပ်ပါ။