Русский
Українська
ქართული
English
Қазақша
Español
Français
Deutsch
Italiano
فارسی
Հոդվածի ֆոկուսը
Ինչ է անում 3-D Secure-ը
3-D Secure-ը վաճառողի, թողարկողի և վճարային ենթակառուցվածքների միջև առկա վճարումների վավերացման շերտ է:
EMVCo-ն նկարագրում է EMV 3-D Secure-ը որպես սպառողների իսկությունը հաստատելու և քարտով չներկայացված վճարումների անվտանգությունը բարձրացնելու տեխնոլոգիա: Բիզնեսի համար սա նշանակում է, որ որոշ վճարումներ կարող են պահանջել լրացուցիչ հաստատում թողարկող բանկից:
Ըստ հայաստանյան բանկերի բաց էջերի, 3D Secure-ն ուղղակիորեն նշված է vPOS սցենարներում։ Օրինակ, Evocabank-ը նկարագրում է V-POS-ը որպես լուծում վեբկայքի և բջջային հավելվածի համար՝ միացված 3D Secure համակարգով: Հետևաբար, checkout-ն նախագծելիս պետք է 3-D Secure-ն համարել ստանդարտ տարր և ոչ թե բացառություն:
- վճարումը կարող է անցնել նույնականացման լրացուցիչ քայլի.
- հաճախորդը կարող է բանկում չավարտել քայլը.
- վերջնական կարգավիճակը կարող է գալ ավելի ուշ callback-ի կամ webhook-ի միջոցով;
- բջջային զննարկիչը և ներծրագրային հոսքը պետք է առանձին փորձարկվեն:
Ինչպես է 3-D Secure-ն ազդում UX-ի վրա
Խնդիրները սովորաբար ծագում են ոչ թե նույնականացումից, այլ վատ հաճախորդի վերադարձից checkout:
Եթե օգտատերը հաստատում է փոխանցում բանկային պատուհանում կամ հավելվածում, կայքը պետք է ճիշտ մշակի բոլոր տարբերակները՝ հաջողություն, մերժում, ներդիրի փակում, ժամանակի ավարտ, URL-ի վերսկսում հաջողության և վերջնական կարգավիճակի հետաձգում:
Հիմնական կանոնը. UX-ը կարող է ասել «մենք ստուգում ենք վճարումը», բայց չպետք է թողարկի ապրանք կամ ծառայություն մինչև սերվերի կողմից հաստատումը: Սա հատկապես կարևոր է թվային ապրանքների, ամրագրումների, CRM հաշիվ-ապրանքագրերի և ավտոմատ առաքման պատվերների համար:
- հաջողության էջը ցույց է տալիս հստակ սպասել, եթե կարգավիճակը դեռ pending է;
- ձախողման էջն առաջարկում է անվտանգ նորից փորձ առանց կրկնօրինակ պատվերի.
- բջջային հոսքը ստուգվում է Safari-ում, Chrome-ում և հավելվածի բրաուզերում;
- աջակցությունը տեսնում է մատակարարի տեղեկանքը և վերջին ստուգումը:
Ի՞նչ թեստեր են պահանջվում գործարկումից առաջ:
Հարկավոր է ստուգել ոչ միայն հաջողված քարտը, այլև ձախողման, պատուհանը փակելու և իրադարձությունը կրկին մատուցելու սցենարները:
Գործարկումից առաջ թիմը պետք է անցնի փորձնական դեպքեր՝ հաջող վճարում, բանկի մերժում, թերի վավերացում, կրկնվող թարմացման հաջող էջ, ներդիրների փակում, հետաձգված callback և կրկնվող webhook:
Եթե ինչ-որ սցենար չնկարագրվի, դա դեռ տեղի կունենա արտադրության մեջ։ Միակ տարբերությունն այն է, թե արդյոք բիզնեսը կտեսնի հասկանալի pending/ձեռնարկ վերանայում, թե ձեռքով կոնֆլիկտ կստանա հաճախորդի, մենեջերի և հաշվապահական հաշվառման բաժնի միջև:
- ստուգեք բոլոր վերադարձվող URL-ները և webhook վերջնակետերը;
- համոզվեք, որ հում ճակատային արդյունքը չի փակում պատվերը.
- պահպանել մատակարարի տեղեկանքը աջակցության համար;
- նկարագրեք տեքստը հաճախորդին pending-ի և ձախողված դեպքերի համար:
FAQ
Արդյո՞ք 3-D Secure-ն երաշխավորում է հաջող վճարում:
Ոչ: 3-D Secure-ն օգնում է նույնականացնել հաճախորդին, սակայն վճարումը դեռ կարող է ձախողվել, սպառվել կամ ունենալ pending կարգավիճակ: Վերջնական արդյունքը պետք է ստուգվի սերվերի կողմից:
Արդյո՞ք ես պետք է առանձին UX պատրաստեմ 3-D Secure-ի համար:
Այո՛։ Հաճախորդը պետք է հասկանա, թե ինչ է տեղի ունենում բանկային հաստատումից հետո, ինչ անել pending-ի հետ և ինչպես անվտանգ կրկին փորձել առանց կրկնօրինակ պատվերի:
Հնարավո՞ր է անջատել 3-D Secure-ը փոխակերպման համար:
Դա կախված է բանկից, մատակարարից, վճարման սխեմայի կանոններից և գործարքի ռիսկից: Կայքի համար ավելի լավ է նախագծել լավ 3DS հոսք, քան հույս դնել դրա բացակայության վրա:
Sources
- EMVCo - EMV 3-D SecureEMV 3-D Secure-ի պաշտոնական նկարագրությունը՝ որպես քարտի վավերացման տեխնոլոգիա:
- Evocabank - V-POS terminalՊաշտոնական V-POS էջ, որտեղ նշված են կայքը, բջջային հավելվածը և 3D Secure-ը:
- Stripe Documentation - PaymentIntents lifecycleԿարգավիճակի մոդելի օրինակ, որտեղ հաճախորդի լրացուցիչ գործողությունը վճարման կյանքի ցիկլի մի մասն է:
