Your FREE payments lab is launching soon. Get ready to experiment. 🧪

The Card Payments Simulator is coming to PayZillion.com!

Simulate real-world ATM, POS, and E-commerce transaction scenarios. Then, instantly dive deep into the complete backend record—from high-level transaction logs to the raw, decoded ISO 8583 messages.

It's the ultimate FREE tool for learning how payments really flow.

#Payments #Fintech #ISO8583 #PaymentsTech #ComingSoon

Here’s a quick look of PayZillion FREE Card Payments Simulator! 💳

Watch how an ATM transaction actually happens 👀

#Payments #Fintech #ISO8583 #PaymentsTech #ComingSoon

Ever wonder what happens behind the scenes when you swipe your card? 💳

FREE payment simulator dropping soon - see ATM, POS & e-commerce in action!

Coming very soon 👀

#Fintech #Payments #CardPayments #ISO8583 #ATM #POS #Ecommerce

၂၀၂၅ ခုနှစ် ကုန်ဖို့ တစ်လခွဲပဲလိုတော့တာဆိုတော့ နှစ်မကုန်ခင် "Payments Made Simple" လို့ အမည်ပေးထားတဲ့ 40-day series လေးကို တစ်နေ့တစ်ပုဒ်ရေးပြီး တင်ပေးဖို့ စီစဉ်ထားပါတယ်။ Page မှာရော website မှာရော မနက်ဖြန်ကနေစပြီး တင်ပေးပါမယ်။ အရင် content တွေကနေ ထူခြားတာကတော့ ဒီတစ်ခါမှာ digital dayments တွေအကြောင်းကို ထိထိမိမိနဲ့ တိုတိုရှင်းရှင်းနဲ့ ရေးပေးထားမှာ ဖြစ်ပါတယ်။

နောက်ထပ် update သတင်းနှစ်ခုပေးဖို့ ရှိတာကတော့ Educational Card Payments Simulator ကို launch လုပ်ဖို့ရယ်၊ Card Payment Professional စာအုပ်ကို 2nd edition ထုတ်ပေးဖို့ရယ်ပါ။ ဒီနှစ်ခုလည်း ၂၀၂၅ မကုန်ခင် ရပါမယ်။

Simulator က educational simulator ဖြစ်ပါတယ်။ Simulator ကို သုံးပြီး ATM ၊ POS ၊ Ecommerce terminal/app တွေ ဘယ်လို အလုပ်လုပ်တယ်ဆိုတာကို system point of view ကနေရော end-user တစ်ယောက်လိုပါ experience လုပ်လို့ရမှာပါ။ End-to-end transaction flow တွေ၊ authorization transaction record တွေနဲ့ back-end log (ISO 8583) တွေကို transaction တစ်ခုချင်းစီအလိုက် နောက်ကွယ်က သက်ဆိုင်ရာ system တွေမှာ စစ်ရသလို experience ရအောင် စီစဉ်ထားပါတယ်။ Simulator က အားလုံးကို totally FREE ပေးသုံးပါမယ်။

Card Payments Professional စာအုပ်အတွက်ကတော့ 1st edition တုန်းက ထုတ်ပေးလိုက်တဲ့အချိန်တုန်းက ထပ်ထည့်ချင်တဲ့ content တွေ ရှိသေးသလို၊ မူလ content outline မှာ ထည့်ထားပေမယ့် စိတ်တိုင်းမကျလို့ ချန်ထားခဲ့တာတွေလည်း ရှိခဲ့ပါတယ်။ ဒီတစ်ခါမှာ စာအုပ်ကို ပိုပြီး ပြည့်စုံအောင်၊ ပိုပြီး အသုံးဝင်အောင် restructure နဲ့ upgrade သေချာ လုပ်ပေးထားပါတယ်။ စာအုပ်က 2nd edition မှာလည်း e-book ပဲရဦးမှာဖြစ်ပြီး ၄၈,၀၀၀ ကျပ် (12 USD) နဲ့ ရောင်းပေးပါမယ်။ အထူးအစီအစဉ်အနေနဲ့ 1st edition မှာ ဝယ်ယူထားသူတိုင်းကို 2nd edition မှာ အခမဲ့ email ကနေ စာအုပ်ပို့ပေးဖို့ စီစဉ်ထားပါတယ်။ အဲ့ဒီအတွက် ဘာမှလုပ်ဖို့မလို့ပါဘူး။ အရင်ဝယ်တုန်းက order မှာပါတဲ့ email အတိုင်းပဲ ပို့ပေးမှာဖြစ်လို့ စာအုပ် ready ဖြစ်တာနဲ့ email ရပါလိမ့်မယ်။ အခုမှ ဝယ်မယ့်သူတွေကတော့ 2nd edition ထွက်တဲ့အခါကျ ကြေညာပေးပါမယ်။

Day 1 - Digital Payment အားလုံးအတွက် အရေးကြီးအင်္ဂါရပ်-၅-ချက်

ကတ် (card) ၊ QR ၊ wallet နဲ့ ဘယ် digital payment မှာမဆို အရေးကြီးတဲ့ အင်္ဂါရပ်-၅-ချက် ရှိပါတယ်။ အဲ့ဒီထဲက တစ်ခုခု မပြည့်စုံတာနဲ့ ငွေပေးချေမှု လုပ်ဆောင်နိုင်မှာ မဟုတ်ပါ။

(၁) A valid payment instrument
ငွေပေးချေဖို့အတွက် အမှန်တကယ် အသုံးပြုနိုင်တဲ့ ကတ်အချက်အလက် (card details) ၊ wallet balance ၊ ဘဏ်အကောင့် (bank account) အစရှိသဖြင့် payment instrument တစ်ခုခုရှိရပါမယ်။

(၂) A channel to capture the request
ငွေပေးချေမှုဆိုင်ရာ အချက်အလက် (payment data) တွေကို ရယူပို့ဆောင်ဖို့အတွက် POS terminal ၊ QR scanner ၊ mobile app ၊ e-commerce website/app အစရှိသဖြင့် channel တစ်ခုခု လိုအပ်ပါတယ်။

(၃) A processor to route the transaction
ရရှိထားတဲ့ အချက်အလက်တွေကို စစ်ဆေးပြီး သက်ဆိုင်ရာစနစ်ဆီကို ပို့ဆောင်ပေးမယ့် ဘဏ် (bank) ၊ payment gateway ၊ payment switch အစရှိသဖြင့် လိုအပ်ပါတယ်။

(၄) A decision from the payer’s side
ကတ်ထုတ်ဝေသူ (issuer) ၊ wallet provider အစရှိတဲ့ သက်ဆိုင်ရာစနစ်တွေကနေ ငွေပေးချေမှုကို "လက်ခံတယ်" (approve) သို့မဟုတ် "ငြင်းပယ်တယ်" (decline) ဆိုပြီး အတည်ပြု ဆုံးဖြတ်ပေးရပါတယ်။

(၅) A settlement path
ငွေပေးချေမှု အောင်မြင်ပြီးနောက်မှာတော့ ကုန်သည် (merchant) အတွက် အမှန်တစ်ကယ် ငွေကြေးလက်ခံရရှိနိုင်ဖို့ ညွှန်ကြားချက် (instructions) တွေ ထားရှိလုပ်ဆောင်ပေးရပါတယ်။

ဒီအင်္ဂါရပ်-၅-ချက်ကို သိထားမယ်ဆိုရင် ဘယ်ငွေပေးချေမှုနည်းလမ်းအတွက်မဆို payment flow တစ်ခုလုံး ဘယ်လိုအလုပ်လုပ်သွားသလဲဆိုတာကို အလွယ်တကူ သဘော‌ပေါက်နိုင်ပါလိမ့်မယ်။

ဒီ post ကတော့ 40-day “Payments Made Simple” series ရဲ့ day 1 အတွက် ဖြစ်ပါတယ်။ အခုလိုပဲ payment ဆိုင်ရာ အကြောင်းအရာတွေကို တိုတိုရှင်းရှင်းနဲ့ လက်တွေ့အသုံးဝင်အောင် တစ်နေ့တစ်ပုဒ် တင်ပေးသွားပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 2 - ဒီဂျစ်တယ်ငွေပေးချေမှုတွေရဲ့ Money Movement သဘောတရား

ဒီဂျစ်တယ်ငွေပေးချေမှုတွေ ပြုလုပ်တဲ့အခါ သာမန်အားဖြင့် ငွေပေးချေလိုက်တာနဲ့ ချက်ချင်း ပြီးသွားတယ်လို့ ထင်ရပါတယ်။ တကယ်တမ်းကျတော့ ကတ်နဲ့ tap လုပ်လိုက်တာ၊ QR scan ဖတ်လိုက်တာ၊ payment button ကို နှိပ်လိုက်တာနဲ့ ငွေက ကုန်သည် (merchant) ဆီကို ချက်ချင်း ရွှေ့ပြောင်းသွားတာ မဟုတ်ပါဘူး။

ငွေပေးချေမှု transaction တိုင်းမှာ အသုံးပြုလိုက်တဲ့ ငွေပေးချေမှုနည်းလမ်း (POS terminal ၊ QR/wallet app ၊ ecommerce website/app အစရှိသဖြင့်) ကနေ အချက်အလက်တွေကို payment processor ဆီ ပို့လိုက်ပါတယ်။ Processor က စစ်ဆေးပြီး ငွေပေးချေသူရဲ့ဘဏ် သို့မဟုတ် သက်ဆိုင်ရာ provider ဆီကို ဆက်ပြီး ပေးပို့လိုက်ပါတယ်။ အဲ့ဒီမှာ သက်ဆိုင်ရာဘဏ် ၊ provider တို့က ငွေပေးချေသူမှာ လက်ကျန်ငွေ လုံလောက်မှုရှိမရှိ၊ ပေးချေခွင့်ရှိမရှိ စစ်ဆေးဆုံးဖြတ်ပြီး "လက်ခံတယ်" (approve) သို့မဟုတ် "ငြင်းပယ်တယ်" (decline) ဆိုပြီး အကြောင်းပြန်ပါတယ်။ အသုံးပြုသူ end-user တစ်ယောက်အနေနဲ့ ဒီအဆင့်ထိပဲ မြင်နိုင်မှာပါ။

အဲ့ဒီအဆင့်ပြီးလို့ နာရီပိုင်း (သို့မဟုတ်) နောက်ရက်မှာမှ settlement လို့ခေါ်တဲ့ အမှန်တကယ် ငွေကြေးလွှဲပြောင်းပေးတဲ့ အဆင့်ကို လုပ်ဆောင်မှာ ဖြစ်ပါတယ်။ အဲ့ဒီတော့မှ ကုန်သည် (merchant) ရဲ့ အကောင့်ထဲကို ငွေဝင်မှာ ဖြစ်ပါတယ်။ ကုန်သည် (merchant) နဲ့ ချိတ်ဆက်ထားတဲ့ service provider ၊ အသုံးပြုထားတဲ့ ငွေပေးချေမှု နည်းလမ်းပေါ် မူတည်ပြီး တစ်ရက်၊ နှစ်ရက်၊ တစ်ပတ် အစရှိသဖြင့် စောင့်ဆိုင်းပြီးမှ ငွေဝင်မှာ ဖြစ်ပါတယ်။

ရိုးရိုးရှင်းရှင်း ပြောရရင် ချက်ချင်းပြီးသွားတဲ့အပိုင်းက authorization လို့ခေါ်တဲ့ ငွေပေးချေမှု ခွင့်ပြုပေးခြင်း သက်သက်သာဖြစ်ပြီး၊ အမှန်တစ်ကယ် ငွေကြေးလွှဲပြောင်းရရှိမှု အပိုင်းကတော့ settlement လုပ်ဆောင်ပြီးမှ ရရှိမှာ ပြီးစီးမှာ ဖြစ်ပါတယ်။

“Payments Made Simple” 40-day series day 2 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 3 - Wallet Balance နဲ့ Bank Balance တွေရဲ့ မတူညီမှု

Wallet အကောင့်တွေနဲ့ ဘဏ်အကောင့်တွေဟာ အကောင့်ထဲမှာ ငွေသိမ်းဆည်းထားနိုင်တာမှာ တူညီပေမယ့် အလုပ်လုပ်ပုံခြင်းတော့ လုံးဝ မတူပါဘူး။

Bank Balance ဆိုတာ သက်ဆိုင်ရာ ဘဏ်ရဲ့ငွေစာရင်းအကောင့်မှာ အပ်နှံထားတဲ့ ငွေကြေးဖြစ်ပါတယ်။ ဘဏ်ငွေစာရင်းအကောင့်နဲ့ ချိတ်ဆက်ထားတဲ့ internet banking ၊ mobile banking တို့ကနေ ငွေပေးချေလိုက်လိုက်တဲ့အခါ ဘဏ်က အပ်နှံထားတဲ့အကောင့်ရဲ့ လက်ကျန်ငွေကို တိုက်ရိုက်စစ်ဆေးပြီး "လက်ခံတယ်" (approve) သို့မဟုတ် "ငြင်းပယ်တယ်" (decline) ဆိုတာကို ဆုံးဖြတ်ပေးပါတယ်။

Wallet Balance ဆိုတာကတော့ wallet ဝန်ဆောင်မှုပေးသူ (wallet provider) ရဲ့ စနစ်ထဲမှာ သိမ်းဆည်းထားတဲ့တန်ဖိုး (stored value) သာ ဖြစ်ပါတယ်။ ကြိုတင်ဖြည့်သွင်းထားတဲ့ငွေ သို့မဟုတ် အခြားငွေကြေး source တစ်ခုခုနဲ့ ချိတ်ဆက်ထားတာ ဖြစ်နိုင်ပါတယ်။ Wallet တွေဟာ ငွေပေးချေမှု (transaction) တွေကို အတည်ပြုတဲ့အခါ ဘဏ်လက်ကျန်ငွေကို မကြည့်ဘဲ သူတို့ wallet စနစ်ထဲက လက်ကျန်ငွေကိုပဲ ကြည့်ပြီး ဆုံးဖြတ်ပါတယ်။

ဒါကြောင့် wallet နဲ့ ငွေပေးချေရတဲ့အခါ ပိုမိုမြန်ဆန်ပြီး ရိုးရှင်းနေတာ ဖြစ်ပါတယ်။ စစ်ဆေးရမယ့် အဆင့်တွေ ပိုနည်းပြီး အရာအားလုံးက wallet system တစ်ခုတည်း အတွင်းပဲ ပြီးသွားလို့ပါ။ ဒါပေမယ့် wallet တွေမှာ ဘဏ်အကောင့်တွေနဲ့ မတူတဲ့ ငွေကြေးပမာဏ ကန့်သတ်ချက် (limits) တွေ၊ စည်းမျဉ်းစည်းကမ်းတွေ ရှိတတ်ပါတယ်။ Wallet ထဲမှာ ထည့်သွင်းနိုင်တဲ့ ငွေကြေးပမာဏ ကန့်သတ်ချက်ရှိတာ၊ အသုံးပြုခွင့် limit မှာ သတ်မှတ်ချက် ပိုရှိနေတာမျိုးပေါ့။

အခုပြောထားတဲ့ သဘောတရားတွေကို သိထားမယ်ဆိုရင် မတူညီတဲ့ ငွေပေးချေမှုနည်းလမ်းတွေရဲ့ သဘောသဘာဝနဲ့ payment flow တွေကို ပိုပြီး နာလည်နိုင်ဖို့ အထောက်အကူ ဖြစ်ပါလိမ့်မယ်။

“Payments Made Simple” 40-day series day 3 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 4 - ဘဏ်၊ Payment Provider နဲ့ Aggregator တွေ ဘာကွာသလဲ

ဘဏ်တွေ၊ payment provider တွေနဲ့ aggregator တွေဟာ ငွေပေးချေမှုလုပ်ငန်းစဉ်မှာ အတူတကွ ပါဝင်ကြရပေမယ့် သူတို့ရဲ့ လုပ်ဆောင်ပုံတွေ မတူညီကြပါဘူး။

ဘဏ်တွေကတော့ အသုံးပြုသူတွေရဲ့ ငွေကြေးကို အမှန်တကယ် ထိန်းသိမ်းထားရသူ၊ ဘဏ်ကောင့်တွေကို စီမံခန့်ခွဲသူ ဖြစ်ပါတယ်။ ရိုးရိုးရှင်းရှင်းပြောရရင် ငွေကြေးကို အမှန်တကယ် ထိန်းချုပ်ထားတာ ဘဏ်တွေ ဖြစ်ပါတယ်။

Payment provider (gateway, PSPs, QR operator, wallet operators) တွေကတော့ merchant သို့မဟုတ် app တွေနဲ့ ဘဏ်စနစ်တွေကို ချိတ်ဆက်ပေးဖို့၊ ငွေပေးချေမှုဆိုင်ရာ အချက်အလက်တွေ ဖလှယ်ပေးဖို့ အစရှိသဖြင့် လုပ်ဆောင်ကြပါတယ်။

Aggregator တွေကတော့ payment provider ထဲမှာပါဝင်ပြီး merchant တွေအတွက် payment service အမျိုးမျိုးကို တစ်နေရာတည်းမှာ စုစည်းချိတ်ဆက်နိုင်ဖို့ စနစ်ထောက်ပံ့ ပေးထားတဲ့ ဝန်ဆောင်မှု ဖြစ်ပါတယ်။ Merchant တွေအနေနဲ့ ဘဏ်တွေ၊ payment provider တွေ အများကြီးကို တစ်ခုချင်း ချိတ်ဆက်နေစရာမလိုဘဲ aggregator ကို ချိတ်ဆက်လိုက်တာနဲ့ မတူညီတဲ့ ငွေပေးချေမှုနည်းလမ်းတွေကို လက်ခံနိုင်မှာ ဖြစ်ပါတယ်။ Integration နဲ့ onboarding လုပ်ရာမှာ single point of connection ကိုပဲ ချိတ်ဆက်ဖို့ လိုအပ်တော့မှာဖြစ်လို့ အချိန်ကုန်၊ ငွေကုန် သက်သာသွားစေပါတယ်။

ဒီလောက်ဆိုရင်တော့ payment ecosystem တွေထဲမှာ ဘယ်သူက ဘာတာဝန်ယူထားရသလဲ ဆိုတာကို ရှင်းရှင်းလင်းလင်း ဖြစ်သွားပါပြီ။

“Payments Made Simple” 40-day series day 4 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 5 - ဒီဂျစ်တယ်ငွေပေးချေမှုတိုင်းရဲ့ အဆင့်-၅-ဆင့်

ကတ်၊ QR ၊ wallet ဘယ်ငွေပေးချေမှုနည်းလမ်းမဆို သဘောတရားအားဖြင့် ငွေပေးချေမှုလုပ်ဆောင်တဲ့အခါမှာ အခုပြောပြမယ့် အဆင့်တွေအတိုင်းပဲ အလုပ်လုပ်ပါတယ်။

အဆင့် (၁) - Capture
POS စက်မှာ ကတ်ကို tap လုပ်တာ၊ QR ကုဒ်ကို scan ဖတ်တာ၊ payment ခလုတ်နှိပ်လိုက်တာ အစရှိသဖြင့် ပြုလုပ်ပြီး ဝယ်ယူသူဆီက ငွေပေးချေမယ့် အချက်အလက်တွေ ရယူပါတယ်။

အဆင့် (၂) - Route
Payment Processor ၊ gateway ၊ switch တို့ကနေတဆင့် ရရှိလာတဲ့ အချက်အလက်တွေကို ကတ်ထုတ်ပေးထားတဲ့ဘဏ်၊ wallet provider အစရှိတဲ့ သက်ဆိုင်ရာဆီကို ပို့ပေးလိုက်ပါတယ်။

အဆင့် (၃) - Decide
ငွေပေးချေသူ (payer’s side) ရဲ့ စနစ်ကနေပြီး လက်ကျန်ငွေ၊ အသုံးပြုခွင့် ကန့်သတ်ချက်နဲ့ သံသယဖြစ်စရာ fraud ဖြစ်နိုင်ခြေရှိမရှိ စစ်ဆေးပြီး ‌ငွေပေးချေမှုကို လက်ခံမယ်၊ လက်မခံဘူး ဆုံးဖြတ်ပေးပါတယ်။

အဆင့် (၄) - Confirm
အဲ့ဒီ ဆုံးဖြတ်ချက်ကို merchant ဆီကို ချက်ချင်း ပြန်ပို့ပေးလိုက်ပါတယ်။ ငွေပေးချေသူအတွက် ပေးချေတာ အောင်မြင်ခဲ့ရင် ဒီအဆင့်မှာ merchant ဆီကနေ ဝန်ဆောင်မှု ရရှိမှာ ဖြစ်ပါတယ်။

အဆင့် (၅) - Settle
Merchant အနေနဲ့ အမှန်တကယ်‌ ငွေလက်ခံရရှိဖို့ကတော့ settlement ပြုလုပ်ပြီး စာရင်းရှင်းပြီးတဲ့ အခါမှာမှ ချိတ်ဆက်ထားတဲ့ payment provider ဆီကနေ လက်ခံရရှိမှာပါ။

ဒီဂျစ်တယ်ငွေပေးချေမှုနည်းစနစ်တိုင်းလိုလိုမှာ ဒီအဆင့်သဘောတရားတွေအတိုင်း လုပ်ဆောင်တာမို့ အခုအဆင့်တွေနဲ့ သဘောတရားကို သိထားရင် စနစ်တိုင်းကို လွယ်ကူစွာ နားလည်နိုင်ပါလိမ့်မယ်။

“Payments Made Simple” 40-day series day 5 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 6 - Online နဲ့ In-Store Payments ရဲ့ မတူကွဲပြားပုံ

Online ဖြစ်တဲ့ အင်တာနက်ပေါ်မှာ စျေးဝယ်တာနဲ့ in-store ဖြစ်တဲ့ စျေးဆိုင်မှာ စျေးဝယ်တာတွေမှာ ငွေပေးချေတဲ့အခါ တူသလိုလိုနဲ့ ခြားနားနေတဲ့ နောက်ကွယ်က လုပ်ဆောင်ပုံတွေကို သိထားဖို့ လိုပါတယ်။

စျေးဆိုင်မှာ ကတ်ကို tap လုပ်တာ၊ QR scan ဖတ်တာမျိုးတွေမှာ POS terminal လိုမျိုး physical device ကို အသုံးပြုပါတယ်။ အဲ့ဒီ POS စက်ကနေ card data အစရှိသဖြင့် လိုအပ်တဲ့ အချက်အလက်တွေကို စစ်ဆေးပါတယ်။ အဲ့ဒီနောက် encrypt လုပ်ပြီး acquirer ရဲ့ စနစ်ကနေတဆင့် issuer ဆီကို သက်ဆိုင်ရာ ကွန်ရက်ကနေ အသုံးပြုခွင့် တောင်းခံလိုက်ပါတယ်။ ဝယ်ယူသူကိုယ်တိုင် ဆိုင်မှာရှိနေတာ ဖြစ်တဲ့အတွက် လုပ်ဆောင်ရတာ ရိုးရိုးရှင်းရှင်းပါပဲ။

အင်တာနက်ပေါ်မှာ စျေးဝယ်တာကျတော့ ecommerce website နဲ့ app တွေကနေတဆင့် card ၊ wallet အချက်အလက် စတာတွေကို ရယူပြီး လုပ်ဆောင်ရပါတယ်။ ငွေပေးချေသူက ဆိုင်မှာ လူကိုယ်တိုင်ရှိနေတာ မဟုတ်တဲ့အတွက် ဆုံးရှုံးနိုင်ခြေ risk နည်းစေဖို့ OTP ၊ 3D Secure နဲ့ device check တာလို အတည်ပြုနည်းလမ်းတွေကို ထပ်ဆောင်း အသုံးပြုကြရပါတယ်။ Online စနစ်တွေဖြစ်လို့ IP address ၊ browser အမျိုးအစားနဲ့ transaction patterns တွေကိုပါ ထည့်သွင်းစစ်ဆေးလေ့ ရှိကြပါတယ်။

နောက်အဆင့်မှာတော့ online ပဲဖြစ်ဖြစ် in-store ပဲဖြစ်ဖြစ် ငွေပေးချေမှုကို issuer ၊ wallet provider အစရှိတဲ့ payer’s side မှ provider ကနေပြီး အသုံးပြုခွင့်ပြုတယ်၊ မပြုဘူးဆိုတဲ့ဆုံးဖြတ်ချက် ချပေးခြင်း authorization ကို လုပ်ပါတယ်။ Authorization ရလဒ်ပေါ်မူတည်ပြီး merchant ဆီကို ငွေကြေးလွှဲပြောင်းပေးဖို့ လုပ်ဆောင်ရတဲ့ clearing နဲ့ settlement process ကို လုပ်ဆောင်ပါတယ်။ ဒီအဆင့်တွေမှာတော့ online ပဲ ဖြစ်ဖြစ် in-store ပဲ ဖြစ်ဖြစ် အတူတူပါပဲ။

“Payments Made Simple” 40-day series day 6 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 7 - Clearing နဲ့ Settlement က အတူတူပဲလား

ငွေပေးချေမှုနဲ့ ပတ်သတ်လာရင် clearing နဲ့ settlement ကို အတူတွဲပြီး ပြောကြလေ့ရှိပေမယ့် တစ်ခုတည်း မဟုတ်ပါဘူး၊ clearing ပြီးမှ settlement လုပ်ရတာ ဖြစ်ပါတယ်။

Clearing ဆိုတာကတော့ ဘဏ်တွေ သို့မဟုတ် payment provider တွေကြားမှာ ‌transaction ဆိုင်ရာ၊ ငွေပေးချေမှုဆိုင်ရာ အချက်အလက် data တွေကို ဖလှယ်တဲ့ အဆင့်ဖြစ်ပါတယ်။ ငွေပမာဏ၊ အချိန်၊ merchant ရဲ့ အချက်အလက်၊ ဝန်ဆောင်ခတွေနဲ့ ဘယ်သူက ဘယ်သူ့ကို ဘယ်လောက်ပေးရမယ်ဆိုတဲ့ အကြောင်းအရာတွေ ပါဝင်ပါတယ်။ ဒီအဆင့်မှာ ငွေကြေးလွှဲပြောင်းမှု မဖြစ်သေးပါဘူး။ အချက်အလက်ဖြစ်တဲ့ data တွေပဲ ဖလှယ်မှာ ဖြစ်ပါတယ်။

Settlement ဆိုတာကတော့ အဲ့ဒီ clearing ကနေ ရလာတဲ့ အချက်အလက်တွေအပေါ် မူတည်ပြီး အဖွဲ့အစည်းတွေကြားမှာ အမှန်တကယ် ငွေကြေး လွှဲပြောင်းပေးတဲ့အဆင့် ဖြစ်ပါတယ်။ Merchant နဲ့ သက်ဆိုင်ရာ party တွေအနေနဲ့ ဒီအဆင့်ရောက်မှသာ ကိုယ့်အကောင့်ထဲကို ငွေအမှန်တကယ် ရောက်ရှိမှာ ဖြစ်ပါတယ်။
အလွယ်ပြောရရင် clearing ဆိုတာ ကျသင့်ငွေစာရင်း bill နဲ့ သဘောတရားတူညီပြီး၊ settlement ကတော့ အဲ့ဒီ bill အတွက် ငွေအမှန်တကယ် ပေးချေခြင်း၊ ရရှိခြင်း သဘောတရားနဲ့ ဆင်တူပါတယ်။

ငွေပေးချေတဲ့အခါ အသုံးပြုသူ end-user တွေအနေနဲ့ authorization အဖြေကိုပဲ ချက်ချင်း မြင်တွေ့ရမှာပါ။ clearing နဲ့ settlement လုပ်ငန်းစဉ်တွေ အတွက်ကတော့ မြင်နိုင်သိနိုင်မှာ မဟုတ်ပါဘူး။ ငွေပေးချေမှု အောင်မြင်ပြီးတော့မှ နောက်ကွယ်မှာ ဆက်လက်လုပ်‌ဆောင်တဲ့ process တွေ ဖြစ်တာမို့ပါ။ ဒီအချက်ကို နားလည်ထားမယ်ဆိုရင် merchant တွေဆီကို ငွေစာရင်းရှင်းပေးခြင်းနဲ့ အကြောင်းအရာတွေကို ကိုင်တွယ်ရတဲ့အခါမှာ အထောက်အကူ ဖြစ်ပါလိမ့်မယ်။

“Payments Made Simple” 40-day series day 7 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 8 – Payments Failure အများစုဟာ ဒီအချက်တွေကြောင့်ပါ

ငွေပေးချေမှု အများစုမှာ failed ဖြစ်စေတဲ့ အကြောင်းအရင်းက ယေဘုယျအားဖြင့် နည်းနည်းပဲ ရှိတာပါ။

(၁) လက်ကျန်ငွေ မလုံလောက်တာ
(၂) PIN နဲ့ OTP တွေ မှားရိုက်မိတာ
(၃) ကတ်နံပါတ်၊ CVV နဲ့ expiry တွေ မှားရိုက်မိတာ၊ ကတ်သက်တမ်းကုန်နေတာ
(၄) လက်ကျန်ငွေရှိသော်လည်း daily/weekly/monthly နဲ့ transaction limit ပြည့်နေတာ
(၅) System တွေကြား connection ပြုတ်နေတာ၊ network ပြဿနာရှိနေတာ
(၆) ကတ် ၊ wallet နဲ့ payment အကောင့်တွေ locked/blocked ဖြစ်နေတာ
(၇) Fraud rule တွေ၊ risk setting တွေနဲ့ ငြိနေတာ၊ သံသယဖြစ်ခံရတာ
(၈) Merchant နဲ့ terminal setup တွေ၊ configuration တွေ မှားယွင်းနေတာ

များသောအားဖြင့် ဒီအကြောင်းအရာတွေကြောင့်ပဲ ဖြစ်လေ့ရှိပါတယ်။ ငွေပေးချေမှုတွေကို စစ်ဆေးရတဲ့အခါ ဒီအချက်တွေကို အရင်ဆုံး စစ်ဆေးသင့်ပါတယ်။ ဒါဆို ပြဿနာတော်တော်များများမှာ technical detailed အထိ စစ်ဖို့မလိုအပ်တော့ဘဲ customer service နဲ့ 1st level support မှာတင် အလွယ်တကူ ဖြေရှင်းနိုင်ပါလိမ့်မယ်။

“Payments Made Simple” 40-day series day 8 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 9 - တူသလိုလိုနဲ့ ကွဲပြားတဲ့ Void ၊ Refund နဲ့ Reversal တွေအကြောင်း

Void ၊ Refund နဲ့ Reversal transaction အမျိုးအစားတွေ အားလုံးက ငွေပေးချေသူ customer ကို ငွေပြန်ပေးတာချင်း အတူတူပေမယ့် အသုံးပြုရတဲ့ အခြေအနေတွေ မတူညီပါဘူး။

Void transaction အမျိုးအစားကတော့ ငွေပေးချေမှု transaction တစ်ခုအတွက် settled မလုပ်ရသေးတဲ့ အခြေအနေမှာ cancel ပြန်လုပ်တာ ဖြစ်ပါတယ်။ ငွေပေးချေမှု လုပ်ဆောင်တဲ့နေ့နဲ့ void က တစ်ရက်တည်း ဖြစ်လေ့ရှိပြီး settlement လုပ်ပြီးသွားရင်တော့ void ကို အသုံးပြုလို့ မရတော့ပါ။

Refund ကတော့ merchant တွေအနေနဲ့ settlement ပြုလုပ်ပြီး ငွေလက်ခံရရှိပြီးတဲ့ အခြေအနေမှာ အသုံးပြုပါတယ်။ Merchant အနေနဲ့ ပိုက်ဆံကို လက်ခံရရှိပြီး ဖြစ်တဲ့အတွက် void လုပ်လို့မရတော့ပါ။ Refund transaction ကိုသုံးပြီး ငွေပြန်အမ်းပေးရမှာ ဖြစ်ပါတယ်။ Settlement ပြီးမှ refund လုပ်ပေးနိုင်တာဖြစ်တဲ့အတွက် void လိုမျိုး ချက်ချင်းမရဘဲ အချိန်ပိုကြာလေ့ရှိပါတယ်။

Reversal ကတော့ အကြောင်းတစ်ခုခုကြောင့် customer ကို ဝန်ဆောင်မှုလည်း မပေးနိုင်တဲ့ အခြေအနေမှာ ငွေပေးချေမှု authorization ကို ပြန်လည်ပြင်ဆင်တဲ့ transaction အမျိုးအစား ဖြစ်ပါတယ်။ များသောအားဖြင့် timeout နဲ့ system failure တွေ ဖြစ်တဲ့အခါတွေမှာ reversal transaction ကို အသုံးပြုပြီး ငွေပေးချေသူဆီက authorized လုပ်ထားတဲ့ငွေကို release ပြန်လုပ်ပေးပါတယ်။ Void နဲ့ မတူတာက void မှာ transaction ကို manual cancel လုပ်ပေးတာဖြစ်ပြီး၊ reversal မှာတော့ အလိုအလျောက် release လုပ်ပေးတာ ဖြစ်ပါတယ်။

“Payments Made Simple” 40-day series day 9 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 10 - Card ၊ Wallet နဲ့ QR Payment များ အကြောင်း

ကတ်နဲ့ ငွေပေးချေတဲ့အခါ merchant အတွက် ကတ်လက်ခံနိုင်ဖို့ ဆောင်ရွက်ပေးတဲ့ acquirer နဲ့ ကွန်ရက်ပံ့ပိုးပေးသူ card network တွေကနေတဆင့် ကတ်ထုတ်ဝေသူ issuer ဆီ အချက်အလက်တွေ ပို့ဆောင်ပေးပါတယ်။ Issuer ကနေပြီး balance ၊ limits နဲ့ risk အစရှိတာတွေကို စစ်ဆေးပြီး transaction ကို ခွင့်ပြုပေးပါတယ်။

Wallet နဲ့ ငွေပေးချေတာမှာတော့ အကောင့်နံပါတ် ဖုန်းနံပါတ်သုံးပြီး peer-to-peer ငွေပေးချေတာ၊ ငွေပေးချေသူနဲ့ merchant ကြား တူညီတဲ့ wallet provider ကိုပဲ အသုံးပြုလို့ရတဲ့ wallet-specific QR သုံးပြီး ငွေပေးချေတာ၊ မတူညီတဲ့ wallet provider တွေကြား ချိတ်ဆက်ပြီး interoperate လုပ်နိုင်တဲ့ QR standard (ဥပမာ - MMQR) သုံးပြီး ငွေပေးချေတာ အစရှိသဖြင့် ပေးချေကြပါတယ်။

နောက်တစ်ပိုင်းမှာတော့ transaction flow တွေအကြောင်းကို ဆက်ပြီးတော့ ပြောပါမယ်။

“Payments Made Simple” 40-day series day 10 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 11 - ကတ်၊ Wallet နဲ့ MMQR Transaction Flow စီးဆင်းပုံ

ငွေပေးချေမှုနည်းလမ်းတိုင်းမှာ ပုံမှန်အားဖြင့် request ၊ routing ၊ approval နဲ့ posting ဆိုတဲ့ အဆင့်တွေကို လုပ်ဆောင်ကြရပါတယ်။ ဒီတစ်ခါတော့ ကတ်နဲ့ QR payment တွေအတွက် ယေဘုယျ transaction flow ကို မျှဝေပေးပါမယ်။

(၁) Card Payment Flow

🔁 Cardholder (Tap/Insert/Swipe) → Merchant POS → Acquirer → Card Network → Issuer

ကတ်နဲ့ ငွေပေးချေတဲ့အခါမှာ merchant POS စက်ကနေပြီး transaction request ကို acquirer ဆီ ပို့ပေးပါတယ်။ အဲ့ဒီနောက် acquirer ကနေ card network ကိုဖြတ်ပြီး issuer ဆီ ပို့ပေးလိုက်ပါတယ်။ Issuer က ရရှိလာတဲ့ အချက်အလက်တွေကို စစ်ဆေးပြီး အသုံးပြုခွင့်ပြုမယ်၊ မပြုဘူးဆိုတာ ချက်ချင်း respond ပြန်ပေးပါတယ်။ ငွေပေးချေမှု အောင်မြင်ခဲ့ရင် cardholder က ဝယ်ယူတဲ့ပစ္စည်း ရပါပြီ။ Merchant အတွက် ငွေကတော့ clearing နဲ့ settlement တွေပြီးမှ ရမှာဖြစ်ပါတယ်။

(၂) QR Payment Flow

🔁 Merchant POS (Display QR) → Payer App (Scan & Pay) → Issuer → National QR Switch → Acquirer → Merchant POS (Notify)

National QR Switch (ဥပမာ - MMQR) လို မတူညီတဲ့ provider တွေကြား interoperate လုပ်နိုင်တဲ့ network အသုံးပြုထားတဲ့ wallet နဲ့ QR ငွေ‌ပေးချေမှုတွေမှာတော့ ပထမဆုံး အဆင့်အနေနဲ့ merchant POS ကနေ QR code ကို ထုတ်ပြီး customer ကို ပြပါတယ်။ Customer က wallet သို့မဟုတ် payment app ကနေ scan ဖတ်ပြီး ငွေပေးချေပါတယ်။ အဲ့ဒီမှာ issuer (wallet/payment app provider) ကနေ အသုံးပြုခွင့်ပြုမယ်၊ မပြုဘူး ဆုံးဖြတ်ပေးပါတယ်။ အဲ့ဒီ ဆုံးဖြတ်ချက် response ကို national QR switch ကနေတစ်ဆင့် acquirer ဆီ၊ acquirer ကနေတစ်ဆင့် merchant POS ဆီကို notify ပြန်လုပ်ပေးပါတယ်။ ဒါဆိုရင်တော့ customer အတွက် ငွေပေးချေခြင်း ပြီးဆုံးပါပြီ။ ကတ်နဲ့ငွေပေးချေတာမှာလိုပဲ merchant အတွက် ငွေကတော့ clearing နဲ့ settlement တွေပြီးမှ ရမှာဖြစ်ပါတယ်။

ဒီနေရာမှာ သိထားရမှာက အသုံးပြုတဲ့ network ကွန်ရက်၊ channel (ATM, POS, Ecommerce) နဲ့ payment service provider တွေအပေါ်မူတည်ပြီး transaction flow ဟာ အမြဲတမ်း တစ်သမတ်တည်း ဖြစ်နေမှာ မဟုတ်ပါဘူး။ ယေဘုယျ သဘောတရားကို သိထားခြင်းဖြင့် မတူညီတဲ့ ချိတ်ဆက်လုပ်ဆောင်မှုတွေကို ကိုင်တွယ်တဲ့အခါမှာ အလွယ်တကူနားလည်နိုင်ဖို့ အထောက်အကူဖြစ်ပါလိမ့်မယ်။

“Payments Made Simple” 40 day series - day 11 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 12 - Issuer ၊ Acquirer နဲ့ Payment Scheme ဆိုတာ

ဒီတစ်ခါတော့ ငွေပေးချေမှုတိုင်းမှာ အဓိက ပါဝင်သူတွေဖြစ်တဲ့ issuer ၊ acquirer နဲ့ payment scheme တွေ အကြောင်းကို ဆက်ပြီး ဖော်ပြပေးလိုက်ပါတယ်။

Issuer သို့မဟုတ် payer’s payment service provider ကတော့ ကတ်၊ wallet ၊ mobile အစရှိသဖြင့် ငွေပေးချေမှုအတွက် အသုံးပြုတဲ့ payment instruments တွေ provide လုပ်ပေးထားတဲ့ ဘဏ် သို့မဟုတ် ငွေကြေးအဖွဲ့အစည်း ဖြစ်ပါတယ်။ ငွေပေးချေမှု transaction တိုင်းမှာ အသုံးပြုနိုင်တဲ့ balance ငွေပမာဏ၊ ကန့်သတ်မှု limits တွေနဲ့၊ fraud rules တွေ၊ account status တွေပေါ်မူတည်ပြီး approve သို့မဟုတ် decline လုပ်ပေးပါတယ်။

Acquirer သို့မဟုတ် payee’s payment service provider ကတော့ merchant အတွက် ငွေပေးချေမှု လက်ခံနိုင်စေဖို့ ဝန်ဆောင်မှုပေးတဲ့ ဘဏ် သို့မဟုတ် ငွေကြေးအဖွဲ့အစည်း ဖြစ်ပါတယ်။ POS စက်၊ online နဲ့ mobile channel အစရှိတာတွေကနေ ငွေပေးချေမှု transaction တွေကို လက်ခံရယူပြီး ချိတ်ဆက်ထားတဲ့ ကွန်ရက်ဖြစ်တဲ့ payment scheme ဆီကို ပို့ဆောင်ပေးပါတယ်။

Payment scheme ကတော့ issuer နဲ့ acquirer တွေကြားမှာ transaction တွေ လုပ်ဆောင်နိုင်စေဖို့ infrastructure နဲ့ လုပ်ထုံးလုပ်နည်း စည်းမျဉ်းစည်းကမ်းတွေကို ချပေးတဲ့၊ ချိတ်ဆက်ပေးတဲ့ အဖွဲ့အစည်းဖြစ်ပါတယ်။ Issuer နဲ့ acquirer တွေကြား ငွေစာရင်းရှင်းနိုင်ဖို့ clearing ကိုလည်း လုပ်ဆောင်ပေးပါတယ်။

“Payments Made Simple” 40 day series - day 12 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 13 - ငွေပေးချေမှု အောင်မြင်ပြီးနောက် Merchant တွေ ပိုက်ဆံဘယ်လိုရသလဲ

Digital payment တွေနဲ့ ငွေပေးချေတဲ့အခါမှာ customer က ငွေရှင်းလိုက်တာနဲ့ merchant က ချက်ချင်း ပိုက်ဆံမရပါဘူး။ ဖြတ်သန်းရတဲ့ အဆင့်တွေရှိပါတယ်။

(၁) Payment Capture အဆင့်
POS စက်၊ ecommerce app အစရှိသဖြင့် payment channel တွေကနေ transaction data ကို ရယူပြီး acquirer ဆီ ပို့ပါတယ်။ ပြီးတော့ ချိတ်ဆက်ထားတဲ့ payment network ကနေတစ်ဆင့် issuer ဆီကို ပို့ပေးပါတယ်။

(၂) Authorization အဆင့်
Customer အနေနဲ့ ငွေပေးချေနိုင်စွမ်းနဲ့ ငွေပေးချေခွင့် ရှိ၊ မရှိကို issuer က စစ်ဆေးပါတယ်။ ပြီးတော့ "Approved" သို့မဟုတ် "Declined" ဆိုပြီး ချက်ချင်း respond ပြန်ပေးပါတယ်။

(၃) Batch Submission နဲ့ Clearing အဆင့်
"Approved" ဖြစ်ခဲ့တဲ့ transaction တွေအတွက် transaction amount ၊ ငွေပေးချေတဲ့အချိန် အစရှိသဖြင့် transaction data တွေကို submission နဲ့ clearing လုပ်ပါတယ်။

(၄) Settlement အဆင့်
အဲ့ဒီနောက်မှာတော့ issuer ဘက်ကနေ merchant အကောင့်ထဲကို ငွေအမှန်တစ်ကယ် ရွေ့လျားရောက်ရှိတဲ့ အဆင့်ဖြစ်ပါတယ်။ Merchant အနေနဲ့ ဝန်ဆောင်ခတွေ နှုတ်ယူထားပြီး ကျန်ရှိတဲ့ ငွေပမာဏကို သက်ဆိုင်ရာ ချိတ်ဆက်ထားတဲ့ acquirer ဆီကနေ လက်ခံရှိရှိမှာ ဖြစ်ပါတယ်။

“Payments Made Simple” 40 day series - day 13 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 14 – Digital Wallet တွေ ငွေဖြည့်တာ၊ ငွေထုတ်တာ

ငွေဖြည့်ခြင်း (Adding money)
- Digital wallet တွေကို ငွေဖြည့်တဲ့အခါ နည်းလမ်း ၃-မျိုးနဲ့ ငွေဖြည့်လို့ရပါတယ်။ ပထမဆုံးနည်းလမ်းက နီးစပ်ရာ wallet agent သို့မဟုတ် အခြားသူတစ်ယောက်ရဲ့ wallet balance ကနေ ငွေထည့်ပေးတာ ဖြစ်ပါတယ်။ နောက်တစ်နည်းက wallet ထဲကို ခွင့်ပြုထားတဲ့ ဘဏ်အကောင့်ကနေ ငွေလွှဲပြီး ထည့်တာဖြစ်ပါတယ်။ နောက်တစ်နည်းက debit ကတ်၊ credit ကတ် အစရှိတဲ့ ကတ်တွေကနေ top-up လုပ်ပြီး ငွေထည့်တာ ဖြစ်ပါတယ်။

ငွေထုတ်ခြင်း (Withdrawing money)
- Wallet တွေကနေ ငွေထုတ်ဖို့မှာလည်း နည်းလမ်း ၃-မျိုးနဲ့ ထုတ်လို့ရပါတယ်။ ပထမဆုံးနည်းလမ်းက နီးစပ်ရာ wallet agent ကနေ ငွေထုတ်တာပါ။ ‌နောက်တစ်နည်းက အဲ့ဒီ wallet နဲ့ ချိတ်ဆက်ထားတဲ့ ဘဏ်ရဲ့ ATM မှာ ငွေထုတ်တာပါ။ ‌နောက်တစ်နည်းကတော့ wallet နဲ့ ချိတ်ဆက်ထားတဲ့ ဘဏ်အကောင့်ထဲကို ငွေလွှဲထည့်တာပါ။ Wallet agent ဆီမှာ ငွေထုတ်တာနဲ့ ATM မှာ ငွေထုတ်တာတွေမှာ ငွေသားထုတ်ယူနိုင်မှာပေမယ့်၊ ဘဏ်အကောင့်ထဲကို ငွေလွှဲထည့်မယ်ဆိုရင်တော့ digital money အနေနဲ့ပဲရမှာပါ။ ဒါပေမယ့် ဘဏ်အကောင့်ထဲကို ငွေရောက်သွားတာဖြစ်တဲ့အတွက် ဘဏ်မှာ ငွေသွားထုတ်လို့ရသလို အဲ့ဒီ ဘဏ်အကောင့်နဲ့ ချိတ်ဆက်ထားတဲ့ ATM တွေမှာလည်း debit ကတ်နဲ့ ငွေသားအလွယ်တကူ ထုတ်ယူလို့ရပါတယ်။

“Payments Made Simple” 40 day series - day 14 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 15 - Digital Payment ရဲ့ Tokenization ဆိုတာ...

Tokenization ဆိုတာ ပေါက်ကြားလို့မရတဲ့ sensitive ဖြစ်တဲ့ ကတ်၊ wallet နဲ့ ဘဏ်အကောင့်စတဲ့ အချက်အလက်တွေကို လုံခြုံပြီး unique ဖြစ်တဲ့ token နဲ့ အစားထိုး သုံးစွဲတာ ဖြစ်ပါတယ်။ Token ကို အသုံးပြုပြီး ငွေပေးချေတဲ့အခါမှာ ကတ်အချက်အလက်၊ wallet အချက်အလက် အစရှိတာတွေကို တိုက်ရိုက် သိမ်းဆည်ထိတွေ့စရာ မလိုအပ်တော့ပါဘူး။ တစ်ချိန်ချိန်မှာ token အခိုးခံရတာ၊ ပေါက်ကြားတာ ဖြစ်လာခဲ့ရင်လည်း token data တွေဟာ ကတ်၊ wallet တွေရဲ့ အချက်အလက်အစစ်တွေ မဟုတ်တာမို့ ခိုးယူသူလက်ထဲမှာ အသုံးမဝင်ပါဘူး။

Tokenization အလုပ်လုပ်ပုံကတော့ တကယ့် ကတ်၊ wallet နံပါတ်တွေ၊ အချက်အလက်တွေကို issuer သို့မဟုတ် provider ဆီမှာပဲ လုံခြုံစွာ သိမ်းဆည်းထားပါတယ်။ အသုံးပြုမယ့် device ၊ app နဲ့ merchant တစ်ခုချင်းစီအတွက် သီးသန့် token တစ်ခုစီ ထုတ်ပေးထားပါတယ်။ ငွေပေးချေတဲ့အချိန်မှာ အဲ့ဒီ token ကိုပဲ အသုံးပြုပြီး transaction ပြုလုပ်မှာဖြစ်ပြီး အချက်အလက် အစစ်တွေကို အသုံးမပြုပါဘူး။ Issuer နဲ့ provider တွေဆီ transaction ရောက်သွားတဲ့အခါကျမှ အဲ့ဒီ token နဲ့ ချိတ်ဆက်ထားတဲ့ ကတ်၊ အကောင့်အချက်အလက်တွေကို provider ကနေ သိရှိပြီး transaction ကို အတည်ပြုပေးမှာ ဖြစ်ပါတယ်။

Tokenization ကို အသုံးပြုတာကြောင့် user တွေရဲ့ အချက်အလက် credential တွေ ပေါက်ကြားနိုင်ခြေကို လျှော့ချပေးပါတယ်။ ခိုးယူသုံးစွဲခံရနိုင်ခြေ fraud risk လည်း နည်းသွားပါတယ်။ အွန်လိုင်း၊ မိုဘိုင်း app တွေနဲ့ wallet တွေမှာ ငွေပေးချေမှုတွေကို လုံခြုံစိတ်ချ ရစေပါတယ်။ Stored payment method တွေကို အသုံးပြုပြီး user တွေရဲ့ ကတ်၊ wallet အကောင့်အချက်အလက် စတာတွေကို merchant တွေ၊ app တွေဆီမှာ အချက်အလက် အစစ်တွေကို ထိတွေ့စရာမလိုဘဲ လုံခြုံစိတ်ချစွာ သိမ်းဆည်းနိုင် ပေးချေနိုင်စေပါတယ်။

“Payments Made Simple” 40 day series - day 15 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 16 – ငွေပေးချေရာမှာ အကောင့်ပိုင်ရှင်ကို အတည်ပြုဖို့ အသုံးပြုတဲ့ နည်းလမ်းများ

ကတ်၊ wallet ၊ internet banking ၊ mobile banking အစရှိသဖြင့် digital payments တွေနဲ့ ငွေပေးချေတဲ့အခါ အသုံးပြုသူတွေကို ကတ်၊ အကောင့်ပိုင်ရှင် စစ်မှန်ကြောင်း အတည်ပြုနိုင်ဖို့ စစ်ဆေးတဲ့ အဆင့်တွေ ရှိတတ်ပါတယ်။ အသုံးများတဲ့ နည်းလမ်းတွေကတော့ –

(၁) OTP (One-Time Password) – တစ်ခါသုံးလျှို့ဝှက်နံပါတ်ဖြစ်ပြီး SMS ၊ email နဲ့ app တွေကနေ ပို့ပေးပါတယ်။ ကုဒ်နံပါတ်ကို မှန်ကန်စွာ ရိုက်ထည့်ပြီး အတည်ပြုပေးရပါမယ်။

(၂) PIN (Personal Identification Number) – ကတ်၊ wallet နဲ့ digital payment တွေနဲ့ ငွေပေးချေတဲ့အခါ ရိုက်ထည့်နိုင်ဖို့ ကြိုတင်သတ်မှတ်ထားတဲ့ လျှို့ဝှက်ကုဒ် ဖြစ်ပါတယ်။ ကုဒ်နံပါတ်ကို မှန်ကန်စွာ ရိုက်ထည့်ပြီး အတည်ပြုပေးရပါမယ်။

(၃) Biometrics – Fingerprint ၊ face recognition အစရှိသဖြင့် အသုံးပြုတဲ့စက်၊ ဖုန်းကို အသုံးပြုပြီး ဇီဝအချက်အလက်နဲ့ စစ်ဆေးတာ ဖြစ်ပါတယ်။

(၄) App-based approval – ငွေပေးချေသူရဲ့ app ဆီကို push notification ပို့ပေးပြီး ငွေပေးချေမှုကို အတည်ပြုခိုင်းတာ ဖြစ်ပါတယ်။

ဒီနည်းလမ်းတွေနဲ့ လိမ်လည်မှု fraud ဖြစ်နိုင်ခြေ၊ ကတ်၊ အကောင့်တွေ ခိုးယူသုံးစွဲခံရနိုင်ခြေ အစရှိတဲ့ အန္တရာယ်တွေကနေ လျှော့ချပေးပါတယ်။ ငွေပေးချေမှုတိုင်းမှာတော့ အဲ့ဒီလို စစ်ဆေးမှာ မဟုတ်ပါဘူး။ ငွေပမာဏ များတာ၊ သံသယဖြစ်စရာ risk ရှိတာနဲ့ transaction အမျိုးအစားအပေါ် မူတည်ပြီး လိုအပ်တဲ့ အခြေအနေတွေအတွက်ပဲ စစ်ဆေးမှာ ဖြစ်ပါတယ်။

“Payments Made Simple” 40 day series – day 16 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 17 - Merchant များ ဖြစ်လေ့ဖြစ်ထရှိတဲ့ ပြဿနာများ

Merchant တွေအတွက် ငွေပေးချေမှု လက်ခံရမှာ ဖြစ်လေ့ဖြစ်ထရှိတဲ့ ပြဿနာလေးတွေကတော့

(၁) Merchant တွေဆီမှာ approved ဖြစ်ခဲ့တဲ့ transaction တွေအတွက် ငွေမဝင်တာပါ။ များသောအားဖြင့် settlement မှာ delay ကြောင့် ဖြစ်နိုင်ပါတယ်။ Settlement files တွေ process လုပ်ပြီးမပြီးနဲ့ cut-off လုပ်တဲ့ အချိန်တွေ စစ်ဆေးရပါမယ်။

(၂) ငွေပေးချေမှု တစ်ခုအတွက် ဝယ်သူဆီမှာ ငွေနှစ်ခါ ဖြတ်မိတာပါ။ ငွေပေးချေမှုလုပ်တဲ့ အချိန်မှာ timeout ဖြစ်သွားတာကြောင့် တစ်ကြိမ်ထက်ပိုပြီး ငွေပေးချေဖို့ reattempt တွေ လုပ်မိတာကြောင့် ဖြစ်နိုင်ပါတယ်။ Multiple attempt လုပ်မိတာအတွက် reversal ဖြစ်ထားတာ ရှိမရှိနဲ့ duplicate authorization လုပ်ခဲ့မိတာ ရှိမရှိ စစ်ဆေးရပါမယ်။

(၃) Transaction မအောင်မြင်ဘဲ ငွေပေးချေသူရဲ့ ကတ်၊ အကောင့်တွေထဲကနေ ပိုက်ဆံလျော့သွားတာပါ။ Issuer သို့မဟုတ် provider တွေဆီမှာ ငွေကို on-hold ဖြစ်နေတာ ဖြစ်နိုင်ပါတယ်။ Reversals သို့မဟုတ် void လုပ်လိုက်ရင် အဆင်ပြေသွားတတ်ပါတယ်။

(၄) ဝယ်သူက QR scan ဖတ်လိုက်ပေမယ့် merchant ဆီမှာ ငွေပေးချေမှု အောင်မြင်ကြောင်း ပေါ်မလာတာပါ။ Callback နောက်ကျနေတာ ဖြစ်နိုင်ပါတယ်။ Provider system ရဲ့ notification logs တွေကို စစ်ဆေးကြည့်ပါ။

(၅) POS စက် လိုင်းမတက်တာပါ။ Merchant သို့ဟုတ် acquirer ဆီမှာ network ကွန်ရက် သို့မဟုတ် system issue ရှိနေတာကြောင့် ဖြစ်နိုင်ပါတယ်။ Network နဲ့ system တွေ ပုံမှန်အခြေအနေရှိမရှိ စစ်ဆေးကြည့်ပါ။

“Payments Made Simple” 40 day series - day 17 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices