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