A Lithuanian fintech buyer should evaluate an integration by how reliably the business can understand and recover its state after disruption. A successful API request is only one part of delivery. Require clear transaction states, reconciliation, dependency ownership and a recovery exercise before accepting a new connector.
This is especially useful when a growing product connects several payment, identity, accounting or reporting providers. Each connection adds another place where a local view can disagree with a remote system. TuniCyberLabs works with buyers remotely; the following fictional payment workflow explains what to request from an engineering partner without claiming a Lithuanian office or a completed regulated engagement.
The regulatory context makes evidence relevant
The Bank of Lithuania's DORA guidance explains that the regulation has applied since 17 January 2025 and addresses ICT risk, incident reporting, resilience testing and third-party risk. Its information-register guidance also connects contractual ICT arrangements to the records supervised financial entities maintain.
Those topics are a reason to connect delivery documentation with operational knowledge. They do not make every Lithuanian software company subject to identical requirements, and an integration project does not by itself establish DORA compliance. Your responsible compliance and legal reviewers determine scope. Engineering should provide accurate dependency, testing and recovery evidence for their review.
Draw the business state before the endpoint diagram
Imagine a payment operations application sending instructions through an external provider. The application records an instruction, submits it, receives a reference and later receives a status update. A customer-facing screen and the finance team both depend on the resulting state.
Define the meaning of each state with operations staff. Separate an instruction created locally, a submission awaiting confirmation, a provider-confirmed outcome and a case requiring investigation. A timeout describes an unsuccessful observation; it does not establish whether the remote business action occurred.
For each transition, record its evidence and owner. Decide which provider event or authorised query establishes the state, which internal action is allowed next and what the customer sees meanwhile. Avoid labels such as “failed” when the system only knows that it has not received confirmation.
Treat reconciliation as a product feature
Ask the engineering partner to demonstrate how missing or conflicting events are detected. A reconciliation process should compare the records relevant to the workflow and produce an exception that a person can investigate. Define the comparison keys, time boundaries and legitimate differences before writing the job.
For the illustrative payment flow, a useful exception record contains:
- ▸The internal instruction identifier and external reference, where available.
- ▸The last confirmed business state and the evidence supporting it.
- ▸The unresolved difference between local and provider records.
- ▸The most recent check and the next permitted investigation action.
- ▸The operations owner and a history of decisions already made.
The exception queue must not become a hidden dumping ground. Agree how staff find ageing cases and how repeated defects feed back into engineering work. Choose the review schedule around the business process and provider capabilities; a generic frequency is not a substitute for this decision.
Test ambiguity, duplication and delayed events
Acceptance should include a response lost after submission, a duplicated event, an event arriving later than expected and a temporarily unavailable status query. Review what happens after the application restarts while work is in progress. These scenarios reveal whether the connector preserves enough evidence to continue safely.
Use the provider's documented retry and idempotency behaviour. Do not assume that every API supports safe repetition, or that an internal request identifier prevents duplicates remotely. Where the outcome is uncertain, the implementation may need to investigate before attempting another business action.
In a demonstration, have operations staff explain the state they see and their next step. If they must ask a developer to search raw logs for every exception, the operational workflow is unfinished. Logs support the investigation; they do not replace a usable case view.
Connect the dependency register to the running system
Request a practical service map that names the provider, integration purpose, systems involved, data categories and internal owner. Include how incidents reach your team, who can contact the provider, and what happens when a credential or certificate needs replacement.
Keep this engineering map aligned with the organisation's vendor and contract records. The map is not a replacement for a regulatory register. Its purpose is to let the people responding to an incident connect the affected business process to the relevant dependency quickly.
Record shared dependencies as well. Two connectors may rely on the same queue, cloud account or identity service. An alternative route that depends on the failed component is not an independent recovery option. Verify this through architecture review and an exercise rather than assuming that different provider names mean independent paths.
Buy a recovery rehearsal with explicit observations
Choose a representative disruption and agree the scope of a controlled test. Observe whether the team detects the problem, pauses unsafe actions, identifies unresolved transactions and returns to an agreed operating state. Record what was tested, what was excluded and what remains open.
Restoring a database backup is not the same as reconciling business activity with an external system. If the provider processed instructions after the backup point, the recovered application needs a method for resolving that difference. Make this question part of the design discussion before selecting recovery targets.
The handover should include runbooks, access arrangements, known limitations and an exercise led by the receiving team. Agree how future provider changes will be reviewed and who maintains the reconciliation logic after the original project closes.
Compare proposals by the evidence they deliver
A useful proposal separates connector implementation, operational interface, reconciliation, failure testing and handover. Ask which provider documentation and test facilities are available, and which decisions depend on your staff. Price uncertainty visibly when a dependency cannot yet be tested.
For broader platform boundaries, see tenant isolation for Lithuanian SaaS buyers. The software vendor scorecard helps compare the delivery evidence across suppliers.
Review our software engineering services and request an integration resilience scope review. Bring a transaction workflow, its providers and one unresolved failure scenario so the first conversation can define a concrete investigation.