Three launches on one day, and none of them was about the payment

Three things went live on 6 August and the trade press filed them under three different headings. A pay-by-bank tie-up. A children's allowance card. A buy-now-pay-later integration. I read all three today, decided only one of them was my beat, and was wrong about that.

They are the same story told three times. Each one moves money belonging to somebody who is not the party holding the credential at the moment of purchase. The payment itself is solved and has been for years. What shipped on Wednesday was the envelope around the payment: who set the limit, who approves this specific purchase, and what the accountable party can see and switch off afterwards. That is the actual unsolved problem in agentic commerce, and this week it got worked on by a bank-rails startup, by Google, and by a lender, none of whom were obviously in the same market.

Pay by bank turns up at the agent

Sionic, of Atlanta, and Agentix, of San Francisco, announced on 6 August that they are putting account-to-account payments behind an AI shopping agent [1].

The division of labour is clean. Sionic brings Bank Perks, which is a bank-branded digital representation of the payer's checking account that lives natively in the Apple or Google wallet, and its Instant Bank Pay service behind it. Agentix brings merchant inventory in a transaction-ready, machine-readable form through its Agent to Agent service, which is what the agent actually shops against [2].

Two details in there are worth more than the announcement around them. The payer approves the purchase before payment is submitted, and a fraud detection service Sionic built with Google screens the transaction within milliseconds before it reaches the rails [2]. So the agent discovers, assembles and queues. It does not spend while you sleep.

That is a much smaller claim than this category normally makes, and it is the reason I believe this one. An agent with discretionary spend is a demo. An agent that builds a basket and hands it back for a tap is a product, because the liability question has an answer.

The commercials are ordinary and disclosed: free to the consumer, and the merchant pays to receive an instant cash deposit [2]. Pay by bank has always been a merchant-economics story wearing a consumer-convenience coat. Putting an agent on top does not change who is paying for it, and I would rather see that stated plainly than buried.

Google shipped an agent credential and called it pocket money

Marqeta said on 6 August that it has expanded its work with Google so that under-18s can receive and spend an allowance inside Google Wallet [3]. Marqeta supplies the card issuing, the tokenisation, the programme management and the real-time spend controls. Parents get transaction history, notifications, daily limits, and the ability to lock and unlock the balance. Supervised children can tap to pay on an NFC Android phone or a Wear OS watch without holding a conventional bank account [3] [4].

I skimmed that release, thought "family finance, not my beat", and moved on. Then I read the feature list again with an agent in mind rather than a child.

A credential scoped to a spender who is not the account holder. A spending limit set by the accountable party and enforced in real time rather than reconciled later. A kill switch the accountable party can hit from their own device. A complete transaction record flowing back to whoever carries the liability. Strip the word "kid" out of that paragraph and it is the specification every agent payments consortium has been arguing about, and Google has it in production because the constraint problem is genuinely easier when the delegate cannot negotiate with the limit.

That is not me claiming Google built this for agents. It plainly built it for parents. The point is narrower and more useful: the hard part of delegated spending is the control plane, not the rail, and the control plane is now shipping in consumer products while the standards bodies are still drafting.

Klarna removed the integration rather than adding a feature

Klarna's first United States integration with J.P. Morgan Payments went live on 6 August, putting pay in full, interest-free instalments and longer-term financing in front of merchants on the bank's Commerce Platform without those merchants building anything [5] [6].

The figures both sides gave: J.P. Morgan Payments handles $2.6tn of merchant transactions a year and serves more than a million retailers including Uber, H&M, Saks, Sephora and Nike; Klarna has 119 million active users and processes 3.4 million transactions a day [5]. David Sykes, Klarna's chief commercial officer, said the collaboration moves "from ambition to impact"; Michael Lozanoff, who runs merchant services at J.P. Morgan Payments, framed it as removing an implementation barrier [5]. Those are the sentences everybody writes on go-live day.

The mechanism underneath them is not a product launch at all. Klarna built no new consumer feature here. It deleted an integration project from a million merchant backlogs, which is a distribution move, and distribution is the only thing that has ever decided a payment method. One caveat I will not skip: the "more than one in four Americans" conversion statistic in the announcement is cited to industry data without a named study [5]. Treat it as a sales figure, because that is what it is.

Read from the rails

Here is what I would take out of Wednesday if I were building.

The three launches describe one architecture from three angles. Sionic put the approval step in front of the agent. Marqeta and Google put the limits, the visibility and the kill switch around the delegate. Klarna proved the distribution point, which is that a payment method arrives through infrastructure the merchant already runs, never through a merchant integration project. Nobody involved was solving agentic commerce. Two of them were not even in the room for it.

If you are specifying an agent payments credential this quarter, read the Marqeta and Google feature list before you read another protocol draft. It is the most complete plain-English statement of what a delegated credential needs that anybody published this week, and it happens to be written about pocket money. Scoped token, real-time limit, instant revocation, full audit trail to the accountable party. Four things. Every one of them in a shipped consumer product rather than a specification.

And check what the delegate can do without asking. That single question separates the three announcements above from most of what this category ships, and it is the one a compliance team will ask first. Sionic's answer is "discover and assemble, then wait for a tap". That answer is boring, and boring is what gets deployed inside a bank.

One smaller item from Thursday belongs in the same frame. Repay launched REPAY Voice, an AI voice-response system that takes consumers through bill payments by speaking to them [7]. It is a modest launch and I am not going to inflate it. But it is the same unbundling: the interface to the payment is coming apart from the payment, and the card sits underneath all of it, unchanged and increasingly invisible.

I have spent enough years watching payment products fail for reasons that had nothing to do with payments. They fail because somebody could not answer who authorised this, or could not turn it off fast enough when the answer turned out to be nobody. Three teams answered that question on the same Wednesday, in three different markets, without coordinating. That is usually the sign that a problem has stopped being interesting and started being infrastructure.

The card was never the hard part. The hard part is the sentence that says who is allowed to spend it, how much, and how fast you can stop them.