Test Cases

This page is currently only available in English.

Looking for a simpler integration path?
If you would rather validate an HTTP and JSON integration than own the raw OPI transport layer directly, consider the Nexi OPI Proxy.
Explore the OPI Proxy

An OPI integration should be tested as a flow, not just as a set of isolated XML messages. A technically valid request is not enough if receipt handling, device callbacks, recovery, or terminal parameter behaviour are still incomplete. This page gives a practical checklist for integrators.

Quick Links

Minimum Scope for a Standard Attended Integration

For a typical attended retail setup, the minimum recommended scope is:

successful sale
declined sale
aborted sale
refund
receipt printing
journal or e-journal storage
ticket reprint
close day
recovery after communication failure
terminal unavailable handling

If the target setup supports them, also test:

preauthorisation
capture
cancellation
DCC
tipping
login / logout
transmit / submit

The goal is not only to prove that a payment can be approved. The goal is to prove that the POS can handle the complete terminal conversation from start to finish.

Test What Is Configuration-Driven

Not every behaviour is controlled by the POS alone. Confirm the real terminal setup before you call a test "passed".

Check explicitly:

which payment methods are enabled
whether DCC is enabled
whether tipping is enabled
whether login or logoff is required
whether automatic submission is enabled
how many receipt copies are expected
whether printer, journal printer, e-journal, or a combination is mandatory
whether the terminal supports the request types you want to use
whether the terminal behaviour matches the merchant setup and terminal parameters

A good test result should always be read together with the actual terminal configuration. Otherwise, a test may pass in one setup but fail in another.

Functional Flow Checklist

Sale

Confirm that:

the terminal receives the amount correctly
the cardholder flow completes
all DeviceRequest callbacks are answered
the final response is parsed correctly
approval references are stored
receipt and journal output are handled correctly
the POS stores the transaction in a way that supports later lookup and follow-up actions

Declined sale

Confirm that:

the terminal returns the declined result correctly
the POS does not store the transaction as successful
no goods or services are released by the POS
the receipt or cardholder message is handled correctly
the cashier or operator sees a clear result

Aborted sale

Confirm that:

the flow can be cancelled from the terminal or POS where supported
the POS stores the correct final state
the cashier or operator sees a clear result
a new transaction can be started afterwards without manual cleanup

Refund

Confirm that:

refund permissions are enforced in the POS
the refund amount is sent correctly
the final response is stored correctly
refund receipts are handled correctly
the refund can be traced later in the POS

Preauthorisation lifecycle

If supported, confirm that:

reservation succeeds
the original reservation references are stored
capture works using the stored references
cancellation works using the stored references
the POS prevents invalid follow-up actions
the final state is clear to the merchant

Service flows

Confirm the required service flows for the target setup:

GetInfo
GetStatus
CloseDay
TransmitTrx if used
ContactTMS / ContactAcq if those flows are part of rollout or support
login / logout if required

Service flows are important because they are often needed for support, daily operations, or recovery.

Device Callback Checklist

This is one of the most important parts of an OPI certification-style test.

Confirm handling for:

cashier display output
printer output
journal printer output
e-journal output
cashier input
customer display output where applicable

Also confirm that:

the POS sends a valid DeviceResponse
the response matches the original request identifiers
multi-step device sequences are handled in order
the POS does not ignore unexpected but valid device requests
the POS handles repeated or delayed callbacks safely
the final payment result is not processed before required device handling is complete

Every DeviceRequest needs a matching DeviceResponse.

Negative and Operational Scenarios

Do not stop at successful transactions. Also test operational issues that can happen in real stores.

Recommended scenarios include:

printer unavailable
paper low
paper empty
journal unavailable
e-journal unavailable
terminal unavailable
DeviceUnavailable
Loggedout
PrintLastTicket
repeated request protection with unique RequestID
immediate follow-up request after final response
terminal restart during idle state
terminal restart during a transaction
POS restart during idle state
POS restart during a transaction
network interruption before final response
network interruption after authorisation but before the POS receives the result

The POS should fail clearly, recover safely, and avoid creating duplicate or contradictory transaction records.

Unknown-Result Recovery

This is where real-world integrations are often won or lost.

After a communication interruption, confirm how the POS decides whether the payment really happened.

Recommended recovery approach:

use RepeatLastMessage if implemented
use reprint if needed
use stored references, terminal evidence, or transaction lookup where the target setup provides it
compare original identifiers carefully before deciding on success or failure

The important rule is simple:

loss of communication does not automatically mean loss of payment
a missing POS response does not automatically mean the terminal did not complete the transaction
the POS must not blindly retry a payment without checking the previous result

A mature integration should have a clear state for interrupted transactions, such as unknown, pending recovery, recovered successful, or recovered failed.

Suggested Evidence to Keep During Testing

For each important test, keep:

the raw request XML
the raw response XML
the terminal result seen by the merchant or cardholder
the receipt or e-journal content
the POS-side stored transaction record
the terminal configuration used during the test
any unknown-result recovery evidence
logs from both the POS and the terminal side where available

This evidence is useful for certification, support, regression testing, and production issue analysis.

Unattended Terminals

Unattended testing is an add-on to the standard OPI test scope. Most teams only need it when the terminal is integrated directly over OPI and the target profile requires DeliveryBox.

For unattended setups, extend the baseline test pack with:

successful DeliveryBox handling
failed DeliveryBox handling
timeout handling and repeated requests if Busy is supported
proof that payment and delivery stay linked
partial-delivery checks only if the terminal profile explicitly supports them
evidence for what happens after interruptions, retries, or delivery failures

Also confirm:

whether the terminal profile is truly unattended
whether DeliveryBox is mandatory
what the timeout, reversal, and delivery-failure behaviour is
whether support teams can reconstruct both payment and delivery afterwards

The detailed unattended examples, XML responses, and recovery guidance live on Unattended Terminals.

A Good Sign That the Integration Is Mature

Your implementation is in a strong place when:

happy-path flows work consistently
DeviceRequest handling is stable
receipt and journal handling are correct
retries and recovery are defined
the POS stores the references needed for follow-up actions
terminal parameter behaviour is understood and not hard-coded by guesswork
operational failures are visible and recoverable
support teams can understand what happened from logs and stored records

For unattended terminals, maturity also means that payment and delivery cannot silently drift apart.

A good unattended integration is not only one where the payment works. It is one where the integration can prove what happened to both the payment and the delivery.