Open source payment orchestration for DORA incident reporting

Open source payment orchestration for DORA: what the regulation asks of your payment stack

If your institution is a payment or e-money institution, DORA requires you to classify and report major operational or security payment-related incidents, and the obligation sits with you, not with your orchestration vendor or your implementation partner. Article 23 of Regulation (EU) 2022/2554 applies the Chapter III incident rules to these incidents for credit institutions, payment institutions, account information service providers and electronic money institutions. Directive (EU) 2022/2556 also added Article 96(7) to PSD2, so the older PSD2 incident reporting under Article 96(1) to (5) no longer applies to providers covered by DORA. You therefore run a single regime for all operational or security payment-related incidents, whether or not they are ICT-related. Confirm with your national competent authority which entity types and reporting channels apply to your licence.

A self-hosted orchestration layer does not make these decisions, but it holds many of the facts you will need. In Hyperswitch, the Router service, the Scheduler and the PostgreSQL and Redis tiers produce the records that show when a payment failed, which connector or processor was affected, how retries and fallbacks were routed, and when a route was changed. Your team should confirm which of these logs are retained, where they are stored, how they are time-synchronized, and whether they can be exported in the form your classification process needs. Equally important, map which processors, vault providers and hosting components sit in each payment path, because the affected-customer and affected-transaction counts depend on that map.

DeployOpen plans, implements and documents self-hosted platforms, and can prepare the logging, configuration and evidence described above for your assessment. DeployOpen does not issue attestations, audit reports or certifications, and it does not decide whether an incident is major, what the root cause is or what gets reported to a regulator. Those decisions belong to your incident management function, your compliance lead and your board, under the criteria set in Delegated Regulation (EU) 2024/1772 and the reporting timelines in Delegated Regulation (EU) 2025/301. The DORA regulation on EUR-Lex is the natural starting point for your legal team when mapping these duties to your own entity.

Which DORA reporting requirements the orchestration layer must support

This table maps each DORA incident reporting provision to what the orchestration layer must capture and how to configure Hyperswitch to produce it. Read it as a checklist for the data your incident file needs, with the reporting clocks set out so that event logging and alerting can be sized against them.

Requirement	What the orchestration layer must capture	Hyperswitch configuration to confirm
Article 23 (scope of operational or security payment-related incidents)	Records of operational or security payment-related incidents, including minor ones, so that major incidents can be identified and classified later	Confirm that payment event logs, connector errors and routing decisions are retained centrally and are not limited to the dashboard view
Article 19(1) (reporting major incidents to the competent authority)	A recorded, timestamped trail showing when the entity became aware of an incident and which authority the report goes to	Route alerts from the Router and Scheduler services into your incident tooling; confirm the alert destination and on-call path in writing
Article 19(4) (initial, intermediate and final reports)	Status history of the incident, updates as handling changes, and final impact figures once root cause analysis is complete	Keep processor status, retry history and reconciliation exports so that estimates can be replaced by actual counts in the final report
Article 18(3)(a) and Delegated Regulation (EU) 2024/1772 (materiality thresholds)	Data needed to judge materiality, such as affected transactions, affected merchants, duration and value of disruption	Confirm which fields in payment records, webhooks and connector responses can be used to count affected transactions per processor and per market
Article 5 of Delegated Regulation (EU) 2025/301: initial notification	Evidence of the time classification as major was made, and the time awareness began, to show the 4-hour and 24-hour limits were met	Timestamp classification decisions in your incident record, not only in Hyperswitch, and confirm webhook delivery times are logged
Article 5 of Delegated Regulation (EU) 2025/301: intermediate and final reports	Intermediate report due within 72 hours of the initial notification; final report due no later than one month after the latest intermediate report	Set internal reminders from the notification timestamp; confirm how long event and webhook logs are retained so the final report can be prepared
Weekend and bank holiday rule (Article 5(4) and (5))	Calendar of national bank holidays for each reporting authority, used to move deadlines to noon on the next working day where the rule applies	Not configured in Hyperswitch; keep the holiday calendar in your incident process and confirm with counsel whether initial notifications and intermediate reports are exempt for your entity type

How the initial, intermediate and final report clocks run

The initial notification is the first formal report to the competent authority. Under Article 5 of Delegated Regulation (EU) 2025/301, it is due within 4 hours of classifying the incident as major and no later than 24 hours after the institution became aware of it. The clock therefore depends on two moments: when the incident was detected and when it was classified. The orchestrator is usually the first system to show a failed authorization spike, a processor outage or a suspicious routing change, so its alerts and timestamps often establish the awareness point.

First detection time: Alert records with UTC timestamps showing when monitoring first flagged the anomaly, such as a sudden rise in declines from one connector.
Affected flows: The processors, payment methods, merchant entities and markets touched by the failure, taken from routing and connector logs.
Classification record: A dated entry showing when the incident was classified as major against the thresholds in Delegated Regulation (EU) 2024/1772.
Initial impact indicators: Transaction counts and value estimates available at that point, clearly marked as estimates.
Contact and escalation log: Who was notified, when, and who holds authority to file.

Confirm with your compliance team how your organization defines the awareness point, and ask your partner whether alert timestamps are stored in a tamper-evident way.

Which self-hosted platforms fit DORA payment incident evidence

A DORA incident file draws on several systems at once: the orchestration layer that routes and retries payments, the ledger and billing records that show financial impact, and the logs that prove when things happened. No single product covers all three, so the choice is about which system is the system of record for each piece of evidence.

Hyperswitch as the orchestration layer

Hyperswitch, licensed under Apache-2.0 and at v1.128.0, is the component that sees every routing decision, retry and processor response. Its Rust core app server handles routing, retries, vaulting and observability, and its Router and Scheduler services write the transaction state that an initial notification relies on. Confirm with your team which Hyperswitch logs and database tables count as the system of record, how long they are retained, and whether they can be exported without stopping payments. Treat the Router log as the first evidence source to confirm.

Card vault and key management boundary

The card vault is a separate service in its own repository, and the encryption service handles key management. For an incident file, the question is whether a vault outage or key problem can be classified as a payment-related incident and how it is documented. Check the self-hosted deployment model you choose, because in the in-house PCI model the merchant carries full responsibility for PCI DSS and data handling. Ask who holds vault logs and who can read them during an investigation.

Control Center access and SSO limits

The Hyperswitch Control Center supports single sign-on through OpenID Connect only. SAML is not supported, there is no JIT or SCIM provisioning, users must be invited first, and roles are managed in Hyperswitch rather than mapped from the identity provider. For incident evidence, this means access reviews and leaver removal happen in two places. Document who can change routing rules during an incident, and confirm how Control Center actions are logged before relying on them.

Apache Fineract for the core banking ledger

Apache Fineract, licensed under Apache-2.0 and at version 1.15.0, is a core banking platform and fits where an institution keeps customer accounts and balances on an open-source ledger. Where it applies, it becomes the system of record for impact figures, which the final report needs once estimates are replaced with actuals. Confirm which balances and transaction types Fineract holds, and whether payment failures can be linked to ledger entries by a stable transaction reference.

Kill Bill for billing events

Kill Bill is an Apache-2.0 subscription billing and payments platform, currently at killbill-0.24.22. Where an institution bills customers for recurring services, its invoice and payment events can show how many customers were affected by a payment failure and for how long. This matters for the intermediate and final reports, which need impact figures. Check whether Kill Bill payment events can be correlated with orchestrator transaction IDs, and whether that correlation survives a processor change.

Separate log and SIEM platform

Orchestrator, ledger and billing logs are only useful for DORA reporting if they are copied to a store that the application team cannot edit. A log or SIEM platform, which DeployOpen would deploy and configure in your own environment, holds timestamps and sequence evidence across components. Confirm the time source used across systems, retention periods set by your legal and regulatory team, and whether the platform can reconstruct a timeline for the initial notification deadline measured from classification.

What the orchestration layer cannot do for DORA on its own

Does a payment orchestrator decide whether an incident is major under DORA?

No. The orchestrator can surface events such as failed authorizations, connector outages and latency spikes, but deciding whether an event is a major operational or security payment-related incident is a judgment the institution must make. Materiality thresholds are set in Delegated Regulation (EU) 2024/1772, and they weigh factors such as the number of clients affected, duration, geographic spread, data losses and economic impact. Your incident management process needs documented criteria, named owners and a record of how each decision was reached, applied consistently across processors and payment methods. Confirm with your compliance team which thresholds apply to your entity type before you configure any alerting.

Can the orchestration platform submit DORA incident reports to the regulator?

No. Reports go to the competent authority through the channels that authority specifies, and the platform has no role in that filing. The orchestrator can hold the data your team needs to complete the initial notification, intermediate report and final report, such as transaction logs, routing decisions and connector status history. Under Article 5 of Delegated Regulation (EU) 2025/301, the initial notification is due within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware of it. Build a runbook that routes these deadlines to people who can act on them, and confirm the submission format and channel with your authority before an incident occurs.

How do we get processor incident data in time for DORA deadlines?

Your own orchestrator can see the failures it routes, but a processor or acquirer may hold the root cause, and their timelines are not yours to control. Contracts should set out how quickly the provider must notify you of incidents affecting your payments, what information they must supply for root cause analysis, and who is their named contact during an event. Check whether the agreement covers subcontractors in the route and whether it grants audit or access rights. Confirm these terms with your legal and procurement teams, because the orchestrator cannot compel a third party to share data.

Does self-hosting Hyperswitch make us PCI DSS compliant?

No. Self-hosting changes where card data lives, but it does not transfer responsibility. In the self-hosted, in-house PCI model, the Hyperswitch documentation states that the merchant is fully responsible for PCI DSS certification and data handling. That means your organization must assess its own cardholder data environment, maintain the controls the standard requires, and obtain its own assessment from a qualified assessor where applicable. If you use an external PCI vault or the SaaS vault, the responsibility split changes, so review each model with your assessor. DeployOpen prepares systems and evidence for assessments but does not issue certifications or attestations.

Who is responsible for the card vault security evidence?

Your organization remains responsible for the evidence, even when an implementation partner builds and documents the vault. The vault is a separate service in the hyperswitch-card-vault repository, and its controls depend on how you deploy it, manage keys, restrict access and monitor it. Keep records of configuration, access reviews, key rotation and change approvals so that an assessor can trace them. Ask your partner which artifacts they produce and which ones your staff must maintain after handover. The split should be written into the statement of work before work starts.

Does the orchestrator fix gaps in our incident classification process?

No. An orchestrator produces telemetry, but classification depends on your people, process and governance. Gaps often sit in how events are triaged, escalated and recorded, and in whether staff across operations, security and compliance agree on who makes the call. Article 23 of DORA applies the incident management requirements of Chapter III to operational and security payment-related incidents, so the process must cover those events as well as ICT-related incidents. Test your process with tabletop exercises that include payment scenarios, and track how long each step takes so you can show your supervisor the process works.

How much does DORA incident reporting for payments cost to set up?

The cost depends on the work that falls outside the orchestrator: classification design, reporting runbooks, contract amendments with processors, PCI DSS assessment of your environment and staff training. Self-hosting adds infrastructure and operations costs, which recur, and the one-time work covers integration, testing and documentation. Costs rise with the number of processors, payment methods and markets, and with the depth of log retention you require. DeployOpen does not publish prices. Request a quote built from a written scope that lists each integration, document and test, and ask which items are one-time and which recur.

Do we need a DeployOpen engagement to meet DORA alone?

Not necessarily. Some institutions run their own orchestration, classification and reporting programs with internal staff, while others bring in a partner for specific parts of the work. Whether you can do it yourself depends on your in-house skills in Kubernetes, PostgreSQL, security operations and payment compliance, and on the time your regulator expects for remediation. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and it prepares evidence for compliance assessments. Ask any partner which parts of DORA they cover and which remain your responsibility.

Evidence DORA reviewers ask for and which component produces it

This table maps each piece of evidence a DORA reviewer or competent authority is likely to request for a payment incident to the component that usually produces it in a self-hosted Hyperswitch setup. Read the component column as a starting point, then confirm with your own environment which items are generated automatically, which need configuration, and which sit in your ticketing, SIEM or processor records.

Evidence item	Producing component	What to confirm in your environment
Incident logs with timestamps	Router logs and observability stack	Log retention period, time synchronization across services, and whether payment failures are captured with a unique payment identifier
Scheduler job history	Scheduler (Producer and Consumer) job records	Whether retries, revenue recovery jobs and failed scheduled tasks are retained long enough to reconstruct an incident timeline
Classification record and criteria applied	Ticketing system with incident template	Who signs the major classification, which materiality thresholds from Delegated Regulation (EU) 2025/301 your records reference, and the timestamp of classification
Configuration and processor change records	PostgreSQL audit tables and version control of routing rules	Whether routing, connector and fallback changes are captured with approver, timestamp and previous value
Access logs for administrators and dashboards	SIEM fed by Control Center and host logs	Whether Control Center user activity is forwarded, since SSO roles are managed inside Hyperswitch rather than mapped from your identity provider
Report copies and submission receipts	Ticketing system and regulator portal records	Where initial, intermediate and final report copies are stored and how submission receipts are linked to the incident record
Root cause analysis	Ticketing system with linked logs and post-incident review	Whether the analysis is complete before the final report is due and that actual impact figures replace earlier estimates
Backup and restore test results	PostgreSQL backup tooling and restore test runbooks	Restore test frequency, scope covering the card vault and encryption service keys, and documented recovery time results

Gaps that tooling alone does not close

A self-hosted orchestration layer produces logs and alerts, but DORA holds the financial entity accountable for the governance around them. The cards below cover the gaps that sit outside the software and that examiners typically ask about first.

Incident classification governance

Detection tooling flags a failed routing change or a processor outage, but someone must decide whether it is an operational or security payment-related incident and whether it is major. Document who makes that call, which criteria from the materiality thresholds in Delegated Regulation (EU) 2024/1772 are applied, and how the decision is recorded. Test the process with a tabletop exercise that uses a real connector failure from your own logs, not a generic scenario. Confirm that the classification owner has authority to act outside business hours.

Third-party ICT risk for every processor

Each processor, vault provider, fraud tool and acquirer in the route is an ICT third-party service provider whose failure can become your incident. Maintain a register that maps every connector to the contract, the data it touches and the function it supports, and record the exit or failover plan for each. Ask processors for their incident notification commitments in writing so that your reporting clock does not depend on their silence. Confirm which processors are used for each market before you rely on a single failover target.

Chapter II ICT risk management documentation

Chapter II requires a documented ICT risk management framework that covers the orchestration platform, its hosting, access and change processes. Auditors and competent authorities will ask to see the framework, not just the running configuration. Map the Hyperswitch components, including the Router, Scheduler, PostgreSQL, Redis and the card vault, into the asset inventory and the risk assessment. Confirm which risk owner signs off on the framework and how often it is reviewed.

Testing obligations under Chapter IV

Chapter IV requires a digital operational resilience testing programme, and threat-led penetration testing applies to some entities. Plan tests of connector failover, routing rule changes and vault access controls, and record the scope and results. Your own security testing team or an external tester can run these, but the programme and remediation tracking remain your responsibility. Confirm with your competent authority whether threat-led testing applies to your entity and how it selects the testers.

Incident response runbooks for payment flows

The reporting clock starts at awareness, so runbooks must tell on-call staff how to escalate a payment incident within hours. Write separate runbooks for processor outages, failed routing fallbacks, suspected vault compromise and reconciliation breaks, each with named roles and evidence to capture. Include the steps to pull transaction identifiers and timestamps needed for the initial notification, intermediate report and final root cause analysis. Rehearse each runbook at least once and keep the rehearsal record.

Confirming the report channel

Reports go to the relevant competent authority, and the channel and format depend on your entity type and member state. Significant credit institutions follow a different route through the national authority to the ECB, and member states may also require copies to NIS2 authorities or CSIRTs. Confirm with your competent authority which portal, templates and contacts apply before an incident occurs. Record the answer in the runbook, because the reporting window is too short to find it during an event.

How the incident capability is built and tested

The sequence moves from defining which entities and payment flows fall under DORA to a set of tested reporting runbooks and an evidence pack the compliance team can hand to its competent authority or auditor. Each phase closes with a check the institution can verify.

Confirm the in-scope entities and payment flows
Compliance counsel and the payments lead confirm which legal entities in the group are payment institutions, electronic money institutions or other entities covered by Article 23, and which payment flows, processors and markets run through the Hyperswitch deployment. DeployOpen maps each flow to the systems it touches, including the Router, Scheduler, PostgreSQL, Redis, the card vault and the Control Center. The step closes when the scope register is signed off and every in-scope flow has a named owner.
Instrument the orchestrator and logs
The platform team configures logging and monitoring for the Hyperswitch components in scope so that payment failures, connector timeouts, routing changes, retries and administrative actions produce events that can be correlated across services. Access logs for the Control Center and the vault are included, along with retention settings that the institution sets against its own records policy. The step closes when a test transaction and a deliberately failed connector call both appear in the central log store with the expected fields.
Define classification criteria and thresholds
Risk, compliance and operations agree how an operational or security payment-related incident is recognized, using the materiality thresholds set in Delegated Regulation (EU) 2024/1772. The team writes criteria that map orchestrator signals, such as the number of affected transactions, payment service users and connector outages, to a classification decision. The step closes with an approved classification matrix and a record of who holds the authority to classify an incident as major.
Write the reporting runbooks for each report
The incident response team drafts one runbook for the initial notification, one for the intermediate report and one for the final report, each tied to the timings in Article 5 of Delegated Regulation (EU) 2025/301. Every runbook names the data fields to extract from logs, the people who sign off, the channel to the competent authority, and how weekend or bank holiday deadlines are handled under the same regulation. The step closes when each runbook has been reviewed by compliance and legal and stored in the incident register.
Run tabletop exercises for each report clock
DeployOpen facilitates tabletop exercises using a realistic but illustrative scenario, such as a processor outage that causes failed authorizations across two markets. Participants work through the initial notification, intermediate update and final root cause report, and the facilitator times each step against the runbook. Gaps in data extraction, approval paths and communication are logged as corrective actions with owners. The step closes when the exercise record lists every action item and each one has a due date set by the institution.
Hand over the evidence pack
DeployOpen assembles the documentation, configuration baselines, log samples, runbooks, exercise records and corrective action log into an evidence pack organized by DORA article. The institution's compliance function reviews the pack and confirms which items it will present to the competent authority or to its independent auditor. The handover is complete when the owner signs for the pack and the institution has tested retrieval of the evidence from its own storage.

Questions payment institutions ask before hiring help with DORA incident reporting

What drives the cost of DORA incident reporting work on a self-hosted orchestration layer?

The main cost drivers are the number of processors and payment methods in the route, the number of log sources feeding detection, the vault model, and whether you already run a SIEM that can take those logs. Each processor connector adds mapping, testing and monitoring work, and each log source adds parsing and retention decisions. Costs fall into two groups: one-time work (scoping, connector setup, detection rules, incident runbooks, report templates) and recurring work (monitoring, rule tuning, upgrades, and periodic exercises). Ask any partner for a written scope that lists each processor, log source and vault model, and for the one-time and recurring items priced separately.

Can a payment institution handle DORA incident reporting in-house?

Many institutions can, provided they already have security monitoring staff, an incident response process and people who understand the payment flow. The reporting obligations come from Article 19 of DORA and the timing rules in Delegated Regulation (EU) 2025/301, which set the initial notification, intermediate report and final report deadlines. The hard part is usually not the form but having detection that surfaces payment incidents early enough to classify them. Assess your team against the classification criteria in Delegated Regulation (EU) 2024/1772 and run a tabletop exercise before deciding what to outsource.

What do our compliance and security teams need to contribute?

Your compliance team owns the regulatory interpretation: which entity type you are under Article 2, which competent authority supervises you, and how your incident policy maps to the classification criteria. Your security team owns the technical inputs: log sources, alert rules, access controls on the orchestration platform and the card vault, and the contacts for each processor. Payment operations owns the transaction-level impact figures that feed the intermediate and final reports. Expect each group to spend time in scoping, in the first live test of the reporting workflow, and in reviewing reports before submission.

How long does DORA incident reporting setup take?

Duration depends on scope, not on a fixed template. The reporting clocks themselves are fixed: under Article 5 of Delegated Regulation (EU) 2025/301, the initial notification is due within 4 hours of classifying an incident as major and no later than 24 hours after becoming aware of it, the intermediate report within 72 hours of the initial notification, and the final report no later than one month after the latest intermediate report. Setup time depends on the number of processors, whether a SIEM exists, and how mature your classification criteria are. Ask for a written timeline tied to the agreed scope, with milestones for detection, classification and a reporting drill.

Does the vault model change the reporting work?

Yes. Hyperswitch documents three vault models: self-hosted with the native in-house vault, self-hosted orchestration with an external PCI vault provider, and self-hosted orchestration with the SaaS Hyperswitch Vault. With the in-house model, the merchant carries full responsibility for PCI DSS and data handling, so more logs and controls fall into the incident scope. With an external vault, the vault provider becomes a third-party ICT service that must appear in your register and in incident contact paths. Confirm the chosen model with your partner before scoping log sources.

Does DeployOpen issue a DORA attestation or certification?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Competent authorities supervise DORA compliance, and DORA provides no certification scheme. The only authority-issued attestation the Regulation provides for concerns a threat-led penetration test under Article 26(7). Ask any partner to show which evidence they produce, such as runbooks, test records and report logs, and confirm with your competent authority and internal audit what they will accept.

What does an implementation partner typically deliver for incident reporting?

A fixed-scope engagement usually covers defined deliverables agreed in writing before work starts. For this topic, these can include a scoped log and alert map for the orchestration layer, detection rules for payment-related anomalies, a classification workflow aligned with your policy, reporting templates for the three report stages, and a reporting drill. Ongoing rule tuning, upgrades and continuous testing are available as retainers. Confirm in writing who signs off on regulatory interpretation, since that stays with your institution and its advisers.

What should we check before choosing a partner for this work?

Ask for a written scope that names the processors, log sources, vault model and SIEM integration, plus the deliverables and acceptance criteria. Check how the partner tests the reporting workflow against the Article 19 and Article 5 timings, and how they handle evidence retention. Confirm that the partner separates its role from your compliance function, and that it does not present itself as an authority. Ask how changes to Hyperswitch connectors or the platform are tested so that detection stays accurate after upgrades, and request a quote that breaks out one-time and recurring costs.

Primary sources for DORA incident reporting

Start with the legal text, not the vendor documentation. Article 23 of DORA applies the Chapter III incident rules to operational or security payment-related incidents, and to major ones, for credit institutions, payment institutions, account information service providers and electronic money institutions. Read it alongside Article 19 of Regulation (EU) 2022/2554 on EUR-Lex, which sets the reporting duty and the initial, intermediate and final report sequence. Your compliance lead should map each report to a named owner and a clock start point before any tooling decision is made.

The timing and content rules sit in *Commission Delegated Regulation (EU) 2025/301*, which sets the 4-hour and 24-hour initial notification window, the 72-hour intermediate report and the one-month final report, and in *Commission Implementing Regulation (EU) 2025/302*, which governs the reporting templates. Confirm the current text on EUR-Lex before you encode any deadline in a ticketing or alerting rule, and check the weekend and bank holiday carve-outs in Article 5 of the Delegated Regulation, since they change which exceptions apply to your entity type. Directive (EU) 2022/2556 matters here for a different reason: it removed PSD2 incident reporting for DORA-covered providers, so a single regime applies to payment incidents whether or not they are ICT-related. Ask your national competent authority which reporting channel and format it expects.

On the platform side, the Hyperswitch documentation answers the operational questions the regulation leaves open. The self-hosting guide describes the Helm-based Kubernetes deployment, so you can confirm where logs, the card vault and the database run and who can reach them during an incident. The Control Center SSO guide is equally important: it states that single sign-on uses OpenID Connect only, that SAML is not supported, that there is no JIT or SCIM provisioning and that roles are managed inside Hyperswitch. Those limits affect how quickly you can revoke access for an incident responder and how you evidence who changed routing rules. Verify each point against the version you deploy, because the docs can change between releases.

How DeployOpen scopes, delivers and supports DORA payment incident capability

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For DORA payment incident capability, that means defining what the orchestration layer must log, classify and hand to the incident team, then building and documenting it in your environment.

How we scope

Written scope lists which Hyperswitch components, connectors and log sources feed incident detection and records.
Scope names the classification inputs, the reporting owner and the reporting timeline your team must meet.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We deploy self-hosted Hyperswitch in your cloud account, data center or air-gapped network, with logging wired to your SIEM.
We configure alerting on connector failures, routing anomalies and vault errors, then test each alert against agreed scenarios.
We document the incident data trail so a major-incident assessment can be traced back to source events.

How we hand over

Handover includes runbooks for triage, classification workflow, and the initial, intermediate and final report templates.
Your team receives configuration records, access model documentation and test results for each incident scenario tested.
We run a walkthrough with incident, operations and compliance staff so ownership of each reporting step is explicit.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
Upgrades of Hyperswitch releases are planned, tested in a non-production environment and documented before rollout.
Ask any partner to confirm how they handle your reporting clock during an upgrade window and who is on call.

Open source payment orchestration for DORA