Payment Errors
Common Atlas API payment errors for expired orders, unsupported payment methods, duplicate payment risk, passenger data, and VCC failures.
Use this page when pay.do fails.
Start here when you need to:
decide whether payment is safe to retry
avoid duplicate payment after
pay.dofailurechoose between waiting, changing the condition, or restarting the flow
FAQ
Should we retry pay.do after a payment error?
Not always.
First query the order state.
If payment may already be in progress or already completed, do not send another payment request blindly.
What changes in the fulfillment flow?
getOfferPrice.do orders use a 5-minute ticketing window.
Query first, then retry only if the order is still payable and still inside the active window.
Highest-frequency codes
401 Time out of payment
Payment was attempted after the payment deadline.
Action
Regenerate the order or create a new booking
For
getOfferPrice.doorders, start from a fresh fulfillment attempt unless your supported recovery flow says otherwise
402 / 404 Order status does not support payment or order already paid
The order is already paid, ticketing, or ticketed.
Action
Query the order first
Do not send duplicate payment requests
403 Unsupported payment method
The chosen method is not allowed for this fare or airline.
Action
Switch to another supported method
Check supported payment fields before payment
406 Payment operation is in progress
A previous payment request is still processing.
Action
Wait and poll order status
Avoid duplicate retries during in-flight payment
407 Incorrect passenger information
The order data does not meet airline payment checks.
Action
Check passenger fields
Rebuild the order if required
409 Additional baggage does not match the segment
Ancillary product selection is inconsistent with the order.
Action
Re-check segment-specific
productCode
411 Generic payment error
Atlas could not complete payment due to account or settlement issues.
Action
Check balance
Check payment inputs
Retry only after validation
413 Card is not supported
Card type is not supported for this scenario.
Action
Use a supported card brand
414 Card mismatch
The payment card type does not match the card type used earlier in the flow.
Action
Use a consistent card type across order and payment
415 Order is not confirmed by user
Common in FR flow when orderCommit.do was not completed.
Action
Complete order confirmation first
Then retry payment
Which payment errors usually need a condition change first?
Codes such as 403, 411, 413, 414, and 415 usually need a payment-method, account, card, or flow correction before retry.
Codes such as 402, 404, and 406 usually need order-state confirmation before any retry.
Recommended troubleshooting order
Query the order before retrying payment
Check payment deadline and order status
Validate supported payment method
Validate passenger and ancillary data
Use deposit fallback when VCC is blocked
Fulfillment flow payment failures
Use tighter retry control for getOfferPrice.do orders.
Query the order before every retry
Stop retrying when the 5-minute window is nearly exhausted
Regenerate only after the original order reached a final unusable state
Do not route this flow into delayed manual approval.
Quick retry guide
Query order before retry
Examples:
402404406
Change the condition before retry
Examples:
403411413414415
Restart or regenerate the order
Examples:
401
Use deposit fallback when VCC fails
Examples:
403411
Related pages
Last updated
Was this helpful?