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