ԼեզուHY
РусскийУкраїнськаՀայերենქართულიEnglishҚазақшаEspañolFrançaisDeutschItalianoفارسی
API, webhooks և backend Հրապարակվել է May 22, 2026 9 րոպե ընթերցում

Գումարի վերադարձ և մասնակի վերադարձ առցանց վճարումից հետո. ինչպես ձևավորել

Փոխհատուցման հոսքը պետք է նախապես մշակվի. ով է նախաձեռնում վերադարձը, ինչպես է ստուգվում գումարը, ինչպես է թարմացվում CRM-ը և ինչ է կատարվում չեկի հետ:

Գումարի վերադարձ և մասնակի վերադարձ առցանց վճարումից հետո. ինչպես ձևավորել

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

Գումարի վերադարձ և մասնակի վերադարձ առցանց վճարումից հետո. ինչպես ձևավորելAPI, webhooks և backendpayment webhooksidempotency key վճարումներserver-side verification

Պարտադիր չէ, որ վերադարձը լինի ձեռքով նշում պատվերի մեջ:

Գումարի վերադարձը առանձին վճարային գործարք է՝ կարգավիճակով, գումարով, մուտքի իրավունքներով և գրանցամատյանով:

Վճարում -> Վերադարձման հարցում -> Մատակարար -> CRM կարգավիճակ
Յուրաքանչյուր վերադարձ պետք է կապված լինի սկզբնական վճարման և պատվերի հետ:

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

Փոխհատուցման պատշաճ հոսքը սկսվում է սկզբնական վճարումը ստուգելուց. արդյոք վճարման ID-ն գոյություն ունի, արդյոք վճարումը հաջող է եղել, որքանն է արդեն վերադարձվել, և արդյոք թույլատրվում է վերադարձնել այն օգտվողին, ով նախաձեռնել է այն: AEB-ն vPOS-ի պահանջներում առանձին սահմանում է գործարքների և ապրանքների/ծառայությունների մասին տեղեկատվության պահպանումը առնվազն մեկ տարի. փոխհատուցման հոսքի համար սա աուդիտի գործնական նվազագույնն է, նույնիսկ եթե ընտրվի մեկ այլ մատակարար:

  • գումարի վերադարձը կապված է պատվերի սկզբնական ID-ի և վճարման ID-ի հետ.
  • նախաձեռնողն ու պատճառը գրանցվում են աուդիտի մատյանում.
  • գումարը չի գերազանցում առկա մնացորդը.
  • CRM/ERP-ն ստանում է առանձին վերադարձի կարգավիճակ:

Մասնակի վերադարձը պահանջում է առանձին մոդել

Գումարի մասնակի վերադարձը չի կարող նախագծվել որպես պատվերի պարզ անցում վճարվածից վերադարձվողի:

Մասնակի վերադարձի մնացորդ
Վճարված գումարը, վերադարձված գումարը և մնացած գումարը պետք է ապահով հաշվարկվեն:

Մասնակի վերադարձի դեպքում պատվերը կարող է մնալ մասամբ վճարված, մասամբ ավարտված կամ փակվել ճշգրտումներով: Հետևաբար, պատվերի կարգավիճակը և վճարման կարգավիճակը չեն կարող խառնվել մեկ դաշտում:

Backend-ը պետք է պահպանի սկզբնական գումարը, բոլոր հաջողված վերադարձների գումարը և հասանելի մնացորդը: Գումարի վերադարձի կրկնակի փորձը պետք է լինի անզոր, որպեսզի նույն հարցումը գումարը կրկնակի չվերադարձնի: Սա հատկապես կարևոր է CRM/ERP-ի համար. պատվերը կարող է մնալ կատարված, իսկ վճարումը կարող է գնալ partal_refunded-ին:

  • սկզբնական_գումար;
  • վերադարձված_գումար;
  • հասանելի_վերադարձման համար;
  • վերադարձի_փորձի_id;
  • վերադարձի կարգավիճակ՝ pending, հաջողվեց, ձախողվեց:

Ֆիսկալիզացիա և հաշվառում վերադարձից հետո

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

Փոխհատուցում + հարկաբյուջետային ուղղում + հաշվառում
Վճարման վերադարձը, հարկաբյուջետային ուղղումը և ERP կարգավիճակը պետք է համապատասխանեն:

Եթե բիզնեսը ֆիսկալացնում է առցանց վճարումները, վերադարձները կարող են պահանջել առանձին ֆիսկալ գործողություն կամ ճշգրտում: Հայաստանում էլեկտրոնային ֆիսկալիզացիան կարգավորվում է էլեկտրոնային ՀԴՄ/HDM-ի միջոցով, ուստի վճարման վերադարձը և ֆիսկալ ուղղումը չեն կարող խառնվել մեկ կոճակի մեջ՝ առանց կարգավիճակների և գրանցամատյանի:

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

  • վճարման վերադարձի կարգավիճակը առանձնացված է հարկաբյուջետային ուղղման կարգավիճակից.
  • հերթեր և կրկնակի փորձեր հարկաբյուջետային իրադարձությունների համար.
  • ձեռքով ճշգրտումների աուդիտ;
  • հաշտեցում բանկային քաղվածքի և ERP-ի հետ:

FAQ

Հնարավո՞ր է վերադարձ կատարել անմիջապես CRM-ից:

Այո, եթե CRM-ը զանգահարում է հետին վերջնակետը՝ իրավունքի, գումարի և սկզբնական վճարման ստուգմամբ, և առանց վճարման գործարքի ձեռքով չի փոխում պատվերի կարգավիճակը:

Ինչու է մասնակի փոխհատուցումն ավելի դժվար, քան ամբողջական փոխհատուցումը:

Քանի որ դուք պետք է հաշվի առնեք արդեն վերադարձված գումարը, մնացորդը, պատվերի կարգավիճակը, հարկաբյուջետային ճշգրտումը և հնարավոր կրկնությունները:

Արդյո՞ք պահանջվում է աուդիտի գրանցամատյան վերադարձի համար:

Այո՛։ Վերադարձը ազդում է փողի, հաշվապահական հաշվառման և աջակցության վրա, այնպես որ դուք պետք է իմանաք, թե ով, երբ, ինչու և ինչ գումարով է սկսել գործարքը:

Sources

  • Armeconombank - VPOS conditionsvPOS-ի պաշտոնական պայմանները, ներառյալ գործարքների մասին տեղեկատվության պահպանման պահանջները:
  • Stripe Docs - RefundsՊաշտոնական փաստաթղթեր լրիվ/մասնակի վերադարձման հիմնական մոդելով և վերադարձման կարգավիճակներով:
  • State Revenue Committee of ArmeniaՀայաստանի հարկային ծառայության պաշտոնական կայք՝ HDM/ֆիսկալիզացիայի ընթացիկ պահանջները ստուգելու համար:

Կարդացեք նաև

Վեբկեռիկներ և վճարման կարգավիճակներ. ինչպես անվտանգ ձևավորել
API, webhooks և backend 10 րոպե ընթերցում

Վեբկեռիկներ և վճարման կարգավիճակներ. ինչպես անվտանգ ձևավորել

Վճարման գործնական մոտեցում callback/webhook և պատվերի կարգավիճակների հուսալի փոփոխություն:

Կարդալ հոդվածը
Անբավարարության բանալին վճարումների մեջ. ինչու է դա անհրաժեշտ և ինչպես օգտագործել այն
API, webhooks և backend 8 րոպե ընթերցում

Անբավարարության բանալին վճարումների մեջ. ինչու է դա անհրաժեշտ և ինչպես օգտագործել այն

Idempotency ստեղնը պաշտպանում է վճարման ֆոնդը կրկնվող գործողություններից, կրկնօրինակ պատվերներից և կրկնվող փորձերի ժամանակ քաոսից:

Կարդալ հոդվածը
Ի՞նչ պետք է գրանցվի վճարման ֆոնդը:
API, webhooks և backend 7 րոպե ընթերցում

Ի՞նչ պետք է գրանցվի վճարման ֆոնդը:

Առանց նորմալ տեղեկամատյանների, աջակցությունը չի կարողանա արագ հասկանալ, թե արդյոք գումարը գանձվել է, որտեղ է կորել կարգավիճակը և ինչ է ուղարկվել CRM-ին:

Կարդալ հոդվածը