Русский
Українська
ქართული
English
Қазақша
Español
Français
Deutsch
Italiano
فارسی
Հոդվածի ֆոկուսը
QR կոդը մուտք է վճարման սցենար, և ոչ միայն նկար
QR կոդը պետք է պարունակի վճարման նպատակ, գումար, նպատակակետ, ստացող և վերջնական կարգավիճակի հստակ կանոն:
Սրճարանում, առաքման, սպասարկման բիզնեսում կամ միջոցառման ժամանակ QR կոդը հաճախ ընկալվում է որպես հաճախորդին վճարման էջը ցույց տալու արագ միջոց: Բայց տեխնիկապես սա նույն վճարման սցենարն է, ինչ checkout կայքում. դուք պետք է հասկանաք, թե ով է վճարում ստանում, ինչի դիմաց, ինչ արժույթով և ինչպես է բիզնեսը պարզում վերջնական կարգավիճակը:
Եթե QR-ը տանում է միայն ստատիկ էջ՝ առանց սովորական վճարման մտադրության, օպերատորը պետք է ձեռքով որոնի վճարումը՝ ըստ գումարի, ժամանակի և հաճախորդի մեկնաբանության: Սա արագորեն փչանում է բազմաթիվ վճարումների, հերթափոխի, սուրհանդակների, հուշումների կամ վճարման կրկնվող փորձերի հետ:
- QR-ը պետք է հանգեցնի կառավարվող վճարման մտադրության կամ վճարման էջին.
- նպատակակետը, գումարը և ստացողը պետք է պահպանվեն հետին պլանում.
- վերջնական կարգավիճակը պետք է գա սերվերի կողմից, և ոչ միայն հաճախորդի էկրանից.
- Աջակցության համար ձեզ անհրաժեշտ է տեղեկանք, որը կարող եք գտնել CRM կամ ամսագրում:
Ի՞նչ կարգավիճակներ են անհրաժեշտ օֆլայն կետի համար:
Գանձապահին կամ մենեջերին անհրաժեշտ է պարզ պատասխան՝ վճարված, սպասող ստուգում, սխալ կամ ձեռքով վերլուծության կարիք:
Անցանց հրամանը չպետք է կարդա չմշակված մատակարարի կարգավիճակը: Նրան անհրաժեշտ է նորմալացված կարգավիճակ. վճարումը ստեղծվել է, pending, վճարված, ձախողված, ժամկետանց կամ ձեռքով վերանայում: Հատկապես կարևոր է pending-ն առանձնացնել և վճարել, քանի որ հաճախորդը կարող է ցույց տալ վերադարձի էկրանը նախքան հետին մասի վերջնական հաստատումը:
Առաքման և ծառայությունների համար օգտակար է պահել վճարման հղումը պատվերի, սուրհանդակի, գրասեղանի, մասնաճյուղի, աշխատողի կամ ապրանքագրի հետ: Այնուհետև վիճելի վճարումը կարող է արագ վերականգնվել՝ ելնելով համատեքստից, այլ ոչ թե մեսենջերում նամակագրության միջոցով:
- մի տրամադրեք ծառայություն միայն հաճախորդի սքրինշոթի հիման վրա.
- ցույց տալ օպերատորի վերջին ստուգումը և մատակարարի տեղեկանքը.
- պատվերի, թեյավճարի և նվիրատվության առանձին վճարում;
- գրանցել ձեռքով հաստատում պատասխանատու անձի հետ:
Ինչպես փակել օրը՝ օգտագործելով QR վճարումները
QR վճարումները պետք է ներառվեն նույն համաձայնեցման մեջ, ինչ կայքը, CRM հաշիվները և բջջային վճարումները:
Եթե QR վճարումները ներառված չեն ամենօրյա հաշտեցման մեջ, դրանք դառնում են առանձին ձեռքով ալիք: Հաշվապահական հաշվառման բաժինը տեսնում է գումարը մատակարարից կամ բանկից, մենեջերը տեսնում է պատվերը CRM-ում, և գործառնական թիմը միշտ չէ, որ հասկանում է, թե որ վճարումները փակված են:
Աշխատանքային մոդել. յուրաքանչյուր QR վճարում ունի վաճառողի ID, մասնաճյուղի ID, թիրախային ID, գումար, արժույթ, մատակարարի տեղեկանք, վերջնական կարգավիճակ և ժամանակի դրոշմ: Համակարգն ավտոմատ կերպով փակում է համընկնումները և անհամապատասխանություններ ուղարկում բացառման ցուցակ:
- հաշտեցնել QR վճարումները այլ ալիքների հետ.
- պահել մասնաճյուղ, աշխատող, պատվեր կամ հանձնարարություն.
- առանձին հաշվի առնել խորհուրդները, նվիրատվությունները և հաշիվ-ապրանքագրերի վճարումները.
- բացառությունների ցանկ կազմեք ձեռքով վերլուծության համար:
FAQ
Հնարավո՞ր է արդյոք օգտագործել մեկ QR ծածկագիր բոլոր վճարումների համար:
Դա հնարավոր է պարզ սցենարի համար, բայց ավելի լավ է, որ backend-ը ստեղծի կամ սահմանի վճարման մտադրություն՝ նպատակակետով, գումարով և ստացողով: Հակառակ դեպքում, հաշտեցումը արագ դառնում է ձեռքով:
Հաճախորդի սքրինշոթը բավարա՞ր է վճարումը հաստատելու համար:
Ոչ: Սքրինշոթը հարմար է հաղորդակցության համար, սակայն բիզնեսի կարգավիճակը պետք է հաստատվի սերվերի կողմից կարգավիճակով, webhook կամ ստուգմամբ մատակարարի հետ:
Ինչպե՞ս հաշվի առնել խորհուրդներն ըստ QR-ի:
Ավելի լավ է բաժանել հուշումները պատվերի վճարումից՝ պահել ստացողին, մասնաճյուղը, գումարը, միջնորդավճարը, վճարման կարգավիճակը և կապը սկզբնական վճարման հետ, եթե այդպիսիք կան:
