Հոդվածի ֆոկուսը
Սկզբնական խնդիր. գնման կանոնները հստակ դարձնել վճարումից առաջ
Կայքի ստուգումը API-ից չի սկսվում. հաճախորդն ու provider-ը պետք է տեսնեն՝ ինչ է վաճառվում, որքան արժե և ինչպես են գործում չեղարկումն ու վերադարձը:
Այս քեյսում նախ փակվում է հանրային տեղեկատվությունը՝ ապրանքներ կամ ծառայություններ, գներ, վաճառքի պայմաններ, առաքման կամ ծառայության մատուցման կանոններ, կոնտակտներ, privacy policy, personal-data policy և չեղարկման կամ վերադարձի կանոններ:
Հայկական տարբերակը ձևական լեզվական փոխարկիչ չէ: Այն պետք է պարունակի նույն էական տեղեկատվությունը, ինչ ռուսերեն և անգլերեն տարբերակները, ներառյալ կանոնները, որոնք հաճախորդը տեսնում է վճարումից առաջ:
- Հրապարակել գինը կամ հստակ հաշվարկի եղանակը:
- Հրապարակել terms, privacy, personal data և refund policy:
- Նկարագրել առաքումը կամ ծառայության մատուցումը:
- Ստուգել HY, RU և EN տարբերակների համարժեք իմաստը:
Լուծումը. պատրաստել ճանապարհը checkout-ից մինչև վերջնական կարգավիճակ
TEST վճարումից առաջ յուրաքանչյուր իրադարձություն պետք է ունենա պատասխանատու՝ պատվեր, payment session, callback, webhook, կտրոն և աջակցություն:
Կայքը պատվերը ստեղծում է վճարումից առաջ և backend-ին փոխանցում է ֆիքսված գումար, արժույթ և նույնացուցիչ: Սերվերային ստուգումը հաստատում է արդյունքը. հաճախորդի success page-ը ինքնուրույն չի փոխում բիզնես կարգավիճակը:
Test պլանը ներառում է հաջող վճարում, չեղարկում, սխալ, pending, կրկնվող իրադարձություն և վերադարձի սցենար: Սա բացահայտում է ինտեգրման սխալները մինչև իրական պատվերները վտանգի տակ են:
- Ստուգել HTTPS-ը, production domain-ը և legal pages-ի հասանելիությունը:
- Frontend-ում կամ URL-ներում գաղտնիքներ չբացահայտել:
- Callback-ը կամ webhook-ը վավերացնել սերվերային կողմից:
- Վճարային բացառությունների համար սահմանել owner և SLA:
Գործարկումից հետո. օպերացիոն պատրաստվածություն
Production-ից հետո թիմը պետք է կարողանա գտնել գործողությունը, բացատրել կարգավիճակը և կատարել վերադարձ՝ չկորցնելով պատմությունը:
Մեկ հաջող test-ը բավարար չէ: Անհրաժեշտ են աջակցության կոնտակտներ, վեճերի ընթացակարգ, payment journal-ի հասանելիություն և provider report-ի հաշտեցման ժամանակացույց:
Գործարկումից հետո կայքի փոփոխությունները նույնպես վերահսկում են պահանջում: Նոր արժույթը, ծառայությունը, առաքման եղանակը կամ վերադարձի կանոնը կարող են փոխել վճարային flow-ը և պետք է նորից ստուգվեն:
- Նշանակել checkout, backend, support և accounting պատասխանատուներ:
- Պահել ձեռքով չեղարկումների և վերադարձների գրանցամատյան:
- Պարբերաբար ստուգել legal pages-ի և լեզվական տարբերակների հղումները:
- Համադրել վճարված պատվերները, վերադարձները և provider report-ը:
FAQ
Պե՞տք է արդյոք կայքի հայերեն տարբերակ vPOS-ի համար:
Այո: Հայերենում պետք է ներկայացված լինի նույն էական տեղեկատվությունը ապրանքի կամ ծառայության, գների, կանոնների և կոնտակտների մասին:
Կարելի՞ է չհրապարակել վերադարձի քաղաքականությունը, եթե ապրանքը վերադարձի ենթակա չէ:
Պետք է հստակ նշել կիրառելի կանոնը՝ վերադարձ, չեղարկում կամ վերադարձի անհնարինություն: Առանց դրա հաճախորդն ու աջակցությունը չունեն հստակ գործընթաց:
Ի՞նչն է համարվում production պատրաստվածություն:
Ոչ միայն հաջող TEST վճարումը, այլ նաև ստուգված legal pages-ը, սերվերային կարգավիճակը, սխալների մշակումը, վերադարձները, աջակցությունը և հաշտեցումը: