ARCA քարտեր և 3-D Secure՝ ինչ պետք է իմանա հայաստանյան առցանց վաճառողը

Քարտերը դեռ այն մեթոդն են, որը հասնում է ամեն գնորդի, այդ թվում՝ արտասահմանում գտնվող նրանց, ովքեր վճարում են հայաստանյան խանութին։ Հայաստանում այդ վճարումներն անցնում են ARCA-ի՝ ազգային քարտային ցանցի, և էքվայրինգն իրականացնող անդամ բանկերի միջոցով։ Այս գրառումն անդրադառնում է այն մասերին, որոնց հետ վաճառողն իրականում գործ ունի՝ ով ինչ է տալիս, ինչ է փոփոխում 3-D Secure-ը, ինչպես թեստավորել և ինչ է ասում API-ն վերադարձների մասին։

Ով ով է քարտային վճարման մեջ

Երեք կողմ է կանգնած Ձեր checkout-ի մեկ կոճակի հետևում։

• Քարտային ցանցը։ Visa, Mastercard և ArCa քարտերը մշակվում են ARCA-ի և նրա անդամ էքվայրինգ բանկերի միջոցով։
• Ձեր էքվայրինգ բանկը։ Սա այն կողմն է, ում հետ Դուք ստորագրում եք ինտերնետ էքվայրինգի պայմանագիր, ով սահմանում է Ձեր տոկոսադրույքը և հաշվարկում գումարը Ձեր հաշվին։ Ամերիաբանկը, Ինեկոբանկը, Էվոկաբանկը, Կոնվերս Բանկը, Արարատբանկը, ԱԿԲԱ-ն, ԱմիոԲանկը, ԱյԴի Բանկը, Արդշինբանկը և ARCA-ի մյուս անդամ բանկերն իրենցից յուրաքանչյուրը հանդես է գալիս որպես առանձին պրոցեսոր՝ սեփական տվյալներով ու սեփական checkout-ի տարբերակով։
• Դարպասը։ Paynet-ը կանգնած է նրանց բոլորի առջև, որպեսզի Ձեր խանութը խոսի մեկ API-ով և ունենա մեկ checkout՝ ամեն բանկի համար առանձինի փոխարեն։ Այն չի պահում Ձեր գումարը և չի փոխարինում Ձեր բանկային պայմանագիրը։

Վերջին կետը հատկապես կարևոր է հասկանալ։ Դարպաս ավելացնելը չի փոխում, թե ում հետ եք ստորագրել, որքան է Ձեր էքվայրինգի տոկոսադրույքը, կամ ով է Ձեզ վճարում։ Այն փոխում է միայն, թե քանի ինտեգրում եք սպասարկում։

Տվյալները, որոնք տալիս է Ձեր բանկը

Քարտային տվյալները կարճ են, ինչը զարմացնում է նրանց, ովքեր սպասում են ֆայլերով լցված պանակի։ ARCA-ի և ARCA-ի ենթակառուցվածքով աշխատող անդամ բանկերի համար Դուք ստանում եք.

• API օգտանուն
• API գաղտնաբառ

Դա էլ ամբողջն է։ Դարպասի հասցեն արդեն որոշված է ըստ մատակարարի, ուստի այլ բան կարգավորելու կարիք չկա։ Ամերիաբանկի դարպասը միակ բացառությունն է հավաքածուում. այն նույնականացվում է օգտանունով, գաղտնաբառով և Client ID-ով։

Բանկային տվյալների հետ գալիս են երկու գործնական նրբություն.

• IP հասցեների սպիտակ ցուցակագրում։ Որոշ էքվայրերներ ընդունում են վճարման հարցումներ միայն այն հասցեներից, որոնք գրանցված են Ձեր վաճառողի հաշվին։ Ինեկոբանկն այսպես է աշխատում։ Քանի որ Դուք եք կնքել բանկային պայմանագիրը, հենց Դուք եք կարող հարցնել, և Paynet-ը ցույց է տալիս ճշգրիտ հասցեն Ձեզ ուղարկելու համար՝ հենց այն պահին, երբ ընտրում եք այդպիսի մատակարար։ Մինչև Ձեր բանկը գրանցի այն, այդ մատակարարով ամեն վճարում ձախողվում է, և ոչ մի ճիշտ կոդ դա չի շտկում։
• Ո՞ր դարպասի տարբերակի վրա եք Դուք։ Մատակարարի կարգավորումներում կա EPG տարբերակ, որն օգտագործում է ARCA EPG դարպասը՝ iPay-ի փոխարեն։ Եթե Ձեր բանկն ասել է, թե որի վրա է Ձեր տերմինալը, կարգավորեք համապատասխան։ Եթե չի ասել, հարցրեք, փոխանակ գուշակելու և հետո վրիպազերծելու մերժված մուտքը։

Տվյալները պահեք այնտեղ, որտեղ նրանց տեղն է։ Paynet-ում դրանք պահվում են գաղտնագրված, և բանալիներին ու տվյալներին առնչվող route-երը Ձեզանից նորից գաղտնաբառի հաստատում են խնդրում։ Ինքնին քարտային տվյալները Ձեզ ընդհանրապես չեն հասնում. գնորդները քարտի տվյալները մուտքագրում են լիցենզավորված պրոցեսորի էջում, ուստի դրանք երբեք չեն պահվում Ձեր սերվերում և երբեք չեն դառնում Ձեր պատասխանատվությունը։

Ինչ է փոփոխում 3-D Secure-ը

3-D Secure-ը այն քայլն է, երբ քարտ թողարկողը ստուգում է քարտապանին՝ նախքան առցանց վճարումը հաստատելը, սովորաբար՝ մեկանգամյա կոդով կամ բանկի հավելվածում հաստատմամբ։ Վաճառողի տեսանկյունից այն փոփոխում է երեք բան, և բոլորն էլ վերաբերում են Ձեր պատվերների կառավարմանը, ոչ թե Ձեր վճարային կոդին։

Գնորդն ավելի երկար և ավելի շատ էկրաններով է հեռանում Ձեր կայքից։ Քարտային վճարումն արդեն իսկ նշանակում էր վերահղում։ Ստուգման քայլն ավելացնելով՝ ավելանում են այն կետերը, որտեղ գնորդը կարող է տատանվել, փակել ներդիրը կամ կորցնել կապը։

Ավելի շատ վճարումներ ավարտվում են վիճակով, որը պարզապես «մերժված» չէ։ Ստուգումը կարող է ձախողվել ինքնուրույն, անկախ քարտի վավերականությունից։ Paynet-ը սա ցույց է տալիս առանձին. checkout-ը գնորդին ասում է «Քարտի ստուգումը ձախողվեց։ Կրկին փորձեք», ինչը տարբեր հաղորդագրություն է, քան «Քարտը մերժվեց» կամ «Քարտի վրա բավարար միջոցներ չկան»։ Ցույց տվեք տարբերությունը նաև Ձեր սեփական վահանակում։ Ստուգման ձախողումն սովորաբար արժե կրկնել, մերժումը՝ սովորաբար ոչ։

Ժամանակացույցն ավելի քիչ կոկիկ է դառնում։ Վճարումը բաց է մնում 20 րոպե, մինչև ժամկետը լրանում է, մինչդեռ ինքը՝ checkout_url-ը, մնում է վավեր 24 ժամ։ Իսկ մատակարարից ուշացած հաստատումը կարող է վճարումը, որն արդեն կարդացվել է որպես failed կամ expired, տեղափոխել completed-ի։ Դա շտկելու վրիպակ չէ, դա այն գնորդի իրականությունն է, ով հենց նոր ավարտել է ստուգումը՝ Ձեր համբերությունը սպառվելուց հետո։ Միշտ գործեք ըստ Ձեր կարդացած վերջին վիճակի, ոչ թե առաջին webhook-ի, և երբեք մի նշեք պատվերը վճարված միայն այն պատճառով, որ բրաուզերը հասել է Ձեր շնորհակալության էջ։ Ստուգեք webhook-ի ստորագրությունը, բացառեք կրկնօրինակները delivery_id-ի հիման վրա, ապա կարդացեք ճշմարտությունը հետ՝ GET /api/v1/orders/{order_id}/payment-ով։

Ընտանիքում կա նաև քարտային վճարման QR տարբերակ։ ArcaQR-ով գնորդը վճարելու համար սկանավորում է կոդը բանկի հավելվածով, և կոդը կարճատև է. checkout-ը հետհաշվարկում է QR, որը վավեր է 60 վայրկյան և ժամկետը լրանալիս առաջարկում է նոր մեկը։

Քարտային վճարումների թեստավորումը՝ նախքան կենդանի աշխատանքի անցնելը

Քարտային պրոցեսորները հայաստանյան վճարային պատկերի այն մասն են, որտեղ կարելի է լիարժեք փորձել, քանի որ ARCA-ն միակ ընտանիքն է իրական թեստային միջավայրով։ Հասանելի են երկու շերտ, և Ձեզ երկուսն էլ պետք են։

Paynet-ի sandbox-ը՝ Ձեր սեփական կոդի համար։ Տեղադրեք Sandbox մատակարարը և ուղարկեք "processor": "sandbox", կամ օգտագործեք թեստային API բանալի, որը սկսվում է sk_test_-ով։ Ոչ մի բանկի հետ կապ չի հաստատվում, ոչինչ չի տեղափոխվում, ոչինչ չի հաշվարկվում։ Քարտի համարն է որոշում արդյունքը, ինչն էլ դարձնում է սա հատուկ օգտակար հենց քարտային աշխատանքի համար.

• 4111 1111 1111 1111 հաստատված
• 4000 0000 0000 0002 մերժված թողարկողի կողմից
• 4000 0000 0000 0069 անբավարար միջոցներ
• 4000 0000 0000 0101 3-D Secure ձախողում
• 4000 0000 0000 0119 պրոցեսորի սպասման ժամկետ
• 4000 0000 0000 0127 գումարի սահմանաչափի գերազանցում
• 4000 0000 0000 0200 կրկնվող գործարք
• 4000 0000 0000 0259 գործարքի ժամկետի ավարտ
• 4000 0000 0000 0309 պրոցեսորն անհասանելի է
• 4000 0000 0000 0341 ընդհանուր ձախողում

Միտումնավոր փորձարկեք 3-D Secure ձախողման դեպքը և տեսեք, թե ինչ է Ձեր խանութը ցույց տալիս գնորդին և ինչ է տեսնում Ձեր աջակցման թիմը։ Այդ հինգ րոպեն արժե ցանկացած չափի ընթերցանությունից ավելին։

Բանկի սեփական թեստային տերմինալը՝ Ձեր տվյալների համար։ ARCA ընտանիքի մատակարարներն ապահովում են թեստային ռեժիմ առանձին թեստային տվյալներով։ Ձեր բանկը հատկացնում է OrderID-ի միջակայք թեստային վճարումների համար, և Դուք մատակարարի կարգավորումներում մուտքագրում եք դրա սկիզբը և վերջը; թեստային վճարումներն այնուհետև օգտագործում են միջակայքի հաջորդ չօգտագործված համարը և երբեք չեն կրկնում։ Եթե Ձեր բանկը տվել է թեստային տերմինալ, օգտագործեք այն, նախքան մատակարարը կենդանի ռեժիմի փոխադրելը։

Ցանկացած դեպքում, կենդանի վճարումները սկսվում են միայն Ձեր բիզնեսի ստուգումից հետո։ Մինչ այդ ամեն ինչ աշխատում է թեստային ռեժիմում, անսահմանափակ անվճար թեստային վճարումներով, ուստի փաստաթղթերի սպասելու պատճառ չկա մինչև կառուցելը սկսելը։

Վերադարձները, ինչպես նկարագրում է դրանք API-ն

Վերադարձը մեկ կանչ է. POST /api/v1/payments/{uuid}/refund։ Մարմինն ընդունում է կամընտիր amount, որը լռելյայն հավասար է մնացած ամբողջ գումարին, և կամընտիր reason։ Կարևորն այն մի քանի կանոններն են, որոնք դրա շուրջն են։

• Ամբողջական և մասնակի վերադարձներն այլ կերպ են վարվում գրառման մեջ։ completed վճարումը դառնում է refunded միայն ամբողջական վերադարձի դեպքում։ Մասնակի վերադարձը կարգավիճակը թողնում է completed, բարձրացնելով refunded_amount-ը զրոյից վեր։ Եթե Ձեր հաշվեկշիռման ստուգումը նայում է միայն կարգավիճակին, մասնակի վերադարձներն այնտեղից անաղմուկ կանհետանան։
• Ուղարկեք Idempotency-Key։ Դրանով նույն բանալին նույն վճարման վրա վերադարձնում է նույն վերադարձը՝ 201 ստեղծելիս և 200՝ կրկնության դեպքում։ Առանց դրա երկրորդ կանչը երկրորդ վերադարձ է։ Եթե վերադարձի կանչը սպասման ժամկետը գերազանցում է, նախքան որևէ բան կրկնելը կարդացեք վճարումը հետ՝ GET /api/v1/payments/{uuid}-ով։
• Կարդացեք սխալի կոդերը, նրանք տարբեր բան են նշանակում։ not_refundable, already_refunded, refund_in_progress, refund_declined, processor_unavailable և refund_outcome_unknown-ը բոլորն էլ գալիս են որպես 409, իսկ refund_not_supported, invalid_amount և amount_exceeds_remaining-ը՝ որպես 422։ Վերադարձ, որի արդյունքն անհայտ է, նույնը չէ, ինչ վերադարձ, որը ձախողվել է, և դրանք միասին դիտարկելը հենց այն է, թե ինչպես է հաճախորդը երկու անգամ վճարվում։
• Վերադարձներն էլ webhook-ներ են ուղարկում։ payment.refunded իրադարձությունն ուղարկվում է վճարման callback_url-ին՝ կրելով վերադարձի uuid-ը, գումարը և պատճառը։
• Բանալիները կարող են ունենալ շրջանակ։ Միայն վճարումների համար ստեղծված API բանալին կարող է ստեղծել և կարդալ վճարումներ ու հղումներ, բայց չի կարող վերադարձնել կամ գնել միավորներ, և փորձելիս ստանում է 403 insufficient_scope։ Այդպիսի բանալի տվեք խանութի front-end-ին կամ կապալառուին, և ամբողջական հասանելիությամբ բանալիները պահեք Ձեր սեփական սերվերում։

Գնագոյացման տեսանկյունից՝ վերադարձներն ինքնին անվճար են։ Ձեր ծախսած գործարքի միավորը չի վերականգնվում, քանի որ դա հաջողված վճարում էր, երբ տեղի ունեցավ։ Ձախողված վճարումները և բոլոր թեստային վճարումներն էլ ոչինչ չեն արժենում։ Մնացածը գների էջում է։

Ինչ անել հաջորդը

• Ձեր էքվայրինգ բանկի հետ ճշտեք, թե ինչ տվյալներ եք ունենալու՝ օգտանուն և գաղտնաբառ, գումարած Client ID, եթե Դուք Ամերիաբանկում եք, և արդյոք Ձեր տերմինալը EPG-ի, թե iPay-ի վրա է։
• Եթե Ձեր բանկը սպիտակ ցուցակագրում է հասցեներ, մատակարարի էջում ցույց տրված IP-ն ուղարկեք նրանց՝ նախքան որևէ բան փորձարկելը։
• Ավելացրեք մատակարարը Paynet-ում, միացրեք այն Ձեր հաստատված դոմենին և ստուգեք, որ դոմենը թվարկում է այն որպես ակտիվ մեթոդ։
• Վազեցրեք sandbox-ի քարտերի ամբողջ ցանկը, ներառյալ 3-D Secure ձախողումը, և համոզվեք, որ Ձեր վահանակը տարբերում է ստուգման ձախողումները մերժումներից։
• Կոդում որոշեք, թե ինչպես եք վարվում ուշացած հաստատման և անհայտ արդյունքով վերադարձի հետ։
• Ամբողջական endpoint-ների ցանկը, ներառյալ վերադարձներն ու webhook-ները, հասանելի է paynet.am/docs/api-ում, ավելի կարճ շրջագայությամբ՝ մշակողների էջում։

ARCA-ն, Visa-ն, Mastercard-ը և վերևում նշված բանկերի անունները պատկանում են իրենց տերերին։ Paynet-ը Երևանում գործող Digital Brains ՍՊԸ-ի կողմից շահագործվող անկախ վճարային դարպաս է. վաճառողներն ունեն իրենց սեփական էքվայրինգի պայմանագրերը։