Նկարագրություն
VPOS.am-ը merchant-ի տեղեկատվական համակարգերը կապում է նրա բանկի կամ լիցենզավորված provider-ի միջերեսին և համաժամացնում հաստատված կարգավիճակները։ Գումարն ընդունում և փոխանցում է բանկը կամ provider-ը՝ merchant-ի հետ առանձին պայմանագրով։
Բանկային միջերեսների ինտեգրման տեխնիկական ծրագրային ապահովում
Merchant-ը առանձին պայմանագիր է կնքում անմիջապես բանկի կամ լիցենզավորված վճարային provider-ի հետ։ Գումարն ընդունում և փոխանցում են նրանք, իսկ VPOS.am-ը տրամադրում է միայն համաձայնեցված ծրագրային ինտեգրման շերտը։
Երբ է պետք VPOS Pay-ը
VPOS Pay-ը միայն դասական online shop-ի համար չէ: Այն օգտակար է, երբ վճարումը պետք է կապվի պատվերի, հաճախորդի, հաշվի, CRM funnel-ի, պահեստի կամ ERP workflow-ի հետ:
Տիպիկ սցենար. հաճախորդը վճարում է կայքում, server-ը հաստատում է վճարումը, պատվերի կարգավիճակը փոխվում է, CRM-ը ստանում է event, fiscal գործընթացը սկսվում է, իսկ օպերատորը տեսնում է միայն իրականում վճարված պատվերները:
- E-commerce checkout WooCommerce, OpenCart, Laravel եւ custom frontend-ների համար
- CRM հաշիվների եւ հայտերի վճարում առանց bank statement-ի ձեռքով ստուգման
- B2B պորտալներ հաշիվների, բաժանորդագրությունների, ամրագրումների եւ ծառայությունների համար
Ինչպես է հաստատվում վճարման արդյունքը
Browser redirect-ը օգտակար է user experience-ի համար, բայց այն չպետք է լինի վերջնական source of truth: Վերջնական արդյունքը հաստատվում է server-side status request-ով, signed event-ով կամ երկու մեխանիզմով միասին:
Այս մոտեցումը պաշտպանում է բիզնեսը, երբ հաճախորդը փակում է tab-ը, վերադառնում է provider-ի պատասխանից շուտ, webhook-ը գալիս է կրկնակի կամ downstream համակարգը ժամանակավորապես հասանելի չէ:
- Ոչ մի պատվեր paid չի դառնում միայն browser URL-ի հիման վրա
- Կրկնվող events-ը մշակվում են idempotent ձեւով
- Provider errors-ը պահպանվում են օպերացիոն ստուգման համար
Ինչ է տալիս pilot-ը
Առաջին launch-ը ճիշտ է սահմանափակել մեկ payment method-ով, մեկ վաճառքի ալիքով եւ հստակ statuses-ով: Այդպես հնարավոր է ստուգել checkout-ը, refunds-ը, rejected payments-ը, manual review-ն եւ CRM/ERP handoff-ը:
Pilot-ի կայունացումից հետո կարելի է ավելացնել երկրորդ provider, այլ payment methods, fiscal queue, reconciliation եւ կոնկրետ բիզնեսի ինտեգրումներ:
Հաճախակի հարցեր
Կարելի՞ է վճարումը successful համարել հաճախորդի կայք վերադառնալուց հետո:
Ոչ: Return URL-ը օգտակար է interface-ի համար, բայց final payment status-ը պետք է հաստատվի server-side կամ signed webhook event-ով:
Ո՞րն է online payments-ը սկսելու անվտանգ տարբերակը:
Սկսեք մեկ payment method-ից, մեկ sales channel-ից եւ fixed status map-ից: Checkout-ը, declines-ը, refunds-ը եւ CRM/ERP handoff-ը ստուգելուց հետո flow-ը կարելի է ընդլայնել: