Test Cases

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 settlement 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
reconciliation
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

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

Functional Flow Checklist

Sale

Confirm:

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

Refund

Confirm:

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

Preauthorisation lifecycle

If supported, confirm:

reservation succeeds
the original reservation references are stored
capture works using the stored references
cancellation works using the stored references

Service flows

Confirm:

GetInfo
GetStatus
Reconciliation
CloseDay
TransmitTrx if used

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

Also confirm:

the POS sends a valid DeviceResponse
the response matches the original request identifiers
multi-step device sequences are handled in order

Negative and Operational Scenarios

Do not stop at successful transactions. Also test:

printer unavailable
paper low
paper empty
journal unavailable
e-journal unavailable
DeviceUnavailable
Loggedout
PrintLastTicket
repeated request protection with unique RequestID
immediate follow-up request after final response

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
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

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
any unknown-result recovery evidence

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
parameter-driven behaviour is understood and not hard-coded by guesswork