Agents on Linq can already collect money. Starting today, they can spend it too.
We've partnered with Agentcard, the Y Combinator-backed company building card issuing for agent-first startups, to give every agent on Linq the ability to pay on a user's behalf. Ask your agent to book the flight, order the sushi, or renew the subscription, and it can now finish the job right in the thread, with a single-use virtual card scoped to that exact purchase. Card credentials never touch Linq's infrastructure or yours.
"The best checkout experience we could imagine was actually no checkout experience. The agent should be able to safely and seamlessly checkout on your behalf. That’s what we’re enabling with Agentcard." said Elliott Potter, CEO and co-founder of Linq.
"We built Agentcard so agents could spend safely: one card per purchase, scoped to the merchant and the amount, expired the moment it clears," said Karen Serfaty, CEO and co-founder of Agentcard. "Linq agents already live where users actually are, in their messages. Putting purchasing power in those threads is the most natural home for agentic commerce we've seen."
Here's how activation works, what a payment looks like end to end, and where card data actually lives.
How activation works
You enable Agentcard from your Linq dashboard. A hosted onboarding flow connects the provider to your organization:
POST /v3/payments/providers/agentcard/connect
Starts hosted onboarding and links Agentcard to your org.
From there, your agent connects each customer by their handle, the phone number or email you already message them at:
POST /v3/payments/handles/{handle}/connect
Initiates a card connection for one customer.
The customer completes a one-time verification directly in the messaging thread. When they finish, a connection.created webhook confirms the handle is ready to pay. No app download, no new account, no card form.
What a payment looks like
To pay, the agent creates a payment with the handle, amount, currency, and merchant details, with an Idempotency-Key header so retries are safe. The response status tells you where things stand:
{ "status": "awaiting_user_action", "url": "https://..." }
The user has a step to complete; the agent sends them the URL in the thread.
A payment moves through three states. needs_connection means the customer has not linked a card yet. awaiting_user_action means a verification or approval step is pending, and the response includes a shareable URL. ready means the agent can retrieve credentials and check out:
GET /v3/payments/{paymentId}/credentials
Returns a short-lived token and fetch URL for retrieving card details directly from the provider.
Credentials are display-and-use only. Linq never stores them, and the single-use card they unlock is scoped to that purchase.
When things go wrong
Failure cases are explicit rather than silent. A payment against an unlinked handle returns needs_connection instead of failing downstream. Declined authorizations arrive as webhooks, as do successful ones, so both sides have a record. Connections can be revoked at any time, which fires a connection.revoked webhook. Payments can be canceled, credential handoffs expire quickly, and Agentcard monitors spend patterns and blocks unusual activity on its side.
Get started
Agentcard on Linq is available today. Linq customers get Agentcard's Light plan for free, with up to 200 cardholders and unlimited cards included. Enable it via the toggle on your Linq admin dashboard, then see the Agentcard docs for the full API reference. Your agent already knows what your users want. Now it can buy it.
Three principles guided the integration:
- Single-use by default. Every purchase runs on a virtual card that works once, for that transaction, and then expires.
- The user stays in the loop. Connections require one-time verification in the thread, and every payment is scoped to a specific merchant and amount.
- Credentials stay out of your stack. Card details come from the provider through a short-lived handoff and are never stored by Linq or by you.
