Հարթակ

VPOS Fiscal

Fiscalization-ը պետք է լինի առանձին վերահսկվող գործընթաց. վճարումը կարող է հաջող լինել, իսկ կտրոնի թողարկումը դեռ պահանջի retry, review կամ պատվերի տվյալների ուղղում:

Նկարագրություն

VPOS Fiscal-ը կապում է հաստատված օնլայն վճարումը fiscal receipt-ի թողարկման, retry queue-ի եւ error audit-ի հետ:

Ինչու կտրոնը չպետք է կախված լինի redirect-ից

Fiscal receipt-ը պետք է թողարկվի վստահելի payment confirmation-ից հետո, ոչ թե միայն այն պատճառով, որ user-ը հասել է thank-you page: Redirect-ը կարող է չլինել, լինել կրկնակի կամ գալ provider-ի վերջնական արդյունքից շուտ:

VPOS Fiscal-ը առանձնացնում է payment confirmation-ը fiscal processing-ից: Այդպես առաջանում է պարզ audit trail՝ երբ է payment-ը ստեղծվել, երբ հաստատվել, երբ receipt-ը մտել queue եւ ինչով է ավարտվել թողարկման փորձը:

Ինչպես է աշխատում receipt queue-ը

Payment confirmation-ից հետո ստեղծվում է fiscal job: Եթե արտաքին service-ը, ERP-ն կամ internal API-ն ժամանակավորապես հասանելի չեն, task-ը չի կորչում, այլ մնում է queue-ում retry limit-ով եւ հստակ failure reason-ով:

Օպերատորը տեսնում է ոչ թե ընդհանուր failure, այլ կոնկրետ state՝ invalid data, timeout, provider unavailable, manual review required կամ receipt already issued:

  • Retries-ը duplicate receipts չեն ստեղծում
  • Critical failures-ը պահպանվում են review-ի համար
  • Manual review-ն առանձնացված է automatic retry-ից

Refunds եւ վիճելի statuses

Fiscal logic-ը պետք է ներառի ոչ միայն հաջող sale-ը, այլ նաեւ refund, partial refund, cancellation before capture եւ CRM-ի ու payment provider-ի mismatch-երը:

Pilot-ի ընթացքում պետք է նախապես որոշել, որ statuses-ն են ստեղծում receipt, որոնք refund document, եւ որոնք պահանջում են manual review մինչեւ fiscal action:

Հաճախակի հարցեր

Ե՞րբ պետք է թողարկվի fiscal receipt-ը:

Receipt-ը պետք է թողարկվի confirmed payment-ից եւ order data validation-ից հետո: Browser redirect-ը կամ user action-ը միայնակ բավարար հիմք չեն fiscal operation-ի համար:

Ի՞նչ անել, եթե receipt-ը միանգամից չի թողարկվել:

Task-ը պետք է մնա fiscal queue-ում failure reason-ով եւ սահմանափակ retries-ով: Data errors-ը եւ duplicate risks-ը ճիշտ է տեղափոխել manual review: