ԼեզուHY
РусскийУкраїнськаՀայերենქართულიEnglishҚазақшаEspañolFrançaisDeutschItalianoفارسی
Վճարային օպերացիաներ Հրապարակվել է May 23, 2026 8 րոպե ընթերցում

Վճարում Հայաստանում բջջային հավելվածում՝ vPOS, Apple Pay և սերվերային կարգավիճակներ

Բջջային checkout-ը պահանջում է առանձին ստուգում. հավելվածը, զննարկիչը, բանկը, Apple Pay, վերադարձի հոսքը և հետին մասը պետք է համընկնեն մեկ վճարման կարգավիճակի:

Վճարում Հայաստանում բջջային հավելվածում՝ vPOS, Apple Pay և սերվերային կարգավիճակներ

Հոդվածի ֆոկուսը

Վճարում Հայաստանում բջջային հավելվածում՝ vPOS, Apple Pay և սերվերային կարգավիճակներՎճարային օպերացիաներառցանց վճարումների հաշտեցումpending վճարումներ3-D Secure Հայաստան

Mobile checkout-ը պարզապես WebView-ի կայք չէ

Օգտագործողը կարող է գնալ բանկային պատուհան, Apple Pay թերթ կամ արտաքին բրաուզեր, և հավելվածը պետք է ճիշտ վերականգնի կարգավիճակը:

Հավելված -> vPOS / Apple Pay -> Backend կարգավիճակ
Հավելվածը ցույց է տալիս UX-ը, սակայն հետնախագիծը պատկանում է վճարման վերջնական կարգավիճակին և բիզնեսի թարմացումներին:

Բջջային հավելվածի համար կարևոր է նախօրոք որոշել, թե ինչպես է բացվում վճարումը. ներկառուցված WebView, արտաքին զննարկիչ, SDK կամ մատակարարի կողմից տեղակայված checkout: Սխալ ընտրությունը կարող է խաթարել հաճախորդի վերադարձը, 3-D Secure, Apple Pay կամ ձախողման մշակումը:

Evocabank-ն ուղղակիորեն նկարագրում է V-POS-ը՝ որպես կայքի և բջջային հավելվածի լուծում: Ameriabank-ը հրապարակայնորեն հայտարարել է, որ vPOS հաճախորդները կարող են ակտիվացնել Apple Pay-ի ընդունումը առցանց խանութներում և հավելվածներում: Բայց գործառույթների կոնկրետ հասանելիությունը կախված է բանկից, պայմանագրից և տեխնիկական նախագծումից, ուստի այն պետք է ստուգվի մինչև մշակումը:

  • ստուգեք, թե արդյոք բանկը աջակցում է բջջային հավելվածների հոսքին.
  • անհրաժեշտության դեպքում նախապես պայմանավորվել Apple Pay-ի կամ դրամապանակի հոսքի մասին.
  • մի պահեք քարտի տվյալները հավելվածում.
  • փոխանցել վերջնական կարգավիճակը հետին պլանի միջոցով, և ոչ միայն callback հավելվածի միջոցով:

Ինչպես հաճախորդին վերադարձնել հավելված

Վերադարձի հոսքը պետք է դիմացկուն լինի հավելվածի փակմանը, պատուհանի փոխարկմանը և կարգավիճակի ուշացումներին:

Վերադարձի հոսք և խորը կապ
Հաջողության, ձախողման և pending էկրանները պետք է բոլորը զանգահարեն backend-ին՝ թարմ կարգավիճակ ստանալու համար:

Վճարումից հետո հաճախորդը կարող է վերադառնալ խորը հղումով, ունիվերսալ հղումով, զննարկիչով redirect կամ ձեռքով բացել հավելվածը: Հետևաբար, հավելվածը չպետք է համարի վճարումը հաջողված միայն այն պատճառով, որ հաջողության էկրանը բացվել է:

Ճիշտ սխեման․ հավելվածը ստանում է վճարման փորձի id կամ պատվերի id, ցուցադրում է միջանկյալ էկրան և պահանջում է հետին պլան։ Backend-ը ստուգում է մատակարարի կամ արդեն մշակված webhook-ի կարգավիճակը, այնուհետև վերադարձնում է նորմալացված արդյունքը հավելված:

  • հաջողության/ձախողման էկրանը միշտ կատարում է հետին պլանի կարգավիճակի ստուգում.
  • pending էկրանը թարմացվում է ինքնաբերաբար կամ սեղմելով թարմացման կոճակը;
  • կրկնակի վճարումը չի ստեղծում նոր պատվեր.
  • խորը հղումը չի պարունակում գաղտնիքներ կամ մատակարարի հավատարմագրեր:

Ինչ փորձարկել ցանցից առանձին checkout

Բջջային հոսքն ունի իր խափանման ռեժիմները, որոնք կարող են չլինել աշխատասեղանի checkout-ում:

Բջջային վճարումների փորձարկման դեպքեր
Հավելվածի ֆոն, դիտարկիչի անջատիչ, 3DS մարտահրավեր, Apple Pay, ցանցի կորուստ, webhook ուշացում:

Գործարկումից առաջ դուք պետք է առանձին անցնեք iOS և Android սցենարները. հավելվածը մտավ ֆոն, բանկը բացեց արտաքին պատուհան, հաճախորդը չեղարկեց Apple Pay, ցանցը անհետացավ վճարումից հետո, webhook հետաձգվեց, և հավելվածը փակվեց մինչև ZXQQ վերադարձը:

Եթե բջջային հավելվածը կապված է CRM, ERP, բաժանորդագրության կամ առաքման հետ, ապա այս համակարգերը պետք է ստանան նույն սերվերի կարգավիճակը, ինչ կայքը: Հակառակ դեպքում, mobile checkout-ը կդառնա անհամապատասխանության առանձին աղբյուր:

  • iOS Safari, Android Chrome և հավելվածի զննարկիչ;
  • Apple Pay կամ դրամապանակի հոսք, եթե միացված է բանկի կողմից;
  • հավելվածի փակում մինչև վերջնական callback;
  • հավելվածի վերագործարկում pending-ից հետո;
  • բջջային վճարումների հաշտեցում CRM/ERP-ի հետ:

FAQ

Հնարավո՞ր է բանկային վճարման էջ բացել անմիջապես հավելվածի ներսում:

Երբեմն դա հնարավոր է, բայց դա պետք է համաձայնեցվի բանկի հետ և ստուգի 3-D Secure, Apple Pay, վերադարձի URL և անվտանգության կանոնները: Հաճախ արտաքին զննարկիչը կամ տեղակայված checkout-ն ավելի ապահով է:

Արդյո՞ք Apple Pay-ը հասանելի է Հայաստանի բոլոր vPOS-ին:

Ոչ, հասանելիությունը կախված է բանկից, պայմանագրից և տեխնիկական դիզայնից։ Օրինակ, Ameriabank-ն հրապարակավ հայտարարեց այս հնարավորության մասին իր vPOS հաճախորդների համար, բայց դա չի նշանակում ավտոմատ հասանելիություն բոլոր մատակարարների համար:

Ո՞վ պետք է փոխի պատվերը վճարովի.

Backend. Հավելվածը կարող է արդյունքը ցույց տալ օգտվողին, սակայն պատվերի բիզնես կարգավիճակը պետք է փոխվի սերվերի կողմից ստուգումից կամ վստահելի webhook իրադարձությունից հետո:

Sources

  • Evocabank - V-POS terminalՊաշտոնական V-POS էջ, որտեղ նշված է կայքի և բջջային հավելվածի հասանելիությունը:
  • Ameriabank - Apple Pay for vPOS clientsԲանկի կողմից հանրային հաղորդագրություն առցանց խանութներում և հավելվածներում vPOS հաճախորդների համար vPOS-ի ընդունման հնարավորության մասին:
  • EMVCo - EMV 3-D Secure3-D Secure-ի նկարագրությունը քարտի նույնականացման համար, որը կարևոր է mobile checkout-ի համար:

Կարդացեք նաև

Առցանց վճարումների համադրում CRM-ի և ERP-ի հետ. ինչպես փակել օրը առանց ձեռքով քաոսի
Վճարային օպերացիաներ 9 րոպե ընթերցում

Առցանց վճարումների համադրում CRM-ի և ERP-ի հետ. ինչպես փակել օրը առանց ձեռքով քաոսի

Բանկի կամ մատակարարի, կայքի, CRM, ERP-ի և ներքին հաշվետվությունների միջև վճարումների համաձայնեցման գործնական սխեմա:

Կարդալ հոդվածը
Սպասվող վճարումներ. ինչ պետք է անի առցանց խանութը, CRM և աջակցություն
Վճարային օպերացիաներ 8 րոպե ընթերցում

Սպասվող վճարումներ. ինչ պետք է անի առցանց խանութը, CRM և աջակցություն

Սպասող - վճարման կյանքի ցիկլի նորմալ վիճակ: Կարևոր է ապրանքը ժամանակից շուտ բաց չթողնել և հաճախորդին չկորցնել անորոշ կարգավիճակի պատճառով։

Կարդալ հոդվածը
3-D Secure Հայաստանում առցանց վճարումների համար. ինչ պետք է հաշվի առնի կայքը
Վճարային օպերացիաներ 8 րոպե ընթերցում

3-D Secure Հայաստանում առցանց վճարումների համար. ինչ պետք է հաշվի առնի կայքը

3-D Secure-ն նվազեցնում է քարտի չներկայացված խարդախության ռիսկը, սակայն կայքի համար դա նաև նշանակում է UX, միջանկյալ կարգավիճակներ, կրկնվող փորձեր և թերի իսկորոշման ճիշտ մշակում:

Կարդալ հոդվածը