API introCopy link

The Payments API enables you to securely retrieve guest credit card or Expedia Virtual Card (EVC) information using a payment token provided by the reservations query of the Lodging Supply GraphQL API.

Endpoint

https://api.expediagroup.com/supply/payments/graphql

All requests must be made over a secure connection. All response bodies, including errors, are encoded in JSON. If no response is returned within 65 seconds, the request has timed out; set your retry logic accordingly.

Use the POST method as shown in this syntax statement:

curl --request POST \
     --url https://api.expediagroup.com/supply/payments/graphql \
     --header 'Authorization: Bearer {token}' \
     --header 'Content-Type: application/json' \
     -d ' {
      paymentInstrument(token: "{token}")
        ...
      }
     '

Even though a POST is sent to the GraphQL endpoint, data will only be retrieved, not modified, because the body contains queries only.

Authentication and authorization

This API uses the same request headers and bearer token that was used when issuing the reservations query that retrieved the token.

Rate limits

The Lodging Supply GraphQL API has a 50 transaction-per-second (TPS) limit that is enforced per connectivity partner. This prevents overuse of our services and ensures fair use by all partners so that we can maintain stability and optimal performance. We constantly evaluate API traffic as it surges and subsides, and we may adjust our rate limit as needed.

To avoid exceeding our rate limit, consider implementing the following strategies:

• Implement caching for read requests for data that does not change often. Store API responses locally and reuse them when possible.
• Spread out your requests over time instead of making them all at once. Running a large volume of closely-spaced requests can lead to rate limiting; try to control the request rate on the client side.
• Implement exponential backoff. If you receive a rate limit error, wait for a short time before retrying. Increase the waiting time exponentially for subsequent failures.
• Monitor your usage to keep track of how many requests you're making. Stay well below the limit to allow for unexpected spikes.
• Optimize your code to ensure you're not making unnecessary API calls.
• Schedule non-urgent tasks during off-peak hours for non-time-sensitive operations.

In the event that the limit is exceeded, the API response will provide either the HTTP status code 429 (and no response body) or HTTP status code 200 with the following error message: { "errors": [ { "message": "Too many requests, please try again in 1 seconds.", "path": [ "propertiesByAdvertiser", "elements", 56, "reservations" ], "extensions": { "source": "Property.reservations", "code": "RATE_LIMIT_EXCEEDED" } }, "data": { "propertiesByAdvertiser": null }, ] }

Testing requests and responses

We provide a graphical integrated development environment (IDE) that enables you to issue query requests using test data. This GraphQL explorer is available on many doc pages on this site. Or, you can install a third-party IDE (desktop app), such as Prisma or Insomnia. After you install the application, configure it with either your client ID and secret or a token generated using these values. Refer to the application's documentation for more information about configuring authorization and headers. Then, load our GraphQL endpoint URL and issue test requests as needed.

Error handling

An error can occur during different phases of a GraphQL request (authentication, validation, schema generation, and execution). If an error occurs, an HTTP status code is returned as well as an error object. The HTTP status code of 200 is returned if a GraphQL execution error occurs, and a non-200 status code is returned if an HTTP or GraphQL request error occurs. For a list of HTTP status codes and GraphQL error classes, refer to Error handling.