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