Timeout limits
Set your HTTP client timeout to at least 35 seconds so you observe Jupico’s own timeout rather than terminating early.
Why timeouts matter
When a request times out, one of the following can be true:- Jupico never received the request.
- Jupico received the request but the response was lost in transit.
- Jupico is still processing it.
Transaction timeouts
1
Do not retry immediately
A retry may result in a duplicate payment.
2
Attempt a rollback
Call the rollback operation for the original transaction. See the credit card and eCheck rollback endpoints in the API reference.
3
Interpret the rollback result
If the rollback succeeds, treat the original operation as reversed. If the rollback indicates no matching transaction, the original never occurred and can be safely retried.
4
Preserve context
Log the original request,
X-Request-ID (if received), and rollback response.5
Escalate if unresolved
Contact Jupico support if the final state cannot be determined.
Tokenization timeouts
Tokenization operations do not move money, so it is safe to retry with backoff.1
Wait
Apply an initial backoff before retrying.
2
Retry the tokenization request
Send the same request.
3
Increase the backoff on subsequent retries
Use exponential backoff (for example, 1s, 2s, 4s, 8s) with jitter.
4
Cap retries
Stop after a small number of attempts (for example, 3–5) and fail the workflow.
5
Log the failure
Record the request details and
X-Request-ID for troubleshooting.Client configuration
Set generous HTTP client timeouts so Jupico’s own 35-second window can be observed:Related pages
Transaction Status Handling
Understand
succeeded, declined, and failed outcomes.Error Handling
Broader error-handling patterns.
Error Codes
Look up the meaning of a specific
code value.Status Codes
HTTP status reference for retryable and non-retryable outcomes.