Русский
Українська
ქართული
English
Қазақша
Español
Français
Deutsch
Italiano
فارسی
Հոդվածի ֆոկուսը
Սկզբնական խնդիր. կապել զամբյուղը, պատվերը և վճարումը
Checkout-ը պետք է պահպանի գումարի, առաքման և պահեստավորման համատեքստը այն բանից հետո, երբ հաճախորդը անցնում է բանկի վճարման էջ:
WooCommerce-ի ռիսկը առաջանում է, երբ պատվերը paid է նշվում return URL-ից անմիջապես հետո: Հաճախորդը կարող է փակել էջը, կրկին բացել հղումը կամ վերադառնալ վերջնական բանկային կարգավիճակից առաջ:
Այս քեյսում պատվերը մինչև vPOS redirect-ը մնում է սպասվող վճարման վիճակում: Backend-ը պահպանում է order id-ն, գումարը, արժույթը և արտաքին payment id-ն, որպեսզի արդյունքը ստուգվի առանց ձեռքով գուշակման:
- Ֆիքսել զամբյուղը, զեղչը, առաքումը և արժույթը payment session-ից առաջ:
- Օգտագործել մեկ ներքին order id բոլոր հարցումներում և լոգերում:
- Կրկնակի վճարման սեղմումով նոր պատվեր չստեղծել:
- Ներքին և արտաքին payment id-ները պահել առանձին:
Լուծումը. webhook-ը և սերվերային ստուգումը կառավարում են կարգավիճակը
Frontend-ը հաճախորդին ցույց է տալիս արդյունքը, բայց վճարման ճշմարտության աղբյուրը մնում է backend-ի ստուգումը:
Վճարումից հետո հաճախորդը վերադառնում է արդյունքի էջ, իսկ backend-ը առանձին ընդունում է callback կամ webhook և ստուգում է ստորագրությունը, գումարը, արժույթը, order id-ն ու թույլատրելի կարգավիճակի անցումը:
Կրկնվող իրադարձությունը նոր պատվեր, կտրոն կամ ծանուցում չի ստեղծում: Handler-ը օգտագործում է idempotency և պահպանում է փորձերի պատմությունը: Pending, failed, paid և refunded-ը մնում են առանձին իրադարձություններ:
- Սերվերում ստուգել իրադարձության իսկությունը և կարևոր դաշտերը:
- Առանձնացնել վճարման, պատվերի և ֆիսկալ կտրոնի կարգավիճակները:
- Պահել audit trail կրկնվող callbacks-ի և ձեռքով գործողությունների համար:
- Pending վճարմամբ ապրանքը չառաքել:
Գործարկումից հետո. վերադարձներ և ամենօրյա հաշտեցում
Թիմը պետք է տեսնի ինչպես հաջող վճարումները, այնպես էլ WooCommerce-ի, բանկի և ներքին հաշվառման անհամապատասխանությունները:
Վերադարձը գրանցվում է որպես սկզբնական վճարման հետ կապված առանձին գործողություն: Սա պահպանում է պատմությունը մասնակի վերադարձների, կրկնվող webhooks-ի և հետագա ֆիսկալացման համար:
Ամենօրյա հաշտեցումը համեմատում է հաստատված վճարումները, չեղարկումները, վերադարձները և սպասվող պատվերները: Թիմը ստանում է բացառությունների ցուցակ, ոչ թե վերականգնում պատմությունը սքրինշոթերից:
- Վերադարձի դեպքում սկզբնական վճարումը չջնջել:
- Անհամապատասխանությունները որոնել order id-ով և provider payment id-ով:
- Վերանայել կրկնվող փորձերն ու ժամկետանց հղումները:
- Սահմանել վեճերի աջակցման ուղի:
FAQ
Կարո՞ղ է WooCommerce-ը պատվերը paid նշել return URL-ով:
Ոչ: Return URL-ը նախատեսված է հաճախորդի փորձի համար: Վերջնական կարգավիճակը պետք է հաստատվի սերվերային ստուգմամբ կամ ճիշտ մշակված webhook-ով:
Ինչպե՞ս կանխել կրկնվող վճարումները կամ callbacks-ը:
Պահպանել կայուն order և payment id-ներ, օգտագործել idempotency key, ստուգել թույլատրելի անցումները և լոգավորել յուրաքանչյուր առաքման փորձ:
Ի՞նչն է կարևոր վերադարձների համար:
Վերադարձը պետք է լինի առանձին գործողություն, կապված սկզբնական վճարման հետ: Այն չպետք է ջնջի պատվերի կամ վճարման պատմությունը:
