See how far a merchant has got in setting up card acceptance, step by step.

The status is worked out on every request from the merchant's actual keys, webhooks and payments. Nobody can mark a step done by hand.

Each step has a status of done, todo, blocked or not_applicable, and a completed_at date where known:

• checkout_domains: an active publishable key with at least one allowed origin. Returns publishable_key_prefix; the full key is shown only once, when created.
• secret_key: an active secret key pinned to the merchant.
• webhook: an enabled webhook endpoint for the merchant subscribed to payment.captured.
• test_payment: a successful payment on a test deployment. On production this is not_applicable and includes a sandbox_url.
• support_email: a customer-support email address set for the merchant or its tenant (the platform default does not count). Payment receipts use it. It does not count toward summary.
• live_ready: everything needed to take real cards is in place. Otherwise blocked, with blocked_code and blocked_reason for the first blocker and blockers[] for all of them. Codes: not_live_deployment, merchant_not_active, card_pan_custody_disabled, compliance_not_published, acquirer_unavailable.

summary is one of:

• not_started: no setup step is done.
• in_progress: some are done.
• ready: all setup steps and live_ready are done. On a test deployment, ready also applies when the only blocker is not_live_deployment.
• blocked: all setup steps are done but the account or platform is not yet ready for live cards.

The response also gives this deployment's environment, livemode, script_url and fields_origin. It never contains key values or webhook signing secrets.

Merchant users see their own merchant; asking for another merchant gets a 404. Tenant owners, admins and members must pass merchantId for a merchant on their tenant; other tenants' merchants get a 404.