A payment request that works once may still charge the customer twice.
State-changing API operations must be tested beyond the first successful request. Creates, updates, transfers, and deletes can behave incorrectly when clients retry after a timeout, replay a completed request, or send identical operations concurrently.
API testing should verify repeated requests after success, retries after lost responses, concurrent requests using the same idempotency key, different updates against the same resource, and updates based on stale data. The expected behavior may be deduplication, conflict detection, serialization, or returning the original result, depending on the API contract.
For payment APIs, reusing the same idempotency key and request must not create a second transaction. The same protection should work when identical requests reach different service instances at the same time. Similarly, concurrent updates must not silently overwrite valid changes made by another client.
Do not verify only the HTTP response. Inspect the final resource state, transactions, emitted events, audit records, external side effects, and asynchronous jobs. Two successful responses must not create duplicate payments, repeated orders, lost updates, or partially completed operations.
Testing idempotency, retry safety, replay protection, and concurrency is essential for reliable APIs and distributed systems. Rentgen is an API discovery tool built to test what an endpoint actually does beyond one successful request.
Read the complete API testing white paper: https://qaontime.com/research/the-power-of-ten-rules-for-testing-http-apis.html
Automation Before Automation.
Top comments (0)