> ## Documentation Index
> Fetch the complete documentation index at: https://docs.atum.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Resolve a payment request

> Look a payment up by the request_id you submitted, for when you lost the submit response but kept your idempotency key.



## OpenAPI

````yaml GET /v1/payments/resolve
openapi: 3.0.3
info:
  title: Atum Payment Gateway API
  description: >
    The Atum Payment Gateway API enables secure, cross-chain payments with
    built-in escrow protection 

    and settlement verification. This API facilitates decentralized payment
    routing across multiple blockchain 

    networks while ensuring transaction atomicity and settlement guarantees.


    ## Supported Blockchains

    - Ethereum and EVM-compatible chains (Arbitrum, Optimism, Base, etc.)

    - Solana

    - Tron


    ## Authentication


    No API key, token, or authorization header is required on any operation.

    A payment carries its own authorization: the `sender_auth` signed messages
    prove

    control of the funding account, and are verified on every submission.
  version: 1.0.0
servers:
  - url: https://payment-gw.production-mainnet.atum.xyz
    description: Mainnet
  - url: https://payment-gw.production-testnet.atum.xyz
    description: Testnet
security: []
tags:
  - name: Payments
    description: >-
      Submit a payment and follow it to settlement, by payment id, by your own
      request id, or step by step.
  - name: Authorizations
    description: Counterparty authorization requested while a payment is being accepted.
  - name: Quote Requests
    description: >-
      The two-phase quote flow - open a quote-request batch, poll it, then award
      one quote.
  - name: Chain Defaults
    description: >-
      The per-chain corridor addresses a client needs before it can build and
      sign a payment.
  - name: Health
    description: Liveness probe for the gateway.
paths:
  /v1/payments/resolve:
    get:
      tags:
        - Payments
      summary: Resolve a request ID to a payment ID
      description: >
        Looks up the payment ID associated with a given client-supplied request
        ID.

        Used by tooling like the payment explorer so callers can look a payment
        up

        by the request ID they originally submitted.
      operationId: resolvePayment
      parameters:
        - name: request_id
          in: query
          required: true
          description: The client-supplied request ID embedded in the payment request
          schema:
            type: string
      responses:
        '200':
          description: Payment found
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ResolvePaymentResponse'
        '400':
          description: Missing request_id parameter
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorResponse'
        '404':
          description: No payment found for the given request ID
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorResponse'
        '500':
          description: Internal server error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ErrorResponse'
components:
  schemas:
    ResolvePaymentResponse:
      type: object
      required:
        - payment_id
      properties:
        payment_id:
          type: string
          description: The payment ID that corresponds to the given request ID
          example: '0x8b73c3c69bb8fe3d512ecc4cf759cc79239f7b179b0ffacaa9a75d522b39400f'
    ErrorResponse:
      type: object
      description: >-
        Safe, outward-facing error. Derived from an internal error through the
        shared error catalog. The public code identifies the category and the
        message is a curated, safe description.


        A panic is caught by shared middleware that responds `{"error":
        "Internal server error occurred"}` instead, so a 500 is not guaranteed
        to carry this shape.
      required:
        - code
        - message
      properties:
        code:
          type: string
          description: Public, machine-readable error category in SCREAMING_SNAKE_CASE.
          pattern: ^[A-Z][A-Z0-9_]*$
          example: INVALID_SOURCE_ASSET
        message:
          type: string
          description: Curated, safe, human-readable message.
          maxLength: 500
          example: The source asset identifier is not a valid CAIP-19 asset.
        request_id:
          type: string
          description: >-
            Correlation id to quote to support to locate the internal error
            record.
          example: req_123456789
        payment_id:
          type: string
          description: >-
            The payment this error was raised against. Absent when the error is
            not about a specific payment.
          example: '0xc7108e200d11580e7e75185991084b42a535af588ba8267cd0d1e7df089e5c9c'
        docs_url:
          type: string
          format: uri
          description: Link to the documentation page for this public code.
        domain:
          type: string
          description: Originating service domain.
          example: PAYMENT_GATEWAY
        retry_classification:
          type: string
          description: >-
            What the caller should do next. Absent means the condition has not
            been classified, which is not the same as safe to retry.

            Re-sending the same `request_id` is an idempotent replay and always
            safe. This value is about submitting a new one, which starts a new
            operation. See https://docs.atum.xyz/errors for the value set.
          example: RECONCILE_THEN_DECIDE
        request_id_reusable:
          type: boolean
          description: >-
            Whether the caller may re-send this same request_id. True means no
            payment was created for it, so the id is still free. False means a
            payment exists for it, so the id is spent and re-sending only
            replays this outcome. Absent means undetermined, which a caller
            should read as false. Separate from retry_classification, which
            answers what the caller must change rather than whether the id
            survived.
          example: false

````