---
title: "Retrieve setup status"
method: GET
path: "/setup_intents/{setup_intent_id}/status"
tags: ["Setup Intents"]
---

# Retrieve setup status

`GET /setup_intents/{setup_intent_id}/status`

Retrieves how far a setup has got and what the buyer must do next, if anything. Collection runs in the background, so poll this rather than reading the create response. Accepts either a secret key or the setup's own `client_secret`, so the surface collecting the payment method can poll it directly.

## Path parameters

- `setup_intent_id` string, required

## Response `200`

Setup status retrieved

- SetupStatus
  - `id` string, required — The setup this status describes, prefixed `sint_`.
  - `last_setup_error` SetupLastSetupError, required
    - `code` string, nullable, required — A machine-readable classification of the failure, e.g. `enrollment_declined`. Absent when the buyer simply abandoned the setup.
    - `message` string, nullable, required — A human-readable explanation of the failure.
  - `next_action` union, required — What the buyer must do to finish. `type` picks the shape and each type carries only its own `data`, so switching on `type` gives you exactly that step's payload.
    - PaymentNextActionRedirect
      - `data` PaymentNextActionRedirectData, required
        - `frame_max_width` integer, nullable, required — The widest the provider's page lays out usefully, in CSS pixels — cap a frame or dialog presenting it at this width. `null` when the page fills whatever width it is given.
        - `url` string, required — The provider's page for this payment, as an absolute URL — take the buyer there.
      - `render` string[], required
      - `type` 'redirect', required — Always `redirect`: send the buyer to `data.url`. The provider hands them back to `return_url` when they are done.
    - PaymentNextActionDisplayInstructions
      - `data` union, required — What to show the buyer so they can pay. `kind` picks the shape and the details sit under the key named for it, so switching on `kind` gives you exactly that kind's payload. Every detail field is optional — the rails behind these methods publish them unevenly — but a kind that arrives with `document_url` can always fall back to sending the buyer to that hosted copy of the instructions.
        - PaymentVoucherInstructions
          - `kind` 'voucher', required — Always `voucher`: a code the buyer pays in person, at a convenience store or bank counter.
          - `voucher` PaymentVoucher, required
            - `amount` Money
              - …
            - `barcode` string — The barcode's contents, when the voucher carries one — render it in the symbology named by `barcode_format`.
            - `barcode_format` string — The symbology `barcode` is encoded in, such as `CODE_128`.
            - `company_name` string — Who the payment is made out to.
            - `document_url` string — A hosted page with the complete, printable instructions. If you would rather not render the details yourself, send the buyer here.
            - `expires_at` string — When the voucher stops being payable, as an ISO 8601 timestamp.
            - `provider_logo` string — URL of that network's logo.
            - `provider_name` string — The network the buyer pays at, such as OXXO.
            - `reference` string — The voucher's number — what the buyer reads out or types at the counter to pay.
        - PaymentQrInstructions
          - `kind` 'qr', required — Always `qr`: a code the buyer scans with their banking app.
          - `qr` PaymentQr, required
            - `amount` Money
              - …
            - `document_url` string — A hosted page with the complete, printable instructions. If you would rather not render the details yourself, send the buyer here.
            - `expires_at` string — When the code stops being payable, as an ISO 8601 timestamp.
            - `key` string — An account key the buyer can pay to directly (Colombia's Bre-B llave), for apps that take a key instead of a scan.
            - `qr_code` string — The QR code's contents, ready to render as a scannable image — `qr_format` says how it is encoded.
            - `qr_format` string — How `qr_code` is encoded.
        - PaymentBankTransferInstructions
          - `bank_transfer` PaymentBankTransfer, required
            - `account_number` string — The account to send to, in the local scheme's format — `account_number_label` says what to call it.
            - `account_number_label` string — What to call `account_number` when showing it, in the local scheme's own terms — `CLABE` in Mexico, for example.
            - `amount` Money
              - …
            - `bank_account_type` string — The kind of account receiving the transfer, such as a checking account, in the local system's own vocabulary.
            - `bank_branch` string — The receiving branch, where the local system routes by branch.
            - `bank_code` string — The receiving bank's code in the local clearing system.
            - `bank_name` string — The receiving bank's name.
            - `beneficiary_document` string — The account holder's tax or identity document number, where the local system needs it to send.
            - `beneficiary_document_type` string — What kind of document `beneficiary_document` is, in the local system's own vocabulary.
            - `beneficiary_name` string — Who the account belongs to — the name the buyer's bank may ask them to confirm.
            - `document_url` string — A hosted page with the complete, printable instructions. If you would rather not render the details yourself, send the buyer here.
            - `expires_at` string — When these details stop being payable, as an ISO 8601 timestamp.
            - `instructions` string — The rail's own step-by-step payment text, when it supplies one.
            - `reference` string — The reference the buyer must attach to the transfer so it can be matched to this payment.
            - `secondary_account_number` string — A second account number, where the rail publishes the same destination in more than one format.
            - `secondary_account_number_label` string — What to call `secondary_account_number` when showing it.
          - `kind` 'bank_transfer', required — Always `bank_transfer`: account details the buyer sends money to from their own bank.
      - `render` string[], required
      - `type` 'display_instructions', required — Always `display_instructions`: show the buyer `data` — what to pay, where, and by when. The payment completes once they pay and the rail confirms it, so keep polling `status`.
    - PaymentNextActionAwaitConfirmation
      - `data` PaymentNextActionAwaitConfirmationData, required
        - `expires_at` string, required — When the confirmation window closes, as an ISO 8601 timestamp. A payment still unconfirmed by then will not succeed — watch `status` for the failed attempt.
      - `render` string[], required
      - `type` 'await_confirmation', required — Always `await_confirmation`: nothing to show — the buyer has done their part and the rail settles out of band. Poll `status` until it moves.
  - `object` string, required — Always `setup_status`.
  - `return_url` string, nullable, required — Where to send the buyer once the setup reaches a resting state, or `null` to leave them where they are.
  - `status` 'processing' | 'succeeded' | 'canceled' | 'requires_action', required — How far the setup has got. **A 200 means we answered, not that the method was saved — always branch on this.** `requires_action` — the buyer has a step outstanding; see `next_action`. `processing` — the buyer has done their part and the processor is deciding. `succeeded` — the payment method is saved, and only this one means saved. `canceled` — abandoned or refused; see `last_setup_error` to tell which.

## Other responses

- `401` — Unauthorized
- `403` — Forbidden
- `404` — Resource not found

---

[API](https://skmtc.net/whop/apis/whop-api.md) · [All operations](https://skmtc.net/whop/apis/whop-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/whop/whop-api/revisions/a84d4905fdbb/schema)