> For the complete documentation index, see [llms.txt](https://developers.bead.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers.bead.xyz/faqs-and-troubleshooting/payments-faqs/why-is-the-processing-status-missing-for-some-payments-especially-on-physical-terminals.md). # Why is the processing status missing for some payments, especially on physical terminals? ## Why is the `processing` status missing for some payments, especially on physical terminals? ### Short answer `processing` is a best-effort intermediate signal, not a guaranteed step in every payment's lifecycle. Whether you see it depends on the payment environment (virtual vs. physical) and on the tender or network used. Some flows give Bead a clear synchronous signal that a payment has started, so `processing` is set immediately. Other flows are inherently asynchronous, and the first signal Bead receives may be the final outcome itself, with no `processing` event in between. This is expected behavior, not a bug. `created` and `completed` (or another final status) remain reliable. Only `completed` should ever be used as your fulfillment trigger — see [Payment Statuses](/payments/payment-statuses.md) for the full status model and finality rules. ### Why this happens Bead supports many asset types, wallet networks, and payment environments, and each has different capabilities for reporting an in-progress state. The presence or absence of `processing` comes down to one question: **does Bead have visibility into the payment while it is underway, or only once it resolves?** #### Virtual terminals (hosted checkout, ecommerce, remote/customer-not-present) In a virtual terminal flow, the customer is interacting with Bead's hosted payment page directly. When the customer selects a tender — for example, clicking "Continue with Klarna" — that click is a synchronous action inside Bead's own hosted experience. Bead knows the instant the customer has committed to a tender and handed off to that provider, so the payment can move to `processing` right away, before the provider has confirmed anything back to Bead. In this environment, `processing` behaves close to how most integrators expect: `created` → `processing` (tender selected, handoff underway) → `completed` (or another final status). #### Physical terminals (in-store, point-of-sale, customer-present) In a physical terminal flow, the customer is typically presented with a QR code and completes the transaction independently, often on their own device, outside of any Bead-controlled interface. This handoff is asynchronous by nature: * Bead has no visibility into when the customer scans the code. * Bead has no visibility into when the customer initiates the transaction on the provider's or network's side. * Depending on the tender or asset, Bead's first signal may be the arrival of funds or a completion event from the network — with nothing in between. For some tenders and crypto assets that lack an intermediate "in-flight" signal from the network itself, there is no event for Bead to relay as `processing`. The payment can appear to jump directly from `created` to a final state such as `completed`. #### Klarna example * **Virtual terminal + Klarna:** the customer clicks "Continue with Klarna" inside Bead's hosted page. Bead observes this action directly and sets the payment to `processing` immediately, ahead of Klarna's own confirmation. * **Physical terminal + Klarna:** the customer scans a QR code and completes the Klarna flow on their own device. Bead has no synchronous signal that the customer has started the transaction — only the eventual outcome from Klarna. The payment can remain at `created` and then move directly to a final status once Klarna reports completion, with no observable `processing` step in between. Same tender, same underlying provider — different visibility depending on which environment initiated the payment. #### Crypto assets The same pattern shows up with certain crypto tenders. Some networks and wallet flows provide an intermediate "detected, not yet confirmed" signal (for example, BTC on-chain payments, which can sit in `processing` for several minutes while the network confirms — see [Why do BTC (on-chain) payments take longer?](/faqs-and-troubleshooting/payments-faqs/why-do-btc-on-chain-payments-take-longer.md)). Others do not surface an in-flight state at all. In those cases, the first event Bead can report may be the arrival of the crypto itself, which can immediately resolve the payment rather than passing through a visible `processing` step. ### What this means for your integration * **Do not build logic that assumes `processing` will always occur.** Treat it as an optional, informational milestone — useful when present, not required for correct handling. * **Do not use terminal type, tender, or asset as a signal that something is broken** if a payment moves straight from `created` to a final status. This is expected for asynchronous, customer-device-initiated flows. * **Continue to use `completed` as your only fulfillment trigger**, regardless of whether `processing` was observed. This is unchanged from the general status guidance in [Payment Statuses](/payments/payment-statuses.md). * **Design webhook consumers to handle either sequence gracefully:** * `created` → `processing` → `completed` (typical for virtual/hosted flows and tenders with in-flight signals), or * `created` → `completed` (typical for physical/QR-initiated flows and tenders without an in-flight signal) * **If you show payment status to staff or customers in a physical environment,** avoid messaging that implies `processing` is guaranteed to appear (e.g., "waiting for processing to begin"). Prefer neutral language such as "waiting for payment" until a final status is returned. ### Quick reference | Environment | Tender/network behavior | Typical status path | | --------------------------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------- | | Virtual (hosted checkout) | Synchronous handoff observable by Bead (e.g., Klarna redirect click) | `created` → `processing` → final status | | Physical (QR / customer-present) | Asynchronous handoff, no intermediate signal available | `created` → final status (no `processing`) | | Crypto with network confirmation window | Network reports an in-flight/unconfirmed state (e.g., BTC on-chain) | `created` → `processing` (may last minutes) → final status | | Crypto without an in-flight signal | First signal is arrival/confirmation itself | `created` → final status (no `processing`) | ### Related pages * [Payment Statuses](/payments/payment-statuses.md) — full status model, finality rules, and fulfillment guidance * [Choosing Tender Types by Payment Environment](/reference-guide/payment-flows/choosing-tender-types-by-payment-environment.md) — guidance on matching tenders to physical, digital, invoice, and delayed-fulfillment flows * [Why do BTC (on-chain) payments take longer?](/faqs-and-troubleshooting/payments-faqs/why-do-btc-on-chain-payments-take-longer.md) — a related case where `processing` is present but long-running * [Payment Webhooks](/payments/payment-webhooks.md) — event delivery for status changes, including flows that skip `processing` * [Create Payment](/payments/create-payment.md) — terminal type considerations for virtual vs. physical payment creation --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://developers.bead.xyz/faqs-and-troubleshooting/payments-faqs/why-is-the-processing-status-missing-for-some-payments-especially-on-physical-terminals.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.