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