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 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?). 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.

• 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 — full status model, finality rules, and fulfillment guidance

• Choosing Tender Types by Payment Environment — guidance on matching tenders to physical, digital, invoice, and delayed-fulfillment flows

• Why do BTC (on-chain) payments take longer? — a related case where processing is present but long-running

• Payment Webhooks — event delivery for status changes, including flows that skip processing

• Create Payment — terminal type considerations for virtual vs. physical payment creation