Русский
Українська
ქართული
English
Қазақша
Español
Français
Deutsch
Italiano
فارسی
Հոդվածի ֆոկուսը
Սպասումը սխալ չէ, այլ միջանկյալ վիճակ
Վճարումը կարող է պահանջել հաստատում, բանկային մշակում, 3-D Secure կամ webhook վերառաքում:
Շատ խանութների սխալը pending-ն որպես ձախողում ընկալելն է։ Գործնականում սա նորմալ վիճակ է. հաճախորդը կարող է անցել 3-D Secure, բանկը կարող է լրացնել թույլտվությունը, callback կարող է հետաձգվել, իսկ հետախուզությունը կարող է սպասել վերջնական կարգավիճակի ստուգմանը:
Կայքի ճիշտ պատասխանը՝ պատվերը մնում է pending վճարման մեջ, ապրանքները չեն թողարկվում, CRM-ն գործարքը չի փակում որպես վճարված, և համակարգը սկսում է կրկնակի ստուգում ըստ ժամանակացույցի կամ սպասում է ստորագրված webhook-ին: Հաճախորդին պետք է ցուցադրվի հստակ էկրան. «Վճարումը ստուգվում է, մենք ինքնաբերաբար կթարմացնենք կարգավիճակը»:
- մի փոխանցեք պատվերը վճարովի զննարկիչին redirect;
- մի ստեղծեք նոր պատվեր յուրաքանչյուր կրկնությունից.
- խանութի վճարման փորձ պատվերի կարգավիճակից առանձին.
- ցույց տալ հաճախորդին հստակ միջանկյալ կարգավիճակ:
Որքա՞ն սպասել վերջնական կարգավիճակին
Timeout-ը պետք է լինի բիզնես կանոն, այլ ոչ թե պատահական թիվ checkout կոդի մեջ:
Չկա մեկ համընդհանուր սպասման ժամանակ. դա կախված է մատակարարից, վճարման եղանակից, 3-D Secure-ից, գրավման տրամաբանությունից և ներքին գործընթացներից: Բայց կանոնը պետք է հստակ լինի. Օրինակ, առաջին րոպեներին համակարգը հաճախ ավտոմատ կերպով ստուգում է կարգավիճակը, այնուհետև պատվերը փոխանցում է «ստուգման կարիք ունի» կամ «ժամկետանց»:
Կարևոր է չեղարկել պատվերը շատ շուտ, եթե մատակարարը դեռ կարող է ուղարկել հաջող կարգավիճակ: Ընդհակառակը, դուք չեք կարող անվերջ պահել ձեր զամբյուղը և ապրանքի պահուստը, եթե վճարումը չի կատարվել: Հետևաբար, pending քաղաքականությունը պետք է համակարգված լինի վաճառքի, պահեստի և աջակցության հետ:
- կատարել առաջին ստուգումները ինքնաբերաբար հետնամասի միջոցով.
- հետագայում ստեղծել աջակցության կամ օպերատորի առաջադրանք.
- առանձին մշակել հաջող webhook UI նստաշրջանի ավարտից հետո;
- գրանցեք վերջնական ձախողման կամ ժամկետանց լինելու պատճառը:
Ինչ պետք է տեսնեն CRM-ն և աջակցությունը
Կառավարիչը կարիք չունի հումքի մատակարարի կարգավիճակի, այլ հստակ գործողության՝ սպասել, զանգահարել, կրկնել հղումը կամ փակել պատվերը:
CRM-ը պետք է ստանա նորմալացված կարգավիճակ: Եթե վճարումը pending է, կառավարիչը պետք է տեսնի, թե երբ է եղել վերջին ստուգումը, ինչ մատակարարի հղում, քանի փորձ է արդեն արվել և ինչ անել հետո:
Պատրաստի սկրիպտները օգտակար են աջակցության համար. եթե հաճախորդն ասում է, որ գումարը գանձվել է, օպերատորը ստուգում է մատակարարի տեղեկանքը և reconciliation queue-ն, այլ ոչ թե հաճախորդին խնդրում է նորից վճարել առանց ստուգելու: Սա նվազեցնում է կրկնակի վճարման և հաճախորդների հետ կոնֆլիկտների ռիսկը:
- pending_check - համակարգը դեռ սպասում է վերջնական կարգավիճակին;
- action_required - հաճախորդը պետք է կատարի քայլը բանկում;
- manual_review - անհրաժեշտ է օպերատոր կամ հաշվապահական բաժին;
- ժամկետանց - հղումը կամ վճարման փորձն այլևս ակտիվ չէ:
FAQ
Հնարավո՞ր է հաճախորդին ցույց տալ «կրկին վճարել» կոճակը, եթե կարգավիճակը pending է:
Հնարավոր է, բայց նոր փորձը պետք է լինի առանձին վճարման փորձ՝ կապված նույն պատվերի հետ։ Նախքան դա անելը, խորհուրդ է տրվում նորից ստուգել հին փորձի կարգավիճակը։
Ի՞նչ անել, եթե հաճախորդը պնդում է, որ գումարը գանձվել է, բայց կայքը ցույց է տալիս pending:
Դուք պետք է ստուգեք մատակարարի տեղեկանքը, մատակարարի կարգավիճակը և reconciliation queue: Դուք չեք կարող հաճախորդից պահանջել նորից վճարել, քանի դեռ հին փորձը չի լուծվել:
Ե՞րբ կարող է pending-ը փակվել որպես ձախողված կամ ժամկետանց:
Մատակարարի հստակ պատասխանից կամ համաձայնեցված ժամանակի ավարտից հետո, երբ համակարգը ևս մեկ անգամ ստուգեց կարգավիճակը և պահպանեց վերջնական որոշման պատճառը:
Sources
- Stripe Documentation - PaymentIntents lifecycleՎճարման կյանքի ցիկլի և միջանկյալ կարգավիճակների պաշտոնական նկարագրությունը, ինչպիսիք են պահանջներ_գործողությունը և մշակումը:
- Stripe API Reference - PaymentIntentsՀղում PaymentIntent կարգավիճակներին՝ որպես վճարման կյանքի ցիկլի պաշտոնական մոդելի օրինակ:
- Stripe Documentation - Webhook delivery behaviorՓաստաթղթեր webhook իրադարձությունների առաքման, կրկնակի փորձերի և իրադարձության պատվերի երաշխիքի բացակայության վերաբերյալ:
