Русский
Українська
ქართული
English
Қазақша
Español
Français
Deutsch
Italiano
فارسی
Հոդվածի ֆոկուսը
Ինչու Facebook Messenger-ն մնում է վաճառքի ալիք
Հաճախորդը հաճախ գրում է բիզնեսին Էջի մուտքի արկղում, պարզաբանում է պատվերի մանրամասները և ակնկալում է ստանալ վճարման հստակ ձև՝ առանց բարդ կայք այցելելու:
Տեղական խանութների, առաքումների, սրահների, առցանց դպրոցների, սպասարկման ընկերությունների և B2B կապալառուների համար Facebook-ի էջը և Messenger-ը մնում են որպես վաճառքի աշխատանքային կետ: Հաճախորդը տեսնում է հրապարակում, գովազդ կամ առաջարկություն, գրում է հաղորդագրություն, պարզաբանում է գինը, հասանելիությունը, չափը, առաքման հասցեն, հանդիպման ժամը կամ ծառայության կազմը և սպասում է արագ հաջորդ քայլին:
Կարևոր է չբնութագրել Facebook Messenger-ին որպես բանկային վճարումների անմիջական մշակման համակարգ: Ճիշտ մոդելը տարբեր է. մենեջերը, բոտը կամ backend-ը ստեղծում է վճարման հղում, հաճախորդը բացում է անվտանգ checkout էջ, վճարում է, և բիզնեսը ստանում է հաստատված վճարման կարգավիճակ webhook-ի կամ սերվերի կողմից կարգավիճակի որոնման միջոցով:
Այս մոտեցումը հարմար է, երբ լիարժեք e-commerce դեռ անհրաժեշտ չէ կամ պատվերը պահանջում է նամակագրություն: Կառավարիչը կարող է համաձայնեցնել մանրամասները Messenger-ում, սակայն ֆինանսական կարգավիճակը չպետք է ապրի հաղորդագրություններում, այլ հետնամասում, CRM կամ վճարման մատյանում՝ order_id, գումար, արժույթ AMD, հաճախորդի նույնացուցիչ, մատակարարի տեղեկանք, payAt և վերջնական բիզնես գործողություն:
- Facebook-ի էջը և Messenger-ը մնում են payment link-ի հաղորդակցման և ներկայացման ալիք;
- վճարումը կատարվում է անվտանգ checkout էջում, և ոչ թե նամակագրության ներսում.
- backend-ը կապում է order_id-ի, գումարի, արժույթի և հաճախորդի հետ;
- պատվերի, մուտքի կամ առաքման հաստատումը տեղի է ունենում ստուգված կարգավիճակից հետո:
Ինչպես է աշխատում payment link ֆեյսբուքյան էջից
Հղումը կարելի է ձեռքով ուղարկել երկխոսությունից հետո կամ ստեղծել դինամիկ API-ի միջոցով, եթե գումարները, ապրանքները և պայմանները տարբեր են:
Պարզ MVP-ն կարող է սկսել ֆիքսված հղումներով՝ կանխավճար խորհրդատվության համար, ավանդ հանդիպման համար, առաքում, հայտնի ապրանք, դասերի փաթեթ կամ ստանդարտ ծառայություն: Կառավարիչը ընտրում է անհրաժեշտ հղումը, այն ուղարկում Messenger և գրանցում է պատվերը աղյուսակում կամ CRM:
Եթե պատվերները եզակի են, ապա ավելի լավ է օգտագործել API: Backend-ը վճարման հարցում է ստեղծում order_id-ով, գումարով, արժույթով AMD, ժամկետի ավարտով, հաճախորդի ID-ով, ալիքով, պատվերի նկարագրությամբ և CRM-ի մետատվյալներով: Դրանից հետո հղումը հաճախորդին ուղարկվում է ձեռքով մենեջերի կողմից՝ ավտոմատացման միջոցով կամ բոտի սկրիպտի միջոցով։
Վճարումից հետո VPOS-ն ուղարկում է webhook: Backend-ը ստուգում է ստորագրությունը կամ վստահելի կարգավիճակի որոնում, ստուգում է order_id-ը, գումարը, արժույթը, կարգավիճակը և անգործունակության բանալին, այնուհետև թարմացնում է պատվերը: Միայն դրանից հետո կարող եք թույլ տալ մուտք գործել դասընթաց, հաստատել հայտը, սկսել առաքումը, փոխել գործարքի կարգավիճակը Bitrix24/amoCRM-ում կամ ուղարկել ստուգաթերթ օպերատորին:
- ֆիքսված հղումները հարմար են փորձնական և ստանդարտ ծառայությունների համար.
- Եզակի պատվերների և գումարների համար անհրաժեշտ են դինամիկ հղումներ API-ի միջոցով.
- ժամկետանցությունը պաշտպանում է հին կամ այլևս ոչ համապատասխան հղման համար վճարելուց.
- webhook-ն փակում է պատվերը սերվերի կողմից ստուգումից հետո;
- CRM-ը ձեռքով մեկնաբանության փոխարեն ստանում է նորմալացված վճարման իրադարձություն:
Ինչն է կարևոր հաշվի առնել տեխնիկապես
Սոցիալական ցանցերը ապահովում են արագ երկխոսություն, բայց վճարման սխեման պետք է լինի նույնքան խիստ, որքան կայքում՝ անզորություն, կարգավիճակներ, աուդիտ և անվտանգ գաղտնիքներ:
Առաջին կանոնը անզորությունն է։ Հաճախորդը կարող է բացել հղումը մի քանի անգամ, կառավարիչը կարող է նորից ուղարկել այն, webhook կարող է նորից գալ, և CRM ինտեգրումը կարող է ժամանակավորապես չպատասխանել: Backend-ը պետք է մշակի կրկնվող իրադարձությունը, ինչպես արդեն հայտնի է, և չստեղծի երկրորդ վճարովի պատվեր, երկրորդ մուտք կամ երկրորդ առաքման առաջադրանք:
Դուք պետք է պահեք order_id-ի, մեսենջերի թեմայի id-ի կամ ներքին customer_id-ի, գումարի, արժույթի, վճարման հայտի ID-ի, ժամկետի ավարտի, մատակարարի հղումների, createAt, paidAt, webhook փորձերի, վերջին կարգավիճակի և աուդիտի գրանցամատյանի մի խումբ: Telegram օգտվողի ID-ն այստեղ հարմար չէ, եթե ալիքը Facebook-ն է; Կարևոր է օգտագործել ալիքին հատուկ նույնացուցիչներ և հաճախորդի ներքին ID:
Ֆիսկալիզացիան, ձեռք բերող բանկը, պայմանագրային պայմանները, վերադարձը, մասնակի վերադարձը և առաքման կանոնները կախված են կոնկրետ բիզնեսից և մատակարարից: Գործարկումից առաջ արժե առանձին նկարագրել, թե ինչ է տեղի ունենում վճարովի, ձախողված, ժամկետանց, pending-ի, կրկնօրինակ վճարման, չեղարկման, վերադարձման և կառավարչի կողմից ձեռքով ճշգրտման հետ:
- idempotency բանալի վճարման հարցում, webhook մշակում և CRM համաժամացում;
- order_id գումարած ալիքի/հաճախորդի նույնացուցիչները՝ պատվեր որոնելու համար.
- կարգավիճակները վճարված, ձախողված, ժամկետանց, pending և ձեռքով վերանայում;
- գաղտնիքներ API/webhook միայն շրջակա միջավայրի փոփոխականների և սերվերի պահեստավորման մեջ;
- վճարումների մատյան՝ մատակարարի հաշվետվության, CRM պատվերների, գումարների վերադարձի և հաշվառման հաշտեցման համար:
FAQ
Հնարավո՞ր է վճարումն ուղղակիորեն ընդունել Facebook Messenger-ով:
Messenger-ը կարող է լինել կապի ալիք և վճարման հղում ուղարկելու վայր, սակայն ավելի ճիշտ է բանկային վճարում կատարել անվտանգ checkout էջում կամ աջակցվող մատակարարի հոսքում:
Որոնք են Facebook Հայաստանի վճարային հղումները:
Սրանք հղումներ են դեպի checkout էջի, որը բիզնեսն ուղարկում է հաճախորդին Facebook-ի էջում կամ Messenger-ի պատվերը համաձայնեցնելուց հետո: Վճարումից հետո backend-ը կարգավիճակ է ստանում webhook-ի կամ կարգավիճակի որոնման միջոցով:
Հնարավո՞ր է սկսել առանց բարդ զարգացման:
Այո՛։ MVP-ի համար կարող եք օգտագործել ֆիքսված payment links և վճարային ամսագիր: Եզակի պատվերների, CRM կարգավիճակների և ավտոմատացման համար ավելի լավ է ավելացնել API, webhooks և անիմաստություն:
Ինչպե՞ս կապել վճարումը կոնկրետ երկխոսության հետ:
Վճարման հարցումը պետք է պահի order_id-ը, ներքին customer_id-ը, ալիքը և պատվերի համատեքստի անվտանգ հղումը: Պետք չէ հիմնվել միայն նամակագրության տեքստի կամ սքրինշոթի վրա։
Հնարավո՞ր է դրամով առցանց վճարում ընդունել Facebook script-ից։
Այո, եթե ընտրված վճարման սցենարը, ձեռք բերող բանկը, մատակարարը և պայմանագրային սխեման աջակցում են վճարման ցանկալի եղանակին: Պայմանները տարբեր են՝ կախված բիզնեսից և մատակարարից:
