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

# Check Venmo and PayPal payout status (free)

> Reports the state of the Venmo and PayPal payouts this account has sent with `GET /send-payment`. Free: only the payout itself is a paid action.

Three ways to call it: with `payment_id` to fetch one payout, with `recipient_id` (from `GET /payment-recipients`) to list every payout to that saved recipient, or with neither to list every payout this account has sent, newest first.

`state` is `queued` (waiting on account balance), `in-process` (dispatched to the platform), `complete`, `failed`, or `cancelled`. `queued` and `in-process` are the two states still in flight; poll every few minutes, or register a webhook with `POST /register-webhook` to be told when a payout completes instead. A payout that has been `in-process` for more than an hour is worth raising with the account owner. `state` is absent on payouts sent before state tracking existed.

Bank payouts are not listed here: follow those with `listBankingTransactions`. Push-to-card transfers are completed by the recipient in the browser and have no server-side state.

Requires a Bearer token from `/auth` or `/get-card`.



## OpenAPI

````yaml /api-reference/openapi.json get /get-payment-status
openapi: 3.1.0
info:
  title: Laso Finance x402 API
  version: 1.0.0
  x-docs-revision: 4a76ba2a603c
  x-docs-manifest: https://laso.finance/.well-known/docs-version.json
  contact:
    email: agents+support@laso.finance
  x-guidance: >-
    Laso Finance is a payment-gated (x402) API that lets an AI agent spend USDC
    on real-world financial products: prepaid cards (U.S. and international),
    gift cards, push-to-card transfers to USD/EUR/GBP debit cards, and
    Venmo/PayPal payouts.


    Payment: every paid route is an x402 v2 endpoint. Call it with no payment
    header to receive a 402 challenge listing the accepted networks, then replay
    with a signed USDC payment. Both Base (eip155:8453) and Solana
    (solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp) are accepted on every paid route;
    the caller picks either chain.


    Identity: `GET /auth` is free and identity-only. Prove wallet ownership with
    a `SIGN-IN-WITH-X` (CAIP-122) header to receive a Firebase id_token, then
    send that token as a Bearer credential to the authenticated read routes
    (`get-card-data`, `get-account-balance`, `get-kyc-status`, etc.). Paid
    routes also return fresh auth credentials in their response, so a payment is
    never required just to obtain a token.


    Recommended flow: (1) `GET /auth` to establish identity, (2) call a paid
    route (e.g. `GET /get-card`) to purchase a product, paying USDC on Base or
    Solana, (3) poll the authenticated read routes with the returned Bearer
    token to fetch the resulting card/transfer details. Full machine-readable
    instructions live at https://laso.finance/SKILL.md.
  description: >-
    Payment-gated API for Laso Finance. All paywalled routes use the x402
    protocol — the caller includes a USDC payment header on Base (eip155:8453)
    or Solana (solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp) and the server verifies
    payment before processing. Free routes require no payment header. The same
    402 also carries an MPP (Machine Payments Protocol) challenge in
    WWW-Authenticate; an MPP client pays with USDC on Base by replaying with
    `Authorization: Payment ...`, and routes, prices, and responses are
    identical.


    ## Getting started


    To set up a wallet for making x402 payments, choose a provider:


    - **Locus** (default): https://paywithlocus.com/SKILL.md

    - **Sponge**: https://wallet.paysponge.com/skill.md — automatic x402 service
    discovery

    - **Ampersend**: https://www.ampersend.ai/getting-started.md — self-custody
    on Base or Solana with dual-approval spending limits. Laso Finance is a
    default skill, so no manual endpoint registration is needed.


    ## How x402 works


    1. Call a paywalled endpoint without a payment header → receive a `402
    Payment Required` response containing payment details (price, recipient
    address, network).

    2. Construct an x402 payment header using the details from the 402 response.

    3. Replay the request with the payment header → the server verifies payment
    and processes the request.


    ## Authentication flow


    `GET /auth` is free: callers prove wallet ownership by sending a
    `SIGN-IN-WITH-X` header (CAIP-122 wallet signature). Paywalled routes
    (`/get-card`, `/order-gift-card`, `/get-push-to-card`, `/order-intl-card`)
    also return fresh auth credentials in their responses, so a payment is never
    required just to obtain a token.


    Most routes return auth credentials (`id_token`, `refresh_token`,
    `expires_in`). Use the `id_token` as a Bearer token to call authenticated
    Laso Finance endpoints like `/get-card-data`. When the `id_token` expires,
    use `POST /auth` with `grant_type: refresh_token` to get a new one.


    ## Important notes


    The `/get-card` USA prepaid card endpoint is U.S. only — issued in USD,
    usable at U.S.-based merchants only, and physical goods must ship to a U.S.
    address. For non-U.S. merchants or non-USD currencies, use `GET
    /order-intl-card` instead (international prepaid card, admin-fulfilled
    within 24 hours). All cards are intended for the caller's own use.


    ## Rate limits


    Every response carries the request budget so you can pace yourself without
    probing for a limit:


    | Header | Meaning |

    | --- | --- |

    | `RateLimit-Limit` | Requests permitted per window |

    | `RateLimit-Remaining` | Requests still available |

    | `RateLimit-Reset` | Seconds until the window rolls over |

    | `RateLimit-Policy` | The policy these numbers describe, as
    `limit;w=seconds` |


    The same values are repeated as `X-RateLimit-*` for clients that only parse
    that spelling.


    Most routes advertise the service-wide ceiling. `POST /signup` enforces its
    own per-IP budget on top of it and overwrites these headers with its own
    numbers. `POST /refresh-card-data` is limited per card rather than per
    caller, so its headers keep the service-wide values and the per-card budget
    is reported only on rejection.


    Every rejection is a `429` carrying `Retry-After` in seconds and a matching
    `retry_after_seconds` field in the body, computed from the limit that
    actually rejected the request. Wait that long and retry once. Do not retry
    in a tight loop.


    For step-by-step instructions, read https://laso.finance/SKILL.md
servers:
  - url: https://laso.finance
    description: Production
security: []
paths:
  /get-payment-status:
    get:
      summary: Check Venmo and PayPal payout status (free)
      description: >-
        Reports the state of the Venmo and PayPal payouts this account has sent
        with `GET /send-payment`. Free: only the payout itself is a paid action.


        Three ways to call it: with `payment_id` to fetch one payout, with
        `recipient_id` (from `GET /payment-recipients`) to list every payout to
        that saved recipient, or with neither to list every payout this account
        has sent, newest first.


        `state` is `queued` (waiting on account balance), `in-process`
        (dispatched to the platform), `complete`, `failed`, or `cancelled`.
        `queued` and `in-process` are the two states still in flight; poll every
        few minutes, or register a webhook with `POST /register-webhook` to be
        told when a payout completes instead. A payout that has been
        `in-process` for more than an hour is worth raising with the account
        owner. `state` is absent on payouts sent before state tracking existed.


        Bank payouts are not listed here: follow those with
        `listBankingTransactions`. Push-to-card transfers are completed by the
        recipient in the browser and have no server-side state.


        Requires a Bearer token from `/auth` or `/get-card`.
      operationId: getPaymentStatus
      parameters:
        - name: payment_id
          in: query
          required: false
          description: Fetch one payout by its `id`. Takes precedence over `recipient_id`.
          schema:
            type: string
        - name: recipient_id
          in: query
          required: false
          description: >-
            List every payout to one saved recipient. This is the `recipient_id`
            returned by `GET /payment-recipients`, not the phone number or
            email.
          schema:
            type: string
      responses:
        '200':
          description: >-
            Returns `{ "payment": PaymentStatus }` when `payment_id` is
            provided, or `{ "payments": PaymentStatus[] }` (newest first)
            otherwise.
          content:
            application/json:
              schema:
                oneOf:
                  - type: object
                    properties:
                      payment:
                        $ref: '#/components/schemas/PaymentStatus'
                  - type: object
                    properties:
                      payments:
                        type: array
                        items:
                          $ref: '#/components/schemas/PaymentStatus'
              examples:
                single:
                  summary: One payout by payment_id
                  value:
                    payment:
                      id: otlUYhH8n7Q2KWmt6FBs
                      amount_pre_fees: 10
                      amount_with_fees: 11.5
                      fees_paid: 1.5
                      platform: venmo
                      state: complete
                      state_updated_at: 1789365621369
                      recipient_id: Bh3bHdQwErTyUiOpAsDf
                      recipient_first_name: Jane
                      recipient_last_name: Doe
                      timestamp: 1789364854261
                      timestamp_readable: 9/14/2026, 6:47:34 AM
        '401':
          description: Missing or invalid Bearer token
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
              example:
                error: Invalid or expired token
        '403':
          description: >-
            Account is frozen. The response includes a `frozen_message` field
            explaining why.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/FrozenError'
        '404':
          description: >-
            `payment_id` was given and no Venmo or PayPal payout with that id
            belongs to this account.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'
              example:
                error: Payment not found
                code: payment_not_found
                hint: >-
                  No Venmo or PayPal payment with that id belongs to this
                  account. Use the id from GET /get-payment-status without a
                  payment_id, which lists every payout this account has sent.
      security:
        - BearerAuth: []
components:
  schemas:
    PaymentStatus:
      type: object
      description: One Venmo or PayPal payout sent from this account.
      properties:
        id:
          type: string
          description: Pass as `payment_id` to fetch this payout on its own.
        amount_pre_fees:
          type: number
          description: Dollars the recipient receives.
        amount_with_fees:
          type: number
          description: Dollars debited from the account balance, fee included.
        fees_paid:
          type: number
        platform:
          type: string
          enum:
            - venmo
            - paypal
        state:
          type: string
          enum:
            - queued
            - in-process
            - complete
            - failed
            - cancelled
          description: >-
            `queued` and `in-process` are still in flight. Absent on payouts
            sent before state tracking existed.
        state_updated_at:
          type: integer
          description: Milliseconds since the epoch when `state` last changed.
        recipient_id:
          type: string
          description: >-
            The saved recipient this went to, as returned by `GET
            /payment-recipients`.
        recipient_first_name:
          type: string
        recipient_last_name:
          type: string
        timestamp:
          type: integer
          description: Milliseconds since the epoch when the payout was sent.
        timestamp_readable:
          type: string
    Error:
      type: object
      properties:
        error:
          type: string
    FrozenError:
      type: object
      properties:
        error:
          type: string
          example: Account is frozen
        frozen_message:
          type: string
          description: Human-readable explanation of why the account is frozen
  securitySchemes:
    BearerAuth:
      type: apiKey
      in: header
      name: Authorization
      description: >-
        Firebase ID token from `/auth` or any paid route, sent as a Bearer
        token: `Authorization: Bearer <id_token>` (the `Bearer ` prefix is
        required).

````