Վճարումներ

01Ովքեր են մասնակցում և ինչպես է շարժվում գումարը

Պատկերացրեք չորս կողմ։ Հաճախորդը վճարում է։ Merchant-ը (ձեր խանութը) վաճառում է։ Acquirer-ը merchant-ի բանկն է, որին սովորաբար հասնում են վճարային gateway-ի կամ պրովայդերի միջոցով (Stripe, Adyen, տեղական բանկի վիրտուալ POS)։ Issuer-ը հաճախորդի բանկն է, որը հաստատում կամ մերժում է։ Քարտային ցանցերը, ինչպիսիք են Visa-ն և Mastercard-ը, հաղորդագրություններ են փոխանցում նրանց միջև։ Քարտային վճարումն ունի երկու քայլ՝ authorisation (issuer-ը ռեզերվում է գումարը) և capture (գումարն իրականում գանձվում է)։ Շատ խանութներ capture են անում անմիջապես․ ռեստորանները կամ այն խանութները, որոնք վստահ չեն մնացորդի հարցում, կարող են սկզբում authorise անել, իսկ capture՝ պատվերը հաստատելիս։ Settlement-ը՝ գումարի մուտքը ձեր հաշվին, տեղի է ունենում ավելի ուշ, հաճախ մեկ օր կամ ավելի անց՝ միջնորդավճարները հանած։

• Authorisation՝ «այս քարտը կարո՞ղ է վճարել 50.00» — միջոցները արգելափակվում են։
• Capture՝ «հիմա գանձիր 50.00-ը» — կարող է լինել ամբողջական կամ մասնակի։
• Void՝ չեղարկել authorisation-ը մինչև capture-ը․ refund՝ վերադարձնել գումարը capture-ից հետո։

02Ինտեգրացիայի ոճեր՝ redirect, hosted fields և SDK-ներ

Քարտի տվյալները հավաքելու երեք տարածված եղանակ կա։ Redirect-ը (hosted payment page) հաճախորդին ուղարկում է gateway-ի էջ և հետ՝ ձեր return URL-ին․ ամենապարզն է և compliance-ի ամենափոքր ծավալն ունի, տարածված է բանկային gateway-ների հետ։ Hosted fields-ը կամ ներկառուցված կոմպոնենտները (Stripe Payment Element, Adyen Drop-in) քարտի դաշտերը ցուցադրում են iframe-ների մեջ ձեր էջում, այնպես որ ամեն ինչ native է թվում, իսկ քարտի տվյալներն ուղիղ գնում են պրովայդերին։ Մոբայլ SDK-ները նույնն անում են հավելվածներում, իսկ wallet հավելվածները կարելի է բացել deep link-երով կամ native մոդուլներով։ Ինչ ոճ էլ լինի, flow-ը նույնն է՝ ձեր սերվերը ստեղծում է վճարման session պատվերի համար՝ գումարով և արժույթով, հաճախորդն այն ավարտում է պրովայդերի մոտ, և ձեր սերվերն արդյունքն իմանում է պրովայդերից, երբեք միայն բրաուզերից։

1// Server: create a payment session for an existing order (Stripe example)
2import Stripe from "stripe";
3const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
4 
5export async function startPayment(order: { id: string; total: number; currency: string }) {
6  const intent = await stripe.paymentIntents.create(
7    {
8      amount: order.total, // integer minor units
9      currency: order.currency.toLowerCase(),
10      metadata: { orderId: order.id },
11      automatic_payment_methods: { enabled: true },
12    },
13    { idempotencyKey: `order-${order.id}-attempt-1` },
14  );
15  return intent.client_secret; // the client confirms with this; no card data touches us
16}

033-D Secure և հաճախորդի ուժեղ նույնականացում

3-D Secure-ը (3DS) այն լրացուցիչ քայլն է, երբ issuer-ը հաճախորդից խնդրում է հաստատել վճարումը, սովորաբար բանկային հավելվածում կամ SMS կոդով։ Ներկայիս տարբերակը՝ EMV 3DS-ը (հաճախ կոչվում է 3DS2), ուղարկում է սարքի և գործարքի հարուստ տվյալներ, այնպես որ շատ վճարումներ անցնում են «frictionless»՝ առանց challenge-ի, և միայն ռիսկայինները են challenge ստանում։ Եվրոպայում PSD2-ով սահմանված strong customer authentication-ը (SCA) դա պարտադիր է դարձնում առցանց քարտային վճարումների մեծ մասի համար․ այլ տեղերում այն կամընտիր է, բայց նվազեցնում է խարդախությունը և սովորաբար խարդախության chargeback-ի պատասխանատվությունը տեղափոխում է issuer-ի վրա։ Ձեզ համար 3DS-ը նշանակում է, որ վճարումն ակնթարթային չէ․ այն կարող է կանգ առնել challenge-ի համար, ապա շարունակվել։ Ձեր flow-ը պետք է կարողանա մշակել «requires action»-ի նման կարգավիճակ և հաճախորդ, որը կիսաճանապարհին փակում է tab-ը։

04Webhook-ներ, callback-ներ և idempotency

Բրաուզերի redirect-ը ձեր կայք վճարման ապացույց չէ․ օգտատերերը փակում են tab-երը, ցանցն ընդհատվում է, և ցանկացած մեկը կարող է ձեռքով մուտքագրել return URL-ը։ Ճշմարտության աղբյուրը server-to-server հաղորդագրությունն է՝ webhook (պրովայդերը կանչում է ձեր endpoint-ը) կամ կարգավիճակի query, որը դուք եք անում պրովայդերին։ Ստուգեք յուրաքանչյուր webhook-ի ստորագրությունը, գտեք վճարումը ձեր սեփական ID-ով և թարմացրեք պատվերը transaction-ի ներսում։ Պրովայդերները կրկնում են webhook-ները, ուստի նույն event-ը կարող է գալ մի քանի անգամ կամ խառը հերթականությամբ․ պահեք մշակված event-ների ID-ները և handler-ը դարձրեք idempotent, այսինքն՝ երկու անգամ աշխատեցնելը նույն էֆեկտն ունենա, ինչ մեկ անգամը։ Idempotency key-եր օգտագործեք նաև ձեր դուրս գնացող կանչերում, որպեսզի կրկնված «create payment»-ը կամ «refund»-ը երբեք երկու անգամ չգանձի կամ չվերադարձնի։

1// Webhook handler: verify, deduplicate, apply once
2app.post("/webhooks/payments", express.raw({ type: "application/json" }), async (req, res) => {
3  const event = stripe.webhooks.constructEvent(
4    req.body, req.header("stripe-signature")!, process.env.STRIPE_WEBHOOK_SECRET!,
5  );
6  await db.transaction(async (tx) => {
7    const seen = await tx.processedEvents.insertIgnore({ id: event.id }); // unique key
8    if (!seen.inserted) return; // duplicate delivery: already handled
9    if (event.type === "payment_intent.succeeded") {
10      const orderId = event.data.object.metadata.orderId;
11      await tx.orders.markPaidIfPending(orderId); // state machine guards the move
12    }
13  });
14  res.sendStatus(200); // answer fast; heavy work goes to a queue
15});

05Վճարման վիճակներ, «outcome unknown» և reconciliation

Վճարումների աղյուսակը պահեք պատվերներից առանձին․ մեկ պատվերը կարող է ունենալ մի քանի փորձ։ Յուրաքանչյուր փորձի տվեք բացահայտ վիճակներ, օրինակ՝ created, pending, requires action, authorised, captured, failed, cancelled, refunded և partially refunded։ Ավելացրեք ևս մեկը, որը սկսնակները մոռանում են՝ outcome unknown։ Այն ծածկում է timeout-ներն ու crash-երը, երբ հարցում եք ուղարկել, բայց պատասխան չեք ստացել․ գումարը կարող է շարժված լինել, կարող է և ոչ։ Երբեք մի գուշակեք։ Նշեք այն որպես unknown, կուրորեն մի կրկնեք նոր գանձումով և թողեք, որ reconciliation job-ը պրովայդերից հարցնի իրական կարգավիճակը։ Reconciliation-ն աշխատում է ժամանակացույցով՝ գտնում է pending կամ unknown վիճակում խրված վճարումները, հարցում է անում gateway-ին, ուղղում է տեղական վիճակը և համեմատում օրական settlement հաշվետվությունները ձեր ledger-ի հետ, որպեսզի յուրաքանչյուր ցենտ հաշվառված լինի։

• Timeout-ով ավարտված կանչը կրկնեք միայն նույն idempotency key-ով, կամ նախ հարցրեք կարգավիճակը։
• Alert ուղարկեք այն վճարումների համար, որոնք սպասվածից երկար խրված են ոչ վերջնական վիճակում։
• Պահեք պրովայդերի raw պատասխանները վեճերի և debugging-ի համար՝ առանց քարտի տվյալների։

06Վերադարձներ, պահված քարտեր, wallet-ներ և PCI scope

Վերադարձները ենթարկվում են նույն կարգապահությանը՝ ստեղծեք refund գրառում, կանչեք պրովայդերին idempotency key-ով և հաստատեք վերջնական կարգավիճակը webhook-ից կամ query-ից, քանի որ բանկային վերադարձները կարող են օրեր տևել։ Աջակցեք մասնակի և ըստ ապրանքի վերադարձներին և երբեք մի վերադարձրեք ավելին, քան capture է արվել։ Պահված քարտերն աշխատում են tokenisation-ի միջոցով․ պրովայդերը պահում է քարտը և ձեզ տալիս token կամ customer ID, որով հետագայում կարող եք գանձել, այնպես որ ցուցադրման համար պահում եք միայն բրենդը, վերջին չորս թվանշանները և ժամկետը։ Apple Pay-ն և Google Pay-ը wallet-ներ են, որոնք պրովայդերին փոխանցում են գաղտնագրված, կոնկրետ սարքին կապված token․ վեբում դրանք պահանջում են domain verification և merchant-ի կարգավորում, բայց տալիս են արագ, բիոմետրիկ checkout։ PCI DSS-ը քարտային ոլորտի անվտանգության ստանդարտն է։ Եթե քարտի տվյալները երբևէ դիպչում են միայն պրովայդերի էջերին կամ iframe-ներին, դուք որակավորվում եք ամենակարճ ինքնագնահատման համար (SAQ A), թեև PCI DSS 4.0.1-ով դեռ պետք է պաշտպանեք այն էջերը, որոնք բեռնում են վճարային script-ները։

07Ledger. դրամական շարժերի double-entry մտածողություն

Payments աղյուսակը ցույց է տալիս յուրաքանչյուր փորձի վիճակը, իսկ ledger-ը ցույց է տալիս, թե ուր գնաց յուրաքանչյուր ցենտ։ Double-entry հաշվապահությունում յուրաքանչյուր շարժ գրանցվում է երկու անգամ՝ որպես debit մի հաշվի վրա և credit մյուսի վրա, այնպես որ ընդհանուր գումարները միշտ հավասարակշռված են։ Խանութի համար հաշիվները պարզ են. հաճախորդի դեբիտորական պարտք, provider-ի բալանս, միջնորդավճարներ, refund-ներ և եկամուտ։ 50.00-ի capture արված վճարումը 1.50 միջնորդավճարով դառնում է գրառումներ, որոնք 50.00 տեղափոխում են հաճախորդից provider-ի բալանս, իսկ 1.50՝ provider-ի բալանսից միջնորդավճարներ։ Refund-ներն ու chargeback-ները նոր գրառումներ են, երբեք՝ խմբագրումներ։ Երբ գալիս է օրական settlement-ը, provider-ի բալանսը պետք է նվազի ճիշտ payout-ի գումարով։ Ցանկացած տարբերություն reconciliation-ի արդյունք է՝ ճշգրիտ ամսաթվով և reference-ով, այլ ոչ թե առեղծված հաշվապահի spreadsheet-ում։

1CREATE TABLE ledger_entries (
2  id          BIGSERIAL PRIMARY KEY,
3  journal_id  UUID NOT NULL,          -- groups the entries of one movement
4  account     TEXT NOT NULL,          -- customer, provider_balance, fees, refunds
5  amount      BIGINT NOT NULL,        -- positive = debit, negative = credit
6  currency    CHAR(3) NOT NULL,
7  payment_id  BIGINT,
8  created_at  TIMESTAMPTZ NOT NULL DEFAULT now()
9);
10 
11-- Every journal must balance to zero
12SELECT journal_id FROM ledger_entries
13GROUP BY journal_id, currency HAVING SUM(amount) <> 0;

08Webhook-ների առաքման իմաստաբանությունը գործնականում

Provider-ները webhook-ները առաքում են at least once, ոչ թե exactly once, և ոչ հերթականությամբ։ Օրինակ՝ Stripe-ը live ռեժիմում ձախողված առաքումները կրկնում է մինչև երեք օր՝ exponential backoff-ով, և նշում է, որ event-ների հերթականությունը երաշխավորված չէ։ Նախագծեք դա հաշվի առնելով։ Կարդացեք request-ի raw body-ն, որովհետև signature verification-ը ձախողվում է, եթե framework-ը parse և նորից serialize է անում այն։ Մերժեք այն event-ները, որոնց ստորագրված timestamp-ը չափազանց հին է (Stripe-ի գրադարանների default-ը հինգ րոպե է), որպեսզի արգելափակեք replay-ները։ Արագ վերադարձրեք 2xx և աշխատանքը տեղափոխեք queue, քանի որ դանդաղ handler-ները առաջացնում են timeout-ներ և ավելի շատ retry-ներ։ Worker-ում մի վստահեք event-ների հերթականությանը. կամ provider-ի API-ից վերցրեք օբյեկտի վերջին վիճակը, կամ անցումները կիրառեք state machine-ի միջոցով, որն անտեսում է հետընթաց քայլերը, օրինակ՝ «succeeded»-ից հետո ուշացած «processing» event-ը։

• Կրկնությունները հեռացրեք event ID-ով՝ unique constraint-ի միջոցով։
• Webhook route-ը ազատեք CSRF պաշտպանությունից, բայց երբեք՝ signature-ի ստուգումից։
• Alert ստացեք, երբ endpoint-ը վերադարձնում է non-2xx պատասխաններ, մինչև retry-ները կսպառվեն։

09Dispute-ներ և chargeback-ներ

Chargeback-ը տեղի է ունենում, երբ քարտապանը խնդրում է իր բանկին չեղարկել վճարումը. խարդախություն, ապրանքը չի ստացվել կամ «չի համապատասխանում նկարագրությանը»։ Provider-ը ձեր բալանսից գանձում է վիճարկվող գումարը գումարած dispute-ի միջնորդավճարը և բացում է dispute՝ ապացույցներ ներկայացնելու վերջնաժամկետով։ Հաղթող ապացույցները կոնկրետ են. առաքման հաստատում հասցեով, ստորագրված անդորրագրեր, log-եր, որոնք ցույց են տալիս հաճախորդի account-ը և սարքը, checkout-ում ընդունված refund-ի քաղաքականություն և նախորդ նամակագրություն։ 3-D Secure նույնականացումը սովորաբար խարդախության dispute-ների պատասխանատվությունը տեղափոխում է issuer-ի վրա, բայց ոչ «ապրանքը չի ստացվել» dispute-ների դեպքում։ Քարտային ցանցերը հետևում են merchant-ների dispute ratio-ին, և դրանց շեմերից վեր մնալը հանգեցնում է տուգանքների կամ քարտերի ընդունման իրավունքի կորստի։ Կանխարգելումն ավելի կարևոր է, քան հաղթելը. հստակ statement descriptor, իրական բողոքների դեպքում արագ refund-ներ և ռիսկային պատվերների fraud screening։

10Վճարման էջի պաշտպանություն PCI DSS 4.0.1-ի ներքո

Նույնիսկ երբ քարտի դաշտերը provider-ի iframe-ում են, հարձակվողները թիրախավորում են դրա շուրջ գտնվող էջը. կոմպրոմետացված script-ը կարող է iframe-ը փոխարինել կեղծ ձևով կամ ծածկել այն (հաճախ կոչվում է e-skimming կամ Magecart-ի ոճի հարձակում)։ PCI DSS 4.0.1-ի 6.4.3 պահանջը պահանջում է վճարման էջերի յուրաքանչյուր script-ի inventory՝ հիմնավորմամբ և integrity-ի մեթոդով, իսկ 11.6.1-ը պահանջում է մեխանիզմ, որը հայտնաբերում է այդ էջերի և դրանց security header-ների չթույլատրված փոփոխությունները։ SAQ A-ի 2025 թվականի հունվարի խմբագրությունում այս երկու կետերը փոխարինվեցին իրավունակության չափանիշով. merchant-ը պետք է հաստատի, որ իր կայքը խոցելի չէ script-ներից եկող հարձակումների նկատմամբ, և Council-ի ուղեցույցն ասում է, որ 6.4.3-ի և 11.6.1-ի տեխնիկաները դա ցույց տալու ճանապարհն են։ Գործնականում՝ checkout-ում քիչ script-ներ, խիստ Content Security Policy, Subresource Integrity ստատիկ ֆայլերի համար և փոփոխությունների մոնիտորինգ։

1# nginx: strict CSP on checkout pages (adjust to your provider's documented domains)
2location /checkout {
3  add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://js.stripe.com; frame-src https://js.stripe.com https://hooks.stripe.com; connect-src 'self' https://api.stripe.com; img-src 'self' data:; report-to csp" always;
4  add_header Reporting-Endpoints 'csp="https://example.com/csp-reports"' always;
5  try_files $uri /index.php?$query_string;
6}