Overview
VPOS Fiscal connects a confirmed online payment with fiscal receipt issuing, retry queues and error audit.
Why receipt issuing should not depend on redirect
A fiscal receipt should be issued after reliable payment confirmation, not only after the user lands on a thank-you page. The redirect may never happen, may happen twice or may arrive before the final provider result.
VPOS Fiscal separates payment confirmation from fiscal processing. This creates a clear audit trail: when the payment was created, when it was confirmed, when the receipt entered the queue and how the issuing attempt ended.
How the receipt queue works
After payment confirmation, the system creates a fiscal job. If an external service, ERP or internal API is temporarily unavailable, the task is not lost. It remains in the queue with limited retries and a clear failure reason.
The operator sees a specific state instead of a vague failure: invalid data, timeout, provider unavailable, manual review required or receipt already issued.
- Retries do not create duplicate receipts
- Critical failures are stored for review
- Manual review is separated from automatic retry
Refunds and disputed states
Fiscal logic must cover successful sales, refunds, partial refunds, pre-capture cancellations and mismatches between CRM and the payment provider.
During the pilot, the team should define which statuses create a receipt, which create a refund document and which require manual review before any fiscal action.
FAQ
When should a fiscal receipt be issued?
A receipt should be issued after confirmed payment and validated order data. A browser redirect or user action alone is not enough for a fiscal operation.
What should happen if receipt issuing fails?
The task should remain in the fiscal queue with a failure reason and limited retries. Data errors and duplicate risks should move to manual review.