Overview
The VPOS.am status page shows key payment circuit components and helps separate provider incidents from integration errors.
Which components should be monitored
The payment circuit has several parts: payment creation, checkout, provider callback, webhook delivery, fiscal queue, reconciliation and operator interface.
If all of them are collapsed into one status, the business cannot understand where the issue is. Each component should be represented separately.
What counts as an incident
An incident is not only full downtime. Clients also care about partial failures: delayed webhooks, increased declines, fiscal queue unavailability or inability to check payment status.
Before a full public status infrastructure is live, such cases are tracked by the operations team and confirmed to clients on request.
What should not be promised too early
A precise SLA should not be promised if it is not backed by monitoring, response procedures and operating history. It is better to describe the current monitoring mode, contact channels and responsibility boundaries.
This is more useful for B2B clients because they understand what is controlled now and what will be added as the platform matures.
FAQ
Why should payment API and webhook delivery have separate statuses?
Payment creation can work while webhook delivery or fiscal queue has a delay. Separate components show the real impact area of an incident.
Can an MVP promise a public SLA?
Not unless the SLA is backed by monitoring, response procedures and operating history. It is more accurate to publish current monitoring mode and contact channels.