Test and get approved
Test every message and situation on your test terminal, document the results, and send the self-assessment so Aera can approve your integration.
Integrate your ECR · task 7 of 8
Aera must approve your integration before it can be used in production. Test everything you built, then send the self-assessment.
Test your integration
Test on your test terminal, with test cards. See Get your test kit.
Test every message you built, starting with the Minimum message set, including what happens when things go wrong:
| Message or situation | Test that… |
|---|---|
| Login / Logout | The ECR logs in at start-up. After a LoggedOut error, it logs in again and then retries the original request (restart the terminal to try it) |
| Payment | Approved, declined, aborted and partly approved payments are all handled |
| Abort | The cashier can cancel before the customer taps the card or enters the PIN and presses OK. A late abort fails and the payment carries on. The ECR handles both |
| TransactionStatus | Break the connection during a payment: pull the network cable, or switch off the ECR or the terminal. After reconnecting, the ECR finds the result with TransactionStatus before trying again, so the customer isn't charged twice |
| Diagnosis | The ECR can check the connection to the terminal, and from the terminal to the payment host |
| Event | The ECR handles event notifications it didn't ask for, and the reject the terminal sends when it can't read a message |
| CardAcquisition, if built | After an aborted CardAcquisition, the ECR doesn't send a Payment request automatically |
| Terminal busy | Send a request while the terminal is busy. The ECR gets Busy and tries again later |
| Terminal not connected | The ECR gets UnavailableDevice and retries after a delay |
| Timeouts | The ECR waits longer than the terminal for payments, and uses short timeouts for quick requests such as Login and TransactionStatus. See Timeouts |
| Keep-alive (local integration) | If keep-alive messages stop, the ECR closes the connection and opens it again. See Connect your ECR |
| Display | The ECR accepts display messages at any time, and doesn't depend on their order, number or text |
| Unknown fields | The ECR ignores JSON fields it doesn't know |
Also test every optional feature you built (for example Display, refund, PIN and Reversal), on the terminal model your merchants will use. See Add optional features. Document your test results. Aera may ask to see them.
Send the self-assessment
Fill in the Functional and Interoperability Self-Assessment: as a web form (planned), or ask your Aera contact for it. It asks for:
- company, contact name, position, email, phone and date
- the terminal model and AIC version you tested with, and your ECR's operating system (Windows, Linux or Android)
- how the ECR connects: network (LAN) or serial (COM)
- confirmation that you have read the Aera Terminal Integration Guide (Nexo), the AIC on-premise installation guide and the test terminal guide (on-premise AIC)
- which messages from the Minimum message set and which optional features you built and tested
- confirmation that you tested with the target terminal model and found no interoperability issues
- which tests you ran: functional, integration and interoperability, plus stress and load, and security, if relevant
- confirmation that your test results are documented
- a signature: name, position and date
Wrong or incomplete answers can delay go-live. Tell Aera promptly if problems come up after you send the form, or if more testing is needed.
Aera marks the form approved, rejected or pending.
Updated 10 days ago