Service Status

Senmo develops infrastructure for financial applications, blockchain systems, and digital voucher solutions.

Our goal is to provide clear operational communication so developers can understand potential service disruptions and take appropriate action.

Platform availability

Service availability depends on the deployment environment and release status of each platform.

This table is informational and is not a real-time monitoring dashboard.

A status should only be marked operational, degraded, or unavailable when supported by verified monitoring information.

Report a service disruption

If you are experiencing connectivity issues, unexpected API failures, or a potential service outage, submit a request through our official support portal.

Open Senmo Support Desk

When reporting an incident, provide:

• Affected platform.
• Environment.
• Description of the issue.
• First observed timestamp in UTC.
• Affected API endpoints.
• HTTP status codes.
• Request identifiers.
• Business or operational impact.

Do not include API keys, passwords, access tokens, or other sensitive credentials.

Service status definitions

The following definitions describe how service health may be communicated.

Status classifications are applied to specific services or components when operational information is available.

Incident severity

Incidents may be classified according to their technical and operational impact.

Critical

A serious disruption involving widespread service unavailability, potential financial integrity concerns, or other major operational consequences.

Examples:

• Suspected duplicate financial postings.
• Widespread inability to process transactions.
• Significant unauthorized access concerns.

High

A major service function is unavailable or materially impaired.

Examples:

• Transaction creation consistently failing.
• Authentication failures affecting multiple integrations.
• A critical API operation becoming inaccessible.

Medium

A partial disruption affects a subset of operations or integrations.

Examples:

• Intermittent API failures.
• Elevated response times.
• A resource-listing endpoint returning errors.

Low

A minor operational issue with limited impact.

Examples:

• A non-critical endpoint returning inconsistent metadata.
• An isolated documentation-related integration issue.

These classifications are descriptive and do not establish contractual response or resolution times.

Incident lifecycle

When an operational incident is confirmed, its handling may involve the following stages.

1. Detection

A potential issue is identified through monitoring, application logs, or a customer report.

2. Investigation

The affected infrastructure, endpoints, and operational impact are assessed.

3. Mitigation

Where possible, corrective action is taken to reduce the impact.

4. Monitoring

The service is observed to determine whether the corrective action has restored expected behavior.

5. Resolution

The incident is considered resolved after the relevant recovery checks have been completed.

6. Follow-up

Significant incidents may require additional investigation, documentation updates, or preventive improvements.

The communication and follow-up process depends on the nature of the incident and applicable service arrangements.

Scheduled maintenance

Infrastructure maintenance may be necessary for:

• Security updates.
• Infrastructure improvements.
• Database maintenance.
• API deployments.
• Performance optimization.
• Reliability enhancements.

Where maintenance is expected to affect customer integrations, relevant information may include:

Maintenance notices and communication channels will depend on the applicable service arrangements.

No universal advance-notice period is established by this page.

API availability and errors

During an infrastructure issue, applications may encounter:

• Increased latency.
• HTTP 500 errors.
• HTTP 502 errors.
• HTTP 503 errors.
• HTTP 504 timeouts.
• Intermittent connectivity failures.

Not every server error indicates a platform-wide outage.

Investigate the request, environment, and affected operation before concluding that a service is unavailable.

Handling service interruptions

Developers should design integrations to handle temporary service interruptions safely.

Recommended practices include:

1. Implementing appropriate request timeouts.
2. Applying controlled retry policies.
3. Using exponential backoff where suitable.
4. Preserving idempotency keys for eligible financial operations.
5. Logging request identifiers and timestamps.
6. Monitoring API response codes and latency.
7. Separating production and testing configurations.
8. Avoiding unnecessary repeated requests during a disruption.

Important considerations for financial transactions

For InfraRails, an HTTP timeout or connection failure does not necessarily mean a transaction was unsuccessful.

Before retrying a financial operation:

1. Preserve the original idempotency key.
2. Check the existing transaction using the supported lookup mechanism.
3. Inspect its current processing status.
4. Determine whether the operation was already applied.
5. Follow the documented recovery procedure.

Do not create a duplicate financial operation simply because the original request did not return a response.

Monitoring and operational visibility

Applications integrating with Senmo infrastructure should maintain their own operational monitoring.

Useful metrics include:

• API availability.
• Request latency.
• Error rates.
• Authentication failures.
• Transaction success and failure rates.
• Pending transaction volumes.
• Unresolved operational incidents.

Monitoring should avoid exposing sensitive financial data or credentials.

Service notifications

Verified service notices, maintenance announcements, and incident communications may be provided through the communication channels established for the relevant service.

The Senmo Support Desk is the primary documented channel for reporting suspected service disruptions.

A dedicated public status dashboard and automated incident subscriptions have not been confirmed in this documentation.

Service-level agreements

Service availability commitments, support coverage, and response times are governed by applicable commercial or service agreements, where established.

This page does not create a service-level agreement or guarantee a particular uptime percentage.

Related resources

• Senmo Support Desk — Submit service-related requests.
• Contact Support — General technical assistance.
• Report an Issue — Report bugs and unexpected behavior.
• Security Reporting — Report suspected security vulnerabilities.
• Troubleshooting — Investigate common API issues.
• Platform Updates — Infrastructure and product announcements.

---

Service status information must be based on verified operational data. The absence of a published incident notice does not independently confirm that a service is operational.