Վճարումների ընդունում Հայաստանում Telegram-bot-ով

Հոդվածի ֆոկուսը

Վճարումների ընդունում Հայաստանում Telegram-bot-ովՎճարային օպերացիաներՀայաստանում Telegram բոտով վճարումների ընդունումվճարման հղումներ Telegram Հայաստանվճարում Telegram բոտով

Հաջորդ քայլերը

VPOS Reconcile Վճարումների հաշտեցում provider-ի, կայքի, CRM-ի, ERP-ի և ներքին հաշվետվության միջև: Կարգավիճակ Ինչպես տարանջատել API-ի, webhook delivery-ի, checkout-ի և fiscal queue-ի վիճակը:

Ինչու Telegram-ը հաճախ դառնում է վաճառքի կետ

Հաճախորդն արդեն շփվում է բոտում, ընտրում է ծառայություն և սպասում առանց առանձին կայքի վճարման արագ միջոցի։

Telegram խոսակցություն -> վերահսկվող վճարում — Բոտը հավաքում է պատվերի համատեքստը, backend-ը ստեղծում է վճարման հարցում, օգտվողը վճարում է պաշտպանված checkout էջում:

Առցանց դպրոցների, սպասարկման գրառումների, առաքման, տեղական e-commerce, խորհրդատվությունների և մասնավոր ակումբների համար Telegram հաճախ առաջին վաճառքի միջերեսն է: Հաճախորդը գրում է բոտին, ընտրում դասընթաց, սակագին, առաքման ժամանակ, խորհրդատվություն կամ բաժանորդագրություն և ցանկանում է անմիջապես ավարտել սցենարը նույն երկխոսության մեջ:

Կարևոր է չշփոթել ինտերֆեյսը և վճարային ենթակառուցվածքը: Telegram-bot-ը չպետք է ուղղակիորեն մշակի բանկային վճարումները: Ճիշտ սխեման․ բոտը կամ հետնամասը ստեղծում է վճարման հղում, օգտատերը գնում է պաշտպանված checkout էջ, վճարում է, և հետնամասը կարգավիճակը ստանում է webhook կամ կարգավիճակի որոնման միջոցով։

Այս մոտեցումը նվազեցնում է ձեռքով հաստատումները, զրույցի սքրինշոթները և մենեջերի սխալները: Բիզնեսը տեսնում է ոչ միայն օգտատիրոջ հաղորդագրություն, այլ ստուգված վճարային իրադարձություն՝ ով է ընտրել ծառայությունը, ինչ order_id է ստեղծվել, ինչ գումար է սահմանվել ՀՀ դրամով, ինչ կարգավիճակ է ստացվել վճարման շերտից և ինչ պետք է անի բոտը հետո:

Telegram-ը մնում է ընտրության և ծանուցման միջերեսը;
վճարումը կատարվում է անվտանգ checkout էջում;
backend-ը պահպանում է order_id-ը, telegram_user_id-ը և գումարը;
վերջնական վճարովի կարգավիճակը գալիս է webhook կամ կարգավիճակի ստուգման միջոցով:

Ինչպես է այն աշխատում

Հիմնական հոսք՝ բոտում ծառայության ընտրություն, վճարման հղում, checkout, webhook և սկրիպտի ավտոմատ շարունակություն:

Բոտ -> payment link -> checkout -> webhook — Օգտատերը ընտրում է ծառայությունը, բոտը ուղարկում է payment link, checkout-ն հաստատում է վճարումը, webhook թարմացնում է բոտը և CRM:

Սցենարը սկսվում է Telegram-bot-ից: Օգտագործողը ընտրում է ծառայություն՝ դաս, խորհրդատվություն, առաքում, նվիրատվություն, հուշում, մուտք դեպի փակ ակումբ կամ ապրանք կատալոգից: Բոտը հավաքում է նվազագույն համատեքստ՝ ընտրված ապրանք, գումար, արժույթ, telegram_user_id, լեզու, կոնտակտային տվյալներ, առաքման վայր կամ այլ բիզնես պարամետր:

Այնուհետև բոտը կապվում է հետին պլանի հետ կամ օգտագործում է նախապես պատրաստված վճարման հղումը: Պարզ MVP-ի համար կարող եք ֆիքսված հղումներ ուղարկել սակագներին: Ավելի ճշգրիտ սցենարի համար backend-ը ստեղծում է վճարման դինամիկ հարցում API-ի միջոցով՝ գումար, արժույթ AMD, order_id, ժամկետի ավարտ, նկարագրություն, հաջողակ/անհաջող վերադարձ URL և մետատվյալներ CRM-ի համար:

Օգտագործողը բացում է անվտանգ checkout էջ, վճարում է քարտով կամ մատակարարի կողմից հասանելի այլ եղանակով: Դրանից հետո VPOS-ն ուղարկում է webhook-ը հետնամաս: Backend-ը ստուգում է ստորագրությունը, կարգավիճակը, գումարը, արժույթը, order_id-ը և idempotency բանալին, պահպանում է արդյունքը վճարման մատյանում և միայն դրանից հետո տեղեկացնում բոտին, որ պատվերը, մուտքը, դիմումը կամ բաժանորդագրությունը հաստատվել է:

օգտատերը բոտում ընտրում է ծառայություն, սակագին կամ պատվեր.
bot/backend-ը ստեղծում է վճարման հղում կամ վճարման հարցում.
օգտվողը վճարում է checkout էջում;
VPOS-ն ուղարկում է webhook վճարման արդյունքով;
բոտը հաստատում է պատվերը, մուտքը, հավելվածը կամ բաժանորդագրությունը:

Ո՞վ է հարմար Telegram-bot-ով վճարումներ ընդունելու համար

Telegram-ն լավ է աշխատում, որտեղ վաճառքը սկսվում է երկխոսությամբ, հավելվածով, ձայնագրությամբ կամ կարճ կատալոգով:

Telegram վճարման սցենարներ — Դասընթացները, խորհրդատվությունները, առաքումները, նշանակումները, նվիրատվությունները, հուշումները, ակումբները և բաժանորդագրությունները օգտագործում են մեկ ստուգված հոսք:

Առցանց դպրոցը կարող է վաճառել մեկանգամյա դաս, մուտք դեպի մոդուլ, ինտենսիվ դասընթաց կամ բաժանորդագրության նորացում: Ստուգված վճարումից հետո բոտը ավտոմատ կերպով բացում է դասը, հղում է ուղարկում փակ ալիքին կամ հանձնարարում է մենեջերին, եթե անհրաժեշտ է ձեռքով վերանայել:

Խորհրդատվական բիզնեսը կարող է ընդունել կանխավճար զանգի կամ ծառայության համար: Բոտը ցույց է տալիս անվճար սլոթեր, ուղարկում է payment link և հաստատում մուտքը միայն webhook-ից հետո: Առաքման համար Telegram-bot-ը կարող է ընդունել պատվեր, հասցե, մեկնաբանություններ և վճարումներ, այնուհետև վճարովի պատվերը փոխանցել CRM՝ սեղանի կամ սուրհանդակային համակարգին:

Ծառայությունների գրառումները, նվիրատվությունները, հուշումները, փակ ակումբները և բաժանորդագրությունները նույնպես հարմար են այս հոսքի համար: Հիմնական բանը օգտատիրոջ հաղորդագրության համաձայն վճարովի չդարձնելն է։ Նույնիսկ եթե հաճախորդը սքրինշոթ է ուղարկել, ավտոմատ հաստատումը պետք է հայտնվի միայն սերվերի կողմից ստուգումից հետո:

առցանց դասընթացներ, ինտենսիվ դասընթացներ և նյութերի հասանելիություն;
խորհրդատվություններ, սպասարկման գրառումներ և վերապահումներ;
առաքում, տեղական e-commerce և նախնական պատվերներ;
նվիրատվություններ, հուշումներ, ակումբներ և բաժանորդագրություններ;
CRM/ERP սկրիպտներ ինտեգրատորների և վեբ ստուդիաների համար:

MVP սցենար մի քանի օրից

Դուք կարող եք սկսել ֆիքսված հղումներով և վճարումների մատյանից, այնուհետև անցնել API, webhooks և CRM ինտեգրմանը:

MVP -> API -> CRM — Ֆիքսված հղումները, դինամիկ API հղումները, webhooks, վճարային ամսագիրը և CRM համաժամացումը կազմում են փուլային ինտեգրման ուղի:

Ամենաարագ օդաչուն՝ ֆիքսված վճարման հղումներ: Օրինակ՝ առցանց դպրոցը ստեղծում է հղումներ դեպի երեք սակագներ, և բոտը փաթեթ ընտրելուց հետո ուղարկում է ցանկալի հղումը։ Այս տարբերակը հարմար է պահանջարկը և սցենարը ստուգելու համար, սակայն այն ունի մի սահմանափակում. յուրաքանչյուր վճարում ավելի դժվար է կապել կոնկրետ order_id-ի, օգտագործողի և CRM կարգավիճակի հետ:

Հաջորդ մակարդակը դինամիկ կապերն են API-ի միջոցով: Բոտը ընտրված ծառայությունն ու օգտագործողին փոխանցում է backend-ին, backend-ը ստեղծում է վճարման եզակի հարցում, պահպանում է order_id-ը և հղումը հետ է ուղարկում Telegram: Վճարումից հետո webhook-ը թարմացնում է վճարումների մատյանը, բոտը և CRM: Սա արդեն նորմալ հիմք է Telegram բոտի հետ վճարումները ինտեգրելու համար։

Առաջին իսկ օրվանից անհրաժեշտ է վճարման ամսագիր: Այն պետք է պարունակի order_id, telegram_user_id կամ ներքին customer_id, գումար, արժույթ, հղում, կարգավիճակ, մատակարարի հղում, ստեղծման ժամանակը, վճարման ժամանակը, webhook փորձերը և բոտի վերջնական գործողությունը: Երբ MVP-ն աշխատում է կայուն, հաջորդ քայլը CRM-ի, աղյուսակի, Bitrix24-ի, amoCRM-ի, Kommo-ի, ERP-ի կամ ներքին վահանակի միացումն է:

ֆիքսված վճարման հղումներ պարզ օդաչուի համար.
դինամիկ հղումներ API-ի միջոցով եզակի պատվերների համար;
webhooks ավտոմատ վճարովի / ձախողված / ժամկետանց կարգավիճակի համար;
աջակցության և հաշտեցման համար վճարումների մատյան;
CRM, սեղան, Bitrix24 կամ amoCRM որպես հաջորդ քայլ:

Ինչն է կարևոր հաշվի առնել տեխնիկապես

Վստահելի Telegram վճարումների հոսքը հիմնված է անզորության, կարգավիճակների, ապահով նշանների և աուդիտի հստակ հետքի վրա:

Տեխնիկական վճարումների վերահսկում — Idempotency, order_id, telegram_user_id, կրկնակի փորձեր, նշանների անվտանգություն, տեղեկամատյանները և աուդիտը պաշտպանում են հոսքը:

Առաջին կանոնը անզորությունն է։ Webhook-ը կարող է նորից գալ, օգտատերը կարող է մի քանի անգամ սեղմել վճարման կոճակը, բոտը կարող է նորից ուղարկել հղումը։ Backend-ը պետք է հասկանա, որ մեկ order_id-ը չպետք է ստեղծի երկու վճարովի պատվեր, երկու մուտք կամ երկու առաքում:

Երկրորդ կանոնը ճիշտ նույնացուցիչները պահելն է: Նվազագույն հավաքածու՝ order_id, telegram_user_id կամ ներքին customer_id, payment_request_id, մատակարարի տեղեկանք, գումար, արժույթ, կարգավիճակ, createAt, paidAt, ժամկետի ավարտ և սցենարի մետատվյալներ: Այս դաշտերը թույլ են տալիս աջակցությանը արագ հասկանալ, թե ինչ է տեղի ունեցել, նույնիսկ եթե օգտատերը գրում է միայն «Ես վճարել եմ»:

Երրորդ կանոնը անվտանգությունն է. Բոտի նշանը, API բանալիները, webhook գաղտնիքները և մատակարարի հավատարմագրերը չպետք է լինեն հաճախորդի կոդում կամ հանրային պահեստում: Webhook-ը պետք է ստուգվի ստորագրության կամ վստահելի կարգավիճակի որոնման միջոցով: Գրանցամատյանները պետք է օգնեն վրիպազերծմանը, բայց չպահեն ավելորդ անձնական տվյալներն ու քարտի տվյալները:

idempotency բանալի վճարման հայտի և webhook մշակման համար;
order_id և telegram_user_id պատվերը օգտագործողի հետ կապելու համար;
կարգավիճակները վճարված, ձախողված, ժամկետանց, pending և ձեռքով վերանայում;
կրկնվող webhooks առանց կրկնօրինակների և կրկնակի մուտքի;
գաղտնիքներ շրջակա միջավայրի փոփոխականների, անտառահատումների և աուդիտի հետքի մեջ:

Տիպիկ ճարտարապետություն

Նույնիսկ պարզ Telegram-bot-ն ավելի լավ է կառուցված որպես backend-ի վրա հիմնված սկրիպտ, որտեղ բոտը չի պահում վճարման գաղտնիքները:

Հղման ճարտարապետություն — Telegram բոտը խոսում է backend-ի հետ, backend-ը ստեղծում է VPOS checkout հղում, webhook թարմացումների բոտ, CRM և ամսագիր:

Պարզ տեքստային հոսքն ունի հետևյալ տեսքը. Օգտվող -> Telegram-bot -> Backend -> VPOS payment link/API -> Ստուգման էջ -> VPOS webhook -> Backend -> VPOS +ZXQNal +ZXQ

Բոտը պատասխանատու է երկխոսության համար՝ ցույց տալ տոկոսադրույքները, հավաքել ընտրանքներ, ուղարկել հղում, ցուցադրել pending կամ վճարովի հաղորդագրություն: Բեքենդը պատասխանատու է գումարի համար՝ հաշվարկեք գումարը, ստեղծեք վճարման հարցում, ստուգեք webhook, պահպանեք կարգավիճակը, կատարեք անիմաստ գործողություն և արդյունքը փոխանցեք CRM/ERP կամ աղյուսակին:

Այս մոտեցումն ավելի հեշտ է պահպանել: Եթե վաղը ձեզ անհրաժեշտ է ավելացնել Bitrix24, amoCRM, ֆիսկալիզացիա, պահեստ կամ բաժանորդագրություն, դուք ստիպված չեք լինի վերաշարադրել վճարման տրամաբանությունը բոտի ներսում: Բավական է ընդլայնել backend-ը և իրադարձությունների մշակողները:

Օգտագործող -> Telegram-bot. ընտրել ծառայություն կամ սակագին;
Telegram-bot -> Backend. ստեղծել պատվերի/վճարման հարցում;
Backend -> VPOS. ստացեք պաշտպանված checkout հղում;
VPOS -> Backend. webhook վճարման կարգավիճակով;
Backend -> Bot/CRM. հաստատեք պատվերը, մուտքը կամ հավելվածը:

Ինչ հարցեր պատրաստել նախքան ինտեգրումը

Լավ տեխնիկական բնութագրը խնայում է ժամանակը. դուք պետք է նախապես նկարագրեք ապրանքները, կարգավիճակները, սխալները, CRM և վերադարձի կանոնները:

Ինտեգրման նախապատրաստման ստուգաթերթիկ — Արտադրանքները, գները, կարգավիճակները, CRM դաշտերը, գումարի վերադարձը, ֆիսկալիզացիան և մատակարարի կանոնները հստակեցվում են գործարկումից առաջ:

Նախքան ինտեգրումը արժե նկարագրել, թե կոնկրետ ինչ է վաճառում բոտը՝ ֆիքսված գներ, ապրանքներ, ծառայություններ, գրառումներ, բաժանորդագրություններ կամ նվիրատվություններ: Յուրաքանչյուր սցենարի համար դուք պետք է հասկանաք հղման գումարը, արժույթը, վավերականության ժամկետը, ինչ է տեղի ունենում վճարումից հետո և ով է պատասխանատու ձեռքով վերանայման համար:

Առանձին-առանձին, դուք պետք է պատրաստեք ստատուսներ: Ի՞նչ է ցույց տալիս բոտը, երբ pending, ձախողված, ժամկետանց և վճարված է: Հնարավո՞ր է կրկնել վճարումը: Ի՞նչ անել, եթե webhook-ն ուշանում է: Ինչպե՞ս է օպերատորը տեսնում վիճելի վճարումը: Ո՞ր դաշտերն են գնում CRM, աղյուսակ, Bitrix24, amoCRM կամ ERP:

Ֆիսկալիզացիան, ձեռք բերող բանկը, պայմանագրային խնդիրները և գումարի վերադարձման կանոնները կախված են կոնկրետ բիզնեսից, մատակարարից և իրավական սխեմայից: Դրանք պետք է առանձին վերանայվեն՝ նախքան հրապարակային գործարկումը, հատկապես, եթե կան բաժանորդագրություններ, կանխավճարներ, վերապլանավորված ծառայություններ կամ վերադարձներ:

ՀՀ դրամով ապրանքների, ծառայությունների, սակագների և գումարների ցանկ.
կանոնները վճարված / ձախողված / ժամկետանց / pending / ձեռնարկի վերանայում;
պարտադիր CRM դաշտեր, order_id և հաճախորդի նույնացուցիչներ;
փոխհատուցում, չեղարկում և վերավճարում;
ֆիսկալիզացիայի, պայմանագրի և ձեռքբերման/մատակարարի պահանջներ:

Ինչպես կարող է օգնել VPOS-ը

VPOS-ն օգնում է հավաքել վճարային հոսքեր Telegram-bot-ի համար առանց ավելորդ բարդության՝ փորձնականից մինչև CRM/ERP ինտեգրում:

VPOS Telegram օդաչու — Վճարման հղումները, API, checkout էջերը, webhooks, CRM համաժամացումը և վճարման ամսագիրը քայլ առ քայլ միացված են:

VPOS-ն օգնում է հայաստանյան բիզնեսին վճարումներ ընդունել վճարային հղումների, API, checkout էջերի և webhooks-ի միջոցով: Telegram-bot-ի համար սա նշանակում է հստակ սխեմա. օգտատերը բոտում ընտրում է ծառայություն, ստանում է անվտանգ վճարային էջի հղում, վճարում է, իսկ հետնախագիծը ստանում է կարգավիճակը և ավտոմատ կերպով շարունակում է սկրիպտը:

Օդաչուի համար կարող եք սկսել վճարման հղումներով և պարզ վճարումների մատյանից: Եթե սցենարը պահանջում է եզակի պատվերներ, CRM, բաժանորդագրություններ, դասընթացի հասանելիություն կամ առաքում, ապա ավելի լավ է նախագծել API-ի վրա հիմնված հոսքը՝ order_id, մետատվյալներ, webhook ստուգում, անգործունակություն և նորից փորձեք առաքում CRM-ում:

Մենք կարող ենք օգնել նկարագրել ճարտարապետությունը, պատրաստել դաշտերը, webhook պայմանագիրը, բոտի կարգավիճակները, վճարումների գրանցամատյանը և ինտեգրվել CRM/աղյուսակ/Bitrix24/amoCRM-ի հետ: Սա նվազեցնում է ձեռքով վճարովի կարգավիճակների ռիսկը և Telegram-bot-ը դարձնում է վճարային ենթակառուցվածքի մաս, և ոչ թե սքրինշոթերի վրա հիմնված վճարումների հետ զրույց:

պատրաստել Telegram վճարման հոսքը և MVP շրջանակը;
միացնել payment links, API և checkout էջը;
կարգավորել webhook, անզորություն և վճարման ամսագիր;
փոխանցել կարգավիճակները CRM, աղյուսակ, Bitrix24 կամ amoCRM;
վերլուծել ֆիսկալիզացիայի և մատակարարի պահանջները որպես առանձին բլոկ:

FAQ

Հնարավո՞ր է վճարումներ ընդունել անմիջապես Telegram-bot-ի ներսում:

Բոտը կարող է լինել պատվիրման միջերես և ուղարկել վճարման հղումը, սակայն բանկային վճարումը պետք է անցնի ապահով checkout էջի կամ աջակցվող մատակարարի հոսքի միջոցով: Դուք չպետք է Telegram-ին համարեք վճարման մատակարար:

Որո՞նք են Telegram Հայաստանի վճարային հղումները նման սցենարում:

Սրանք հղումներ են, որոնք բոտն ուղարկում է օգտատիրոջը ծառայություն կամ սակագին ընտրելուց հետո: Օգտատերը բացում է checkout էջը, վճարում է, իսկ backend-ը կարգավիճակը ստանում է webhook-ի միջոցով։

Ձեզ անհրաժեշտ է համալիր զարգացում ձեր առաջին MVP-ի համար:

Ոչ պարտադիր: Առաջին MVP-ն կարող է կատարվել ֆիքսված վճարման հղումներով և վճարումների մատյանում: Պատվերները, մուտքը կամ CRM ավտոմատ հաստատելու համար ավելի լավ է ավելացնել API և webhooks:

Ինչպե՞ս է բոտը իմանում, որ վճարումն անցել է:

VPOS-ն ուղարկում է webhook-ը հետնամաս: Backend-ը ստուգում է կարգավիճակը, գումարը, արժույթը, order_id-ը և idempotency-ը, այնուհետև բոտին ուղարկում է հրաման՝ պատվերը կամ մուտքը հաստատելու համար:

Կարո՞ղ եմ ընդունել դրամով առցանց վճարում:

Այո, եթե վճարման սցենարը, ձեռք բերող բանկը, մատակարարը և պայմանագրային սխեման աջակցում են վճարման ցանկալի եղանակին: Հատուկ պայմանները տարբեր են՝ կախված բիզնեսից և մատակարարից:

Ի՞նչ անել, եթե webhook-ը երկու անգամ է եկել:

Վերահսկիչը պետք է անիմաստ լինի. նույն վճարման/պատվերի համար կրկնվող webhook չպետք է նորից մուտք գործի, ստեղծի երկրորդ պատվեր կամ կրկնօրինակ վճարում CRM-ում:

Արդյո՞ք անհրաժեշտ է ֆիսկալիզացիա Telegram-bot-ում վճարման համար:

Սա կախված է բիզնեսի տեսակից, իրավական կառուցվածքից, մատակարարից և կոնկրետ գործունեությունից: Սկսելուց առաջ ավելի լավ է ֆիսկալիզացիան և փաստաթղթերը կարգավորել առանձին: