Machine-to-machine payments: when the device holds the wallet

A software agent buying on a person's behalf still has a person behind it: a card, a mandate, a name to sue. Machine-to-machine payments are a narrower and older problem. A delivery van pays a charging bay for electricity. A shipping container pays a port for handling. A factory sensor sells a reading to a buyer it has never been introduced to. None of these involve a chat interface or a delegated purchase on someone's shopping list; they involve two pieces of equipment that must identify each other, agree a price, move value and settle a dispute without a human in the loop at the moment of the transaction. That is a different engineering and legal problem from software agents buying on a person's behalf.

Device identity: the SIM as a root of trust

Before a machine can pay, it has to prove which machine it is. The most widely deployed answer is not a new blockchain identity scheme but an old component repurposed: the SIM. The GSMA's IoT SAFE specification, IoT SIM Applet For Secure End-to-End Communication, lets a device use the cryptographic material inside its SIM, eSIM or iSIM as a standardised hardware root of trust, generating keys and certificates and establishing secure sessions from a tamper-resistant chip rather than from a weaker software store elsewhere in the device (GSMA industry material). IoT SAFE is specified for securing data communications rather than for payments as such, but it is the same root of trust that machine-payment identity schemes build on. Because eUICC-based remote SIM provisioning already lets an operator change a device's mobile identity without touching the hardware, that identity survives a change of network or country. This matters because most industrial machines are unattended: there is no screen to type a password into, and nobody nearby to approve a step-up authentication prompt.

The clearest commercial example is Pairpoint, the Economy of Things joint venture between Vodafone and Sumitomo Corporation, which issues connected devices standards-based digital identities stored within their SIMs and uses those identities to permit trades with other permissioned devices. On 10 October 2024 the two companies announced a partnership with Mastercard connecting the Pairpoint platform to Mastercard Gateway, so that vehicles could make authorised direct payments at charging or fuel stations, tolls and congestion charges, and freight operators could settle pre-approved port, handling and storage charges along a route (Vodafone, 10 October 2024). Mastercard is a partner integrating its gateway, not a third owner of the venture. The announcement said the service would become available in the UK "later this year", meaning 2024, followed by a progressive European roll-out. Nearly two years on, we found no independently confirmed production volume, only that announcement, later partnership announcements and coverage repeating the same launch language. Treat it as a named, funded deployment moving towards scale, not as evidence of scale.

Wallet custody on hardware that cannot ask a question

A device that pays needs somewhere to keep the keys, and constrained hardware, a meter, a sensor, a vehicle's telematics unit, cannot run the same custody model as a phone or a bank. The practical options collapse to the same choices institutions already weigh for any private key, squeezed into less silicon and less power budget: a secure element or hardware security module embedded in the device, multi-party computation that splits signing authority so no single compromised device can move funds alone, or a session key with a hard spending limit that expires and has to be reissued. We set out that trade-off, including where custodians draw the line between convenience and single points of failure, in our piece on MPC, multisig and HSM key management. The same reasoning applies to a charging post as to a treasury wallet, except that the device usually has no operator watching a dashboard when something goes wrong.

Micropayments, metering and where the money actually moves

Machine payments are frequently small and frequently continuous: a per-kilowatt-hour charge, a per-megabyte data fee, a per-reading sensor fee. Running each of those through a card network's per-transaction cost structure does not work, which is why the technical literature keeps returning to payment channels, off-chain constructs that batch many small transfers and settle a net amount on-chain only when the channel closes, and to purpose-built low-fee ledgers marketed at machine transactions. Both routes push the per-transaction cost close to zero, and both move the dispute problem downstream: if a channel is closed on a disputed final balance, or a feeless ledger has no chargeback mechanism, the argument about who owes what happens after the money has moved. Metering is the quieter half of the problem. The payment is only as trustworthy as the reading it is paying for, and a compromised or miscalibrated sensor produces a bill that is technically valid and substantively wrong.

Mastercard's Agent Pay for Machines is worth naming here mainly to draw a boundary. Despite the "machines" in its name, Mastercard's 10 June 2026 announcement describes AI software agents transacting with each other and with merchant systems at high velocity, in amounts down to fractions of a cent, settling across cards, accounts and stablecoins, with more than thirty named early partners and illustrative scenarios such as settling invoices and paying for compute rather than named physical-device deployments (Mastercard, 10 June 2026). That is the agentic-commerce problem, not the device-to-device one. The overlap in vocabulary between the two is a recurring source of confusion in vendor material.

A live, mandated deployment: Plug and Charge

The one machine-payment mechanism genuinely in force across a continent, rather than merely piloted, sits in electric vehicle charging. ISO 15118's Plug and Charge feature lets a vehicle and a charge point authenticate each other over the charging cable using certificates, so a session starts and billing is attributed to the vehicle's charging contract with no card, app or QR code at the point of use. The EU's Alternative Fuels Infrastructure Regulation, Regulation (EU) 2023/1804 as amended in 2025, requires newly installed or renovated publicly accessible AC charging points to support EN ISO 15118-2:2016 from 8 January 2026, extending to EN ISO 15118-20:2022 and to private charging points from 1 January 2027. The first deadline has passed: qualifying new public AC charge points in the EU must support it now.

It is not a solved security problem. "Charge It to My Neighbor: A Relay Attack on ISO 15118 Plug and Charge Payment", first posted in December 2025 and revised in May 2026, demonstrates a relay attack: an attacker builds a fake charging station, plugs it into a victim's vehicle and relays the cryptographic authentication to a real charging station, charging the attacker's vehicle while the victim is billed. The authors attribute it to the absence of station-identifying information in the Plug and Charge signature and to weaknesses in TLS certificate handling, and publish a proof-of-concept implementation together with mitigations (arXiv:2512.15966, v1 December 2025, v2 May 2026, accepted at USENIX VehicleSec 2026). That is a technical finding, not a legal one. The paper does not address who bears the cost of a session authorised this way, and no regulator has published an answer either.

Who is liable when the device pays wrongly

Card-scheme dispute handling assumes a cardholder who can be asked whether they recognise a charge. A machine cannot be asked that, and the entities behind it, a fleet operator, a charge point host, a device manufacturer, a SIM issuer, have not yet had a court or regulator settle how liability splits when an autonomous payment turns out to be wrong. Legal commentary on the point is consistent that contract and agency law has no special category for a machine counterparty: a device cannot hold rights or obligations in its own name, so every machine payment is legally an act attributed to the human or corporate principal that authorised it, whether that attribution was made clearly at design time or worked out afterwards in a dispute. Three practical questions are unresolved in the deployments we could source: what evidence proves a device was authorised to spend up to a given limit, what happens when a limit is bypassed by a security failure rather than a design flaw, and who absorbs the cost while that is worked out. Vendors describe "policy controls" and "accountable" transactions in their marketing; none of the material we reviewed describes a tested dispute process for a live deployment.

Whether the device operator is a payment service, and whose data it is

Two separate regulatory questions get run together in coverage of this space. The first is whether operating a machine-payment platform makes a company a payment service provider in its own right, triggering licensing, safeguarding and strong customer authentication obligations, or whether it can sit as a technical layer behind a licensed acquirer. The EU's answer is coming but has not landed. The Commission proposed a Payment Services Regulation and a third Payment Services Directive in 2023; Parliament and the Council reached a provisional political agreement on 27 November 2025, and compromise texts followed in April 2026, under which technical service providers that fail to support strong customer authentication within their role can be liable for the resulting financial damage. As of mid-September 2026 neither instrument has been formally adopted or published in the Official Journal, and the Regulation would apply eighteen months after entry into force. Any claim that a particular machine-payment operator is or is not caught by it is a forecast, not a fact.

The second question is data rather than money. The EU Data Act became applicable on 12 September 2025, giving the user of a connected device rights to the data that device generates and to have it shared with a third party of the user's choosing. A further tranche, requiring connected products placed on the EU market to be designed so that product data is directly accessible to the user by default, applies from 12 September 2026 and is now in force. A metering dispute over what a device measured, and a payment dispute over what it paid, will increasingly turn on data governed by that regulation, which is in force, sitting under payment rules that are not.

What the Paris programme heard on the infrastructure underneath

At Paris in June 2026, the panel "How Regulated Institutions Deploy on Canton" ran on the Taostats Stage on 3 June from 12:45 to 13:15. Yiannis Varelas moderated. The panellists were Heslin Kim, Luca Burlando and David Palmer of Pairpoint. The session concerned regulated institutions building on permissioned ledger infrastructure rather than machine payments specifically, and it did not resolve the liability or licensing questions above; nothing in the session record suggests it tried to.

The unresolved core

Device identity anchored in a SIM is deployed today and well understood. Wallet custody on constrained hardware borrows patterns solved elsewhere, discussed in our piece on key management, and mostly works when applied carefully. Micropayment settlement has workable technical answers whose dispute handling nobody has stress-tested at scale in public. Plug and Charge is the one mechanism that is both live and mandated, and it already has a documented attack against it with no public answer on liability. Everything past that, whether a device operator is a payment service, who owns the data a metering dispute turns on, and what a court does with a transaction that has no human counterparty to interrogate, is genuinely open. None of this is tax, legal or investment advice; where an institution is exposed to it, that is a question for its own counsel, not a blog post.