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

Business use cases

How could a merchant or marketplace evaluate payment operations?

3 min read

Start with a defined payment journey: request, provider response, delivery, reconciliation, and exceptions. Include pending payments and repeated notifications in the test plan. Confirm enabled providers, currencies, and the separately authorized settlement route.

Follow one order through the whole journey

Choose a representative merchant or marketplace payment. Identify the order terms, payment request, provider response, delivery result, and reconciliation record. Ask which system owns each stage and what confirms its completion. This prevents an early success message from being treated as the entire business outcome. Include the relevant asset and network context and any provider-specific requirements. The pilot should use only the providers and operations actually enabled for the agreed environment.

Include the cases that create support work

Try a delayed response, an incomplete amount, a repeated notification, or another realistic exception within the approved test scope. Ask an operator to explain the situation using the saved references. Check whether the customer-facing wording is clear about what has happened and what remains pending. A delivery problem does not necessarily reverse a payment, and a refund, where supported, is its own authorized action rather than an assumed side effect.

Evaluate reconciliation and responsibility

Determine whether the business can match the payment to the intended order, explain fees, and identify unresolved work. Measure investigation effort rather than only how quickly the happy-path screen appears. Keep settlement to treasury, external execution, and delivery separate when they have different conditions. At the end of the pilot, name the owner of each exception and the source of the authoritative status. Those operating details make a payment integration useful after the demonstration is over.

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.

In plain language

An example is not a production result

The examples in this FAQ explain how to think about a workflow. They are not reports of customer results, guarantees of performance, or instructions to use real funds. A useful evaluation starts with agreed access, a non-production environment where appropriate, and data that you are permitted to use. Decide in advance what a pass looks like and what must be refused. An allowed case alone is not enough: the team should also try an unauthorized request, a missing requirement, or an unavailable dependency where the test scope permits it. Keep the result and its context so someone else can understand what was demonstrated. Passing that test provides evidence for the tested combination of product, configuration, and environment. It does not automatically enable a different operation or network. Moving to production should be a separate, explicit decision with the required owners involved.

What to do next

Review the payment-operations solution and agree a controlled evaluation with your integration team.

Payment operations ↗Payments & Commerce ↗