Русский
Українська
ქართული
English
Қазақша
Español
Français
Deutsch
Italiano
فارسی
Հոդվածի ֆոկուսը
Սկզբնական խնդիր. վճարման մեթոդները չպետք է մասնատեն պատվերը
Հաճախորդին անհրաժեշտ է ընտրություն, իսկ թիմին՝ մեկ order id և հասկանալի արդյունք՝ անկախ վճարման եղանակից:
Երբ մեթոդները միացված են առանձին կոճակներով առանց ընդհանուր backend contract-ի, նույն պատվերը ստանում է տարբեր նույնացուցիչներ և կարգավիճակներ: Աջակցությունը չունի հստակ պատասխան, իսկ հաշվառումը՝ հաշտեցման միասնական ուղի:
Այս քեյսում պատվերը պահպանում է մեկ ներքին id, իսկ յուրաքանչյուր ընտրված մեթոդ ստեղծում է առանձին payment attempt: Method-ը, provider-ը, արտաքին id-ն, գումարը, արժույթը և կարգավիճակը մնում են մեկ payment model-ի կառուցվածքային դաշտեր:
- Մեթոդն ընտրելուց հետո պատվերի կազմը չփոխել առանց նոր փորձի:
- Provider-ը և method-ը պահել նորմալացված արժեքներով:
- Failed կամ expired-ից հետո հաճախորդին տալ հասկանալի fallback:
- Մեթոդը հաստատված չհամարել մինչև սերվերային արդյունքը:
Լուծումը. նորմալացնել կարգավիճակները և թույլատրելի անցումները
Provider-ի կարգավիճակների բառապաշարը կարող է տարբեր լինել, սակայն բիզնեսին անհրաժեշտ է մեկ վիճակների և բացառությունների մոդել:
Backend-ը ընտրված մեթոդի իրադարձությունը բերում է ընդհանուր կարգավիճակի մոդելի՝ ստուգելով իսկությունը, գումարը, արժույթը և կոնկրետ payment attempt-ը:
Այս շերտը կարևոր է վերադարձների, կրկնվող իրադարձությունների և հաշվետվությունների համար. բիզնես գործընթացը չպետք է կախված լինի արտաքին dashboard-ի ձևակերպումից: Նորմալացումը չի փոխարինում յուրաքանչյուր provider-ի ընթացիկ կանոնների ստուգմանը:
- Պահել արտաքին և ներքին կարգավիճակների համապատասխանության աղյուսակ:
- Հետաքննության համար պահպանել provider raw status-ը:
- Ուշացած իրադարձությամբ paid-ը failed չդարձնել:
- Անորոշ դեպքերը ուղարկել manual review:
Գործարկումից հետո. հաշտեցում ըստ մեթոդի և provider-ի
Մեկ dashboard-ը պետք է ցույց տա հաստատված գործողությունները, pending-ը, վերադարձները և տարբերությունները յուրաքանչյուր մեթոդի համար:
Օպերացիոն թիմը կարող է տեսնել ընդհանուր գումարը և ֆիլտրել մեթոդով, provider-ով, ժամանակահատվածով, կարգավիճակով և վերադարձով: Սա օգտակար է աջակցության և հերթափոխի փակման համար:
Եթե provider report-ը և ներքին ledger-ը տարբերվում են, բացառությունը կապված է կոնկրետ payment attempt-ի հետ: Պատվերը չպետք է ձեռքով ուղղել առանց պատճառի, պատմության և սկզբնական աղբյուրի ստուգման:
- Համեմատել provider report-ը ներքին payment ledger-ի հետ:
- Pending և expired-ը paid-ից առանձին ցույց տալ:
- Վերադարձի դեպքում պահպանել սկզբնական method-ը:
- Սահմանել ձեռքով ուղղումների դերերն ու ընթացակարգը:
FAQ
Արդյո՞ք յուրաքանչյուր վճարման մեթոդին առանձին պատվեր է պետք:
Ոչ: Մեկ պատվերը կարող է ունենալ մի քանի payment attempts: Առանձին էություն պետք է լինի վճարման փորձը, ոչ թե պատվերը:
Կարո՞ղ են տարբեր provider-ները օգտագործել մեկ status set:
Այո, բիզնես գործընթացին անհրաժեշտ է նորմալացված մոդել: Սակայն audit-ի և հետաքննության համար պահեք provider-ի սկզբնական կարգավիճակը:
Ի՞նչ ստուգել նոր վճարման մեթոդ ավելացնելուց առաջ:
Provider-ի ընթացիկ պայմանները, կարգավիճակներն ու վերադարձները, սերվերային ստուգումը, կայքի պահանջները և հաշտեցման report-ի ձևաչափը:
