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