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