Русский
Українська
ქართული
English
Қазақша
Español
Français
Deutsch
Italiano
فارسی
Հոդվածի ֆոկուսը
Նվազագույն առցանց վճարման շղթա
Վճարման սցենարը պետք է նախագծված լինի որպես իրադարձությունների շղթա, այլ ոչ թե որպես մեկ կոճակ կայքում:
Բիզնեսի համար առցանց վճարումը սկսվում է կայքում տեղադրված կոճակից, սակայն տեխնիկապես դա մի քանի համակարգերից բաղկացած շղթա է։ Կայքը ստեղծում է պատվերը, backend-ը գրանցում է վճարումը, վճարման էջն ընդունում է քարտը կամ վճարման այլ եղանակ, այնուհետև backend-ը ստուգում է վերջնական կարգավիճակը:
Չափազանց կարևոր է վճարումը հաջողված չհամարել միայն այն ժամանակ, երբ օգտատերը վերադառնում է կայք: Օգտագործողը կարող է փակել ներդիրը, ցանցը կարող է իջնել, և վճարման մատակարարը կարող է ավելի ուշ ուղարկել վերջնական կարգավիճակը: Հետևաբար, հուսալի ճարտարապետությունը միշտ հենվում է սերվերի կողմից հաստատման և callback/webhook-ի վրա:
- Կայքը պատվեր է ստեղծում կայուն համարով։
- Backend-ը ստեղծում է վճարային նստաշրջան և պահպանում է արտաքին վճարման ID-ն:
- Մատակարարը գնորդին վերադարձնում է հաջողության/ձախողման URL:
- Backend-ը առանձին ստուգում է վճարման կարգավիճակը մատակարարի կողմից:
- CRM/ERP ստանում է միայն ստուգված արդյունքը:
Այն, ինչ դուք պետք է պատրաստեք նախքան ինտեգրումը
Նախքան մշակումը, դուք պետք է պայմանավորվեք ոչ թե կոճակի դիզայնի, այլ պատվերի, վճարման, ստացման և հաշվառման միջև կնքված պայմանագրի շուրջ:
Ամենատարածված սխալը վճարումն սկսելիս սկզբնական վիջեթից սկսելն է: Ավելի ճիշտ կլինի նախ նկարագրել պայմանագիրը՝ ինչ դաշտեր են փոխանցվում վճարմանը, ինչ կարգավիճակներ կան, ով է ճշմարտության աղբյուրը և ինչ է կատարվում սխալի դեպքում։
e-commerce, B2B-հաշիվների և CRM-պատվերների համար պայմանագիրը տարբեր կլինի: Առցանց խանութի համար զամբյուղը և առաքումը կարևոր են, B2B սցենարի համար՝ հաշիվ-ապրանքագիր և վճարում հղման միջոցով, CRM/ERP՝ կարգավիճակի համաժամացում և կառավարիչների գործողությունների աուդիտ:
- Արժույթի, գումարի և կլորացման կանոններ.
- Պատվերի եզակի ID և անզորության բանալին:
- Հաջողված, առկախ և սխալ կարգավիճակների ցանկ:
- Ֆիսկալ անդորրագիր ստեղծելու և նորից ուղարկելու կանոններ.
- Որտեղ ուղարկել արդյունքը՝ CMS, CRM, ERP, պահեստ կամ ներքին API:
Այնտեղ, որտեղ VPOS.am-ն հեշտացնում է սկսելը
Անհրաժեշտ է նվագախմբային շերտ, որտեղ վճարումները չպետք է լինեն առանձին, այլ բիզնես գործընթացի շրջանակներում:
VPOS.am-ը կարելի է համարել որպես վճարման կյանքի ցիկլի նորմալացման շերտ: Ձեռնարկությունները կարիք չունեն ամեն անգամ վերանախագծել կարգավիճակները, callback մշակել, կրկնել և համաժամացնել հաշվապահական համակարգերի հետ:
Այս մոտեցումը հատկապես օգտակար է, երբ վճարումը պետք է կապված լինի մի քանի ալիքների հետ՝ կայք, CRM հաշիվ ապրանքագիր, ձեռքով վաճառք, ERP պատվեր կամ բջջային սցենար: Կարևոր նպատակ է վճարման վարքագիծը նույնը դարձնել բոլոր մուտքի կետերի համար:
- Մեկ կարգավիճակի մոդել տարբեր մատակարարների համար:
- webhook/callback իրադարձությունների վերահսկվող մշակում:
- CRM, ERP և ֆիսկալիզացիայի տվյալների պատրաստում:
- Կայքի կոդում ավելի քիչ տրամաբանություն, որը հատուկ է մատակարարին:
FAQ
Կարո՞ղ է պատվերը վճարված համարվել հաջողության էջում redirect-ից հետո:
Ոչ: Հաջողության էջը հարմար է օգտատերերի համար, սակայն հետին պլանը պետք է առանձին ստուգի կարգավիճակը վճարման մատակարարի հետ կամ սպասի վստահելի callback/webhook-ին:
Արդյո՞ք CRM ինտեգրումն անհրաժեշտ է առաջին փուլում:
Ոչ միշտ: Օդաչուի համար կարող եք սկսել վեբկայքի և հետին պլանի կարգավիճակի ստուգմամբ, բայց անմիջապես ավելացնել այն դաշտերը, որոնք հետագայում կպահանջվեն CRM կամ ERP:
Ինչու՞ ավելի լավ է սկսել վճարման մեկ սցենարով:
Սա հեշտացնում է պայմանագիրը, սխալների հետ վարվելը, ֆիսկալիզացիան և օգտատերերի աջակցությունը ստուգելը` առանց վաճառքի բոլոր ուղիները միաժամանակ կոտրելու ռիսկի:
