HYBRID DEVNET · PUBLIC EVIDENCE LIVEVerifiable infrastructure for value, markets, identity, and operational dataInspect the network

Products & integrations

Does checkout availability mean native MPC transfers are enabled?

3 min read

No. External checkout can operate independently through enabled providers and currencies. Native MPC value movement remains subject to its own wallet, authorization, network, and funding checks.

Checkout and wallet signing solve different tasks

A checkout workflow can use an enabled payment provider to request and track a payment. A native MPC wallet workflow concerns the customer’s wallet authority and the participants needed for an enabled asset operation. Both may appear in one application, but completing one does not establish readiness of the other. A merchant seeing an available checkout option should not infer that every native wallet transfer route is also enabled.

Name who performs each part

Ask which provider handles collection, which system records payment status, where the business expects settlement, and which wallet operation is involved, if any. Keep the order, payment, and transfer references distinct. If native value movement is needed later, confirm its account, asset, network, authorization, and funding requirements separately. This helps explain the customer journey without presenting provider payment acceptance as a completed native wallet transaction.

Evaluate the full merchant outcome

A useful test includes what happens after a payment response: delivery, reconciliation, and any exception handling. Test a delayed or incomplete result, not only the happy path. Ask which record establishes each stage and what the merchant should tell a customer while a later stage is pending. A branded interface can make the journey coherent, but it must not hide the difference between an enabled provider workflow and a separately governed wallet capability.

In plain language

What “enabled for your operation” means

A product can support several kinds of activity without making all of them available to every user. For example, reading an existing wallet record is different from creating a wallet, signing a transfer, or withdrawing to another chain. Access can depend on the account, environment, network, product configuration, and required approval. An operation is the exact action you want to take, such as reading a status or requesting a withdrawal. A scope is a limit on what a credential is allowed to request. Seeing a feature in documentation tells you what to investigate; it is not itself an access grant. During an evaluation, ask for a simple list of which actions are enabled, which are read-only, and which are outside the agreed test. Keep that list with your test results. This gives business users and developers the same understanding of what a successful demonstration actually establishes.

In plain language

Why several reference numbers can describe one journey

A business request, a payment-provider record, a Hybrid-Chain event, and an external blockchain transaction can each have their own identifier. These are not competing names for the same database row. They identify different parts of a journey, just as an order number and a parcel tracking number describe related but different records. Keep the relationship between them rather than overwriting one with another. A hash is a compact cryptographic fingerprint used to identify or commit to data; a UUID is another kind of record identifier. Neither should be interpreted from its appearance alone. Use the label beside it and the system that issued it. When asking for help, include the network and the type of reference as well as the value. This makes it much easier to distinguish a missing link from a failed operation and avoids searching an external chain for an internal reference.

What to do next

Confirm the provider and settlement route for the payment workflow you intend to use.

Payments & Commerce ↗Funding & Settlement ↗