Connected Devices Could Become an Economic Network

The charging station has delivered energy. The buyer's system says the transaction is still pending. The network connection has disappeared.

A successful demonstration rarely pauses at this point. A commercial system has to continue from it.

At TLAY, we think this is a useful test of the transition from connected devices to an economic network. Devices can exchange commands without giving their operators a reliable way to resolve unfinished business. Commerce requires that unfinished business to have an owner, a state and a path to resolution.

The following charging transaction is a design example, not a report of a deployed TLAY project. Its purpose is to follow one failure all the way through.

The agreement before the interruption

A delivery robot operated by Company A needs energy from a charging station operated by Company B. The agreed price is $0.50 per kilowatt-hour, with a maximum delivery of 10 kWh and a maximum payment of $5. The price and authorization have a defined validity period.

Company A authorizes this particular purchase. In this example, $5 is placed in a prepaid settlement balance reserved for the order. It is not yet all earned by the seller. The agreement allows billing for measured partial delivery and returning the unused amount.

Both sides refer to the same order identifier. It connects the offer, authorization, device execution and eventual financial result. A retry must preserve that identity rather than create an apparently unrelated purchase.

Before starting, the charging system records the accepted order durably. Its local execution policy specifies limits and behavior if communication fails. This preparation determines what the participants can later reconstruct.

The service starts. The buyer has committed funds; the seller has begun performing work.

Four kilowatt-hours later

After 4 kWh has been delivered, the connection fails. Under the policy chosen for this example, the station stops delivery safely and retains the local meter reading and execution record. Other applications might permit bounded offline continuation, but that would need a different explicit policy.

The station produces a signed partial-completion record. Its attempt to send that record fails. Company A's system still sees an open order and cannot tell from that status alone whether no energy, some energy or the full amount was delivered.

The missing response is not evidence that no work occurred. Treating it that way creates a dangerous retry: the robot could start a second purchase while the first remains unresolved.

Nor should Company B settle the full $5 merely because it has not received a cancellation. The agreed quantity was a maximum, not evidence of actual delivery.

Both operators are now dealing with uncertainty about the same physical event.

A retry should ask before it acts

When communication returns, Company A queries the original order. The request carries the existing identifier. The station checks its persistent state and returns the retained result rather than starting another charging session.

This is the practical role of idempotent request handling: repeated requests for the same operation should not create repeated commercial actions. It needs durable records and careful execution design. Putting an identifier in a message is insufficient.

A crash between recording an instruction and operating the hardware can still create uncertainty. The device must reconcile execution state with available measurements. If it cannot establish what happened, the system should expose that uncertainty and stop automatic settlement where required.

Exactly-once physical performance is not something a payment interface can simply promise. The recovery path must account for the boundary between software state and physical action.

The receipt needs an interpretation

The returned record identifies the station, order, relevant readings and partial-delivery state. Company A checks that it belongs to the authorized transaction and that the amount is consistent with the agreed limits.

A signature helps establish provenance and integrity. It does not independently prove the meter's calibration or the physical delivery. The commercial arrangement still needs an agreed measurement method and a process for inconsistent evidence.

If the buyer's records disagree materially with the station's, the transaction should enter a dispute state. A designated operator can investigate using the retained evidence. Automatically selecting whichever signed value arrives first would confuse authenticity with correctness.

For this example, the records reconcile to 4 kWh. The parties therefore have an agreed basis for charging $2.

Closing both the service and the money

The settlement process releases $2 to Company B and returns the remaining $3 to Company A from the prepaid balance. These financial actions also reference the original order and must tolerate duplicate delivery of the same completion message.

The final record shows a partially completed service, the accepted quantity and the financial outcome. It should not be relabeled as a fully completed 10 kWh order simply because payment reconciliation succeeded.

The robot still needs energy. That is a new business decision. It can place another order with the same station or seek another provider, using a new authorization where required. Recovery of the first transaction should not silently become permission for additional work.

This separation prevents an accounting repair from expanding the machine's authority.

What if the station never comes back?

The agreement needs a deadline and a responsible party for unresolved transactions. Depending on the evidence and terms, funds may remain reserved temporarily, a manual review may determine partial payment, or a defined refund procedure may apply.

There is no universal rule that safely settles every missing-record case. Immediate full refunds can expose sellers who performed work. Indefinite holds can harm buyers. The acceptable trade-off depends on the service, amount and evidence available.

The infrastructure should make the unresolved state visible, preserve the evidence and route the case to the party authorized to decide. It should not hide the problem behind an endlessly spinning “pending” label.

For TLAY, a useful machine commerce integration must include this recovery behavior alongside the successful payment path. An operator needs to know how a half-finished transaction becomes a closed one without duplicate work, unexplained charges or lost evidence.