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.
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
DeviceRequestcallbacks 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:
GetInfoGetStatusReconciliationCloseDayTransmitTrxif 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
DeviceUnavailableLoggedoutPrintLastTicket- 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
RepeatLastMessageif 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
DeviceRequesthandling 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