> For the complete documentation index, see [llms.txt](https://resources.atriptech.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://resources.atriptech.com/api-document/product-guides/booking/booking-step-guides/payment-and-ticketing.md).

# Payment & Ticketing

{% hint style="info" %}
💬 **Need help?** If you're stuck, ask Eva in the Help Center for instant diagnostics.

<a href="https://www.atriptech.com/" class="button primary" data-icon="comments">Ask Eva</a>
{% endhint %}

Use this page to complete payment and wait for ticket issuance.

Start here when you need to:

* pay an existing order
* choose the correct payment method
* track final ticketing after `pay.do`

### FAQ

#### What do I need before `pay.do`?

You need a valid `orderNo`, a supported payment method, and card data when the method is card-based.

The order must still be unpaid and still support the selected payment path.

#### Does payment success mean ticketing is already complete?

No.

Payment success does not always mean the airline PNR and ticket numbers are already final.

Use order follow-up until the final ticketing state is confirmed.

#### Is the deadline different for Fulfilment API orders?

Yes.

Orders created from `getOfferPrice.do` use a 5-minute payment and ticketing window.

If ticketing does not complete in time, Atlas cancels the order automatically.

#### Which payment paths are available for Fulfilment API?

Fulfilment API supports deposit and VCC pass-through.

This gives you two operational payment paths.

If one path is unavailable, you can switch to the other when the current order state still allows it.

### Main API

* `pay.do`

### Use this when you need

* Deposit payment
* VCC pass-through payment
* BYOA payment
* MoR payment
* Ticket issuance tracking after payment

### Before you call

Confirm these points first:

* the order already exists
* the order is still unpaid
* the order supports the selected payment method
* card data is ready if you use card-based payment

For standard flows, call `order.do` before `pay.do`.

### What should you keep in mind after payment?

Keep using `orderNo` for order follow-up.

Read the final ticketing state from order query.

Do not send duplicate payment requests when payment may already be in progress or completed.

### Payment methods

* `1`: Deposit
* `3`: VCC pass-through
* `4`: BYOA
* `5`: MoR

### Key inputs

Always send:

* `orderNo`
* `paymentMethod`

Send `creditCard` when using:

* VCC pass-through
* MoR

`threeDS.ip` is only relevant for MoR.

### What comes next?

After `pay.do`, use [Query Order](/api-document/product-guides/booking/booking-step-guides/query-order.md) until the final ticketed state is confirmed.

Use webhook as a supplement, not as the only confirmation path.

### What to watch

* supported payment methods vary by airline and fare
* card brand must match the order requirements
* payment can fail if the booking is past deadline
* payment success does not always mean ticketing is already finished
* you still need order follow-up until the final ticketing state is confirmed

### Best practice

* read supported payment methods from the booking flow before payment
* use deposit when you need fare guarantee after payment
* use VCC only when the fare supports it
* poll order status after payment until ticketing completes
* handle payment retries carefully to avoid duplicate charges

### Fulfilment API deadline

Apply these extra rules when the order comes from `getOfferPrice.do`:

* start payment immediately after order creation
* check the remaining time before every retry
* only retry when the order is still inside the safe operating window
* stop retrying when the order is already near timeout

{% hint style="warning" %}
Do not apply the standard 30-minute order-hold expectation to Fulfilment API orders.

This flow is designed around a 5-minute ticketing deadline.
{% endhint %}

### Fulfilment API payment fit

Use Fulfilment API when you need:

* immediate payment after order creation
* deposit and VCC pass-through as dual payment paths
* near-departure ticketing without the same cache-expiry pressure after request submission

For teams that already hold the required order context, integration can usually be completed in roughly 1 hour.

### Safe retry rule

If payment may already have started, query the order first.

Do not retry payment blindly after `402`, `404`, `406`, or similar order-state errors.

### Common failure cases

Common payment response failures include:

* invalid request data
* payment after deadline
* unsupported payment method
* order already paid
* payment already in progress
* missing passenger data
* card not supported
* card mismatch
* order not confirmed in FR flow

Use the API response `status` as the source of truth.

### Failure alert timing for Fulfilment API

Failure alerts are issued within 6 minutes after ticketing failure is confirmed.

Use `queryOrderDetails.do` as the source of truth for the final order state.

### Related pages

* [Create Order](/api-document/product-guides/booking/booking-step-guides/create-order.md)
* [Confirm Order](/api-document/product-guides/booking/booking-step-guides/confirm-order.md)
* [Query Order](/api-document/product-guides/booking/booking-step-guides/query-order.md)
* [Hybrid Payment Guide](/api-document/product-guides/booking/booking-step-guides/payment-and-ticketing/hybrid-payment-guide.md)
* [Error Codes](/api-document/support-and-reference/troubleshooting-and-support/errors-handing.md)
* [Booking APIs](/api-document/api-reference/booking-apis.md)

### Full API reference

See endpoint-level details here:

* [Payment & Ticketing](/api-document/api-reference/booking-apis/payment-and-ticketing.md)