Key topics
Related public pages
If you need the product, API or operations page rather than only the article, start with these VPOS.am sections.
Payout request should be tied to a period
A payout without period, recipient and currency becomes a manual note that cannot be reconciled later.
Smart QR payments can arrive every day, while payouts are usually closed by shift, week or month. Payout request should explicitly store periodStart, periodEnd, recipient, branch, currency, gross amount, fee amount and net amount.
If an operator creates payout without these fields, it becomes impossible to know which verified payments were included. This is especially painful for restaurants, hotels, salons, charity projects and teams with multiple recipients.
- lock periodStart and periodEnd;
- separate employee, team, company and donation scopes;
- calculate gross, fee and net separately;
- prevent second active payout for same scope and period.
Payout status should have limited transitions
Requested, processing, completed and cancelled should be a state machine, not free text.
A payout request needs a limited set of statuses and clear transitions. For example, completed should not become requested again without a separate correction, and cancelled should not silently hide verified payments from reports.
Every status transition should have actor, timestamp, method, reference and comment when the operation is manual. This prevents a payout from looking closed while accounting has no bank reference.
- do not allow arbitrary payout statuses;
- require method/reference when completed;
- log actor and request id;
- send idempotent webhook for status transition.
Which exceptions should operators see
Operators should see only cases that need decisions, not the entire stream of successful QR payments.
The platform should close simple matches automatically and show operators a short exception list. Examples: no verified payments for period, active payout already exists for this scope, amount changed after refund, payout reference missing or webhook delivery failed.
This scales better than spreadsheets. The team can see which periods are closed, which payouts are processing and which records need manual review before accounting close.
- no verified payments for payout period;
- duplicate active payout scope;
- refund changed net amount after request;
- completed payout without reference;
- webhook delivery failed after retries.
FAQ
Can payout be completed without bank reference?
Technically yes, but manual completed should require method and reference. Otherwise reconciliation with bank statement and accounting becomes weak.
What if refund appears after payout request?
Create an exception or recalculate payout before completed. Refund should not silently change a closed period without audit trail.
Are webhooks needed for payout statuses?
Yes, if an external system needs requested, processing, completed or cancelled. Repeated webhook delivery should not create duplicates.
