Ինչ պետք է վճարման հետին պլանի մատյան

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

Ի՞նչ պետք է գրանցվի վճարման ֆոնդը:API, webhooks և backendpayment webhooksidempotency key վճարումներserver-side verification

Հաջորդ քայլերը

Webhooks Ստորագրված events, retries և անվտանգ webhook processing: API docs Գործնական contract payment sessions-ի, status checks-ի և events-ի համար:

Տեղեկամատյանները պետք է պատասխանեն աջակցության հարցերին

Վճարային ամսագրի հիմնական չափանիշն այն է, թե արդյոք հնարավոր է վերականգնել պատվերի պատմությունը առանց ծածկագրի մուտքի:

Աջակցեք հետաքննության ժամանակացույցին — Պատվերը ստեղծվեց, վճարումը սկսվեց, webhook ստացվեց, CRM թարմացվեց, հարկային աշխատանք queued:

Երբ հաճախորդը գրում է «գումարը գանձվել է, բայց պատվերը չի թարմացվել», աջակցությունը պետք է արագ տեսնի իրադարձությունների շղթան: Եթե կա միայն հում callback կամ միայն կարգավիճակ CRM-ում, հետաքննությունը երկար է դառնում:

Վճարման ֆոնդը պետք է պահպանի հստակ ժամանակացույց. ով է ստեղծել պատվերը, ինչ վճարման ID է տրվել, ինչ իրադարձություններ են եկել մատակարարից, ինչ է ուղարկվել CRM/ERP և ինչ է տեղի ունեցել ֆիսկալ անդորրագրի հետ:

պատվերի id-ն և վճարման նույնականացումը բոլոր հարակից իրադարձություններում.
փոխկապակցման id ծայրից ծայր որոնման համար;
ստեղծման, թարմացման և առաքման ժամանակացույցեր;
յուրաքանչյուր արտաքին ինտեգրման կարգավիճակը:

Այն, ինչ դուք չպետք է աննկատ գրեք մատյանում

Մուտքագրումը չպետք է դառնա զգայուն տվյալների պահեստ:

Անվտանգ անտառահատումների սահման — Քողեք զգայուն արժեքները, պահպանեք տեխնիկական ID-ները, սահմանափակեք չմշակված բեռների հասանելիությունը:

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

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

դիմակ զգայուն արժեքները;
մի պահեք քարտի ամբողջական տվյալները ներքին տեղեկամատյաններում.
առանձին տեխնիկական և գործառնական դերեր.
գրանցել ձեռքով ակնարկներ և ուղղումներ:

Ի՞նչ իրադարձություններ պետք է գրանցվեն:

Դուք պետք է գրանցեք ոչ միայն սխալները, այլև վիճակի հաջող անցումները:

Վճարման իրադարձությունների մատյան — Ստեղծել, redirect, ստուգել, webhook, կարգավիճակի անցում, առաքում, հարկաբյուջետային աշխատանք:

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

Առանձին-առանձին, արժե մուտքագրել արգելված կարգավիճակի անցումները: Օրինակ, եթե ուշացած pending-ը փորձում է վերագրանցել վճարովի, դա չպետք է փոխի կարգը, այլ պետք է տեսանելի լինի մշակողների համար:

վճարման փորձի ստեղծում;
մատակարարի պատասխանը և արտաքին վճարման ID-ն.
webhook/callback անդորրագիր;
բիզնեսի կարգավիճակի անցում;
առաքում CRM/ERP/ֆիսկալ ծառայություն:

FAQ

Արդյո՞ք անհրաժեշտ է պահպանել մատակարարի չմշակված պատասխանը:

Այո, բայց սահմանափակ հասանելիությամբ և զգայուն տվյալների քողարկումով: Նորմալացված դաշտերը սովորաբար բավարար են աջակցության համար:

Ի՞նչ է հարաբերակցության ID-ն:

Սա վերջից մինչև վերջ նույնացուցիչ է, որն օգնում է գտնել մեկ պատվերի կամ վճարման բոլոր իրադարձությունները տարբեր տեղեկամատյաններում և համակարգերում:

Բավական է միայն սխալներ գրանցելը:

Ոչ: Վճարումների համար կարևոր է տեսնել հաջող իրադարձություններ, որպեսզի վերականգնվի վերամշակման ամբողջական շղթան:

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

Տեղեկամատյանները պետք է պատասխանեն աջակցության հարցերին

Այն, ինչ դուք չպետք է աննկատ գրեք մատյանում

Ի՞նչ իրադարձություններ պետք է գրանցվեն:

FAQ

Կարդացեք նաև

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

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

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