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