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