Worked replacement example
Terminal T1 belongs to merchant M1. M1 reports it lost at 09:00. T1 is revoked and replacement T2 is approved at 09:20. An online payment signed by T1 at 09:30 must be rejected. An offline payment that T1 says it accepted at 08:55 arrives at 10:00 and needs review under the offline acceptance rule. T2 must use its own credential and begin with a new sequence. These times are synthetic. The test checks the device state and event boundary, not a real POS provider.
Treat replacement as a credential change
Enroll a new terminal with a fresh challenge and a merchant approval. Test whether an old terminal can send offline transactions after revocation and how those records reach review. Do not reuse the old device secret.
Checks to run
- Bind merchant, terminal identity, keys, and operator during enrollment.
- Test device swap, lost-device revocation, factory reset, and merchant reassignment.
- Keep a change record for who approved replacement and when the old credential stopped working.
Device state map
Use pending, active, suspended, lost, and retired states. A terminal in pending can prove its identity but cannot take payments. A lost terminal cannot regain service by replaying an enrollment request. A retired terminal cannot be silently attached to another merchant.
Where offline payments are supported, define how a revoked device’s stored transactions are reviewed. Do not assume network revocation instantly erases data held on a terminal.
One more boundary test
Test merchant reassignment as a separate event from replacement. A returned terminal should be wiped, retired from M1, and enrolled with new credentials for M2. Transactions signed under the M1 credential after retirement must not settle to M2. Check that support staff cannot change merchant binding with only a serial number and a ticket note. Require a verified merchant approval and retain the old binding history. This protects dispute review when the same physical terminal has had more than one owner.
Retire a lost terminal
Enroll terminal T-01 for merchant M-01 and capture a transaction. Mark T-01 lost, then try to send a new sale, refund, settlement request, and key rotation from it. Each new operation must fail after the revoke event, while its earlier sale remains traceable. Enroll replacement T-02 only after verifying the merchant and binding the new device ID and key. Try copying T-01 credentials to T-02; the server must reject the mismatch under an enforced key-to-device binding rule. Keep the enrollment request, approved merchant, key version, revocation time, and last accepted transaction. The test separates device identity from merchant identity.
Prove key binding instead of trusting an ID
A copied secret with a changed serial number can still pass a shared-secret check if the server trusts the claimed serial. For device-bound enrollment, issue a fresh challenge and verify proof from the enrolled private key. Keep the public-key fingerprint and merchant binding in trusted server storage. Test a request that claims T-02 but is signed with T-01’s credential; the key lookup and device state must reject it. If the system uses exportable shared credentials, state that copying them can clone identity and test the actual compensating rule. Offline timestamps are device claims; compare sequence and last confirmed server state before accepting delayed records.
Primary sources
Next step
Revoke a lost demo terminal and test both online requests and delayed offline uploads from that device. Read the related guide. For a review of your own system, request a security review.