Русский
Українська
ქართული
English
Қазақша
Español
Français
Deutsch
Italiano
فارسی
Հոդվածի ֆոկուսը
Ինչ պետք է պատրաստ լինի նախքան TEST մուտքը
Բանկը կամ մատակարարը ստուգում է ոչ միայն ինտեգրման կոդը, այլև կայքի պատրաստակամությունը վճարումներ ընդունելու համար:
Նախքան TEST մուտք գործելը, կայքը պետք է տեխնիկապես և բովանդակության համար պատրաստ լինի՝ HTTPS, կայուն տիրույթ, կոնտակտային էջեր, վճարման պայմաններ, վերադարձ, առաքում կամ սպասարկում: Սա ձևական չէ, քանի որ վճարման մատակարարը գնահատում է, թե հաճախորդը որտեղ է մուտքագրում քարտը և ինչ կանոններ է տեսնում վճարելուց առաջ։
AEB բաց vPOS պայմաններում նկարագրում է կայքի պահանջները և TEST/REAL կապի փուլերը: Նույնիսկ եթե կոնկրետ բանկը օգտագործում է իր ստուգաթերթը, բիզնեսի համար օգտակար է նախապես փակել այս նվազագույնը, որպեսզի դիմում ներկայացնելուց հետո ժամանակ չկորցնի մեկնաբանությունների վրա:
- աշխատող HTTPS և ճիշտ տիրույթ;
- կոնտակտներ, իրավական տեղեկատվություն և վերադարձի քաղաքականություն;
- ապրանքների կամ ծառայությունների հստակ նկարագրություն.
- հաջողություն, ձախողում և pending էջեր;
- պատասխանատու մշակող TEST մուտքերի համար:
Ո՞ր թեստային դեպքերն են պարտադիր անցնել:
Մեկ հաջող փորձնական վճարումը չի ապացուցում, որ վճարման հոսքը պատրաստ է արտադրության:
Նվազագույն փորձարկման մատրիցը պետք է ներառի հաջող վճարում, մերժում, pending, ներդիրի փակում, URL նորից հաջողության անցնել, webhook նորից առաքում, նույն պատվերի համար կրկին վճարելու փորձ և CRM/ERP կարգավիճակների ստուգում:
Եթե նախագիծը ներառում է ֆիսկալիզացիա, ստուգվում է չեկերի առանձին հերթ՝ ստուգում հաստատված վճարումից հետո, տվյալների սխալ, կրկնում, ձեռքով ստուգում և անդորրագրի միացում վճարման ID-ի հետ: Եթե կան վերադարձներ, ապա ստուգվում է գումարի ամբողջական և մասնակի վերադարձը:
- ֆիքսված գումարով վճարային նստաշրջանի ստեղծում.
- սերվերի կողմից վերջնական կարգավիճակի ստուգում;
- անիմաստություն webhook կրկնելիս;
- CRM/ERP ստանում է միայն նորմալացված կարգավիճակներ;
- օպերատորը տեսնում է հարաբերակցության id-ն աջակցության համար:
Ե՞րբ կարող եմ գնալ REAL
REAL-ի գործարկումն ապահով է, երբ թիմը հասկանում է ոչ միայն երջանիկ ուղին, այլև բացառությունների վերլուծության կանոնները:
Դուք պետք է անցնեք REAL այն բանից հետո, երբ բոլոր կարևոր սցենարները կանցնեն թեստը, գրանցամատյանները հասանելի կլինեն, webhook վերջնակետը կայուն է, և աջակցող թիմը գիտի, թե ինչ անել pending-ի, ձախողված, վերադարձման և անհամապատասխանության դեպքերի հետ:
Ավելի լավ է արտադրությունը սկսել աստիճանաբար՝ մեկ ալիք, վճարման մեկ եղանակ, ապրանքների կամ հաշիվ-ապրանքագրերի սահմանափակ փաթեթ, ամենօրյա հաշտեցում և արագ կապի ալիք մենեջերի, մշակողի և վճարումների համար պատասխանատու անձի միջև:
- կա անցած թեստային գործերի ցանկ.
- կա վճարման հետադարձ կամ ժամանակավոր անջատում.
- կան աջակցության հրահանգներ.
- Առաջին օրերի ընթացքում ամենօրյա հաշտեցումը միացված է.
- սխալները գրվում են գրանցամատյանում, և ոչ միայն սերվերի վահանակում:
FAQ
Հնարավո՞ր է անցնել REAL մեկ հաջող թեստային վճարումից հետո:
Ոչ: Դուք պետք է ստուգեք մերժումը, pending, կրկնվող webhook, ներդիրը փակելը, վճարումը կրկնելը, CRM/ERP կարգավիճակները և վիճելի դեպքերի աջակցությունը:
Ի՞նչ անել, եթե բանկը միանալուց առաջ ձեզ խնդրում է փոփոխել կայքը:
Փակեք մեկնաբանությունները որպես մեկնարկի ստուգաթերթի մաս՝ HTTPS, կոնտակտներ, վճարման պայմաններ, վերադարձ, ապրանքների կամ ծառայությունների նկարագրություն և վճարման արդյունքների ճիշտ էջեր:
Արդյո՞ք վերադարձը պետք է փորձարկվի գործարկումից առաջ:
Այո, եթե վերադարձը հասանելի է բիզնես գործընթացում: Կարևոր է ստուգել կապը վերադարձման և սկզբնական վճարման ID-ի, CRM/ERP կարգավիճակի և ֆիսկալ սցենարի միջև:
Sources
- Armeconombank - VPOSՊաշտոնական էջ՝ կայքի պահանջներով, TEST/REAL փուլերով և vPOS-ի պայմաններով:
- Evocabank - V-POS terminalV-POS-ի պաշտոնական նկարագրությունը վեբկայքի և բջջային հավելվածի համար 3D Secure-ով:
- Stripe Documentation - Webhook signatures and deliveryՊաշտոնական ուղեցույցներ webhook իրադարձությունների ստորագրության ստուգման, վերահանձնման և վարքագծի համար:
