Complete Link Purchase

Complete a Link purchase

Link issues one-time-use payment credentials against a spend request — a single purchase the user has explicitly authorized for a stated amount and merchant.

You facilitate every spend approval through the request_virtual_card tool. It shows the user a card with the amount, the merchant, your reason, and the cart broken down line by line. Nothing is created unless they approve.

Everything after approval runs through the Link MCP server's tools. There is no CLI to install and no shell command to run.

Tools

Flow

• Step 1: Confirm an account is connected
• Step 2: Price the purchase and read the merchant
• Step 3: Ask the user to authorize the card
• Step 4: Poll, then retrieve the credential
• Step 5: Pay
• Step 6: Report the outcome

Step 1: Confirm an account is connected

Call get_userinfo. If it fails with an authorization error, the user has not connected Link in Cursor — say so and stop, rather than retrying.

Step 2: Price the purchase and read the merchant

Do this thoroughly before raising a card. The amount you ask for is the exact amount that gets charged, and a card issued for less than the cart total is declined at checkout. Changing your mind means asking the user all over again.

1. Open the merchant page and read how it accepts payment. A normal credit-card checkout form is the ordinary case, and the issued card works there.
2. Get the final total: items, tax, shipping, and any fees.
3. Know exactly what is being bought — size, colour, delivery option — so the line items you show the user match their cart.

If the merchant wants to verify who is calling, sign_web_bot_auth takes the URL and returns an HTTP Message Signatures block to attach as request headers. Reuse one block until its expires_at instead of signing per request.

If the endpoint is programmatic and answers HTTP 402 rather than serving a checkout form, it wants a machine payment rather than a card. Say so and stop; do not raise a card against it.

Step 3: Ask the user to authorize the card

Call request_virtual_card. Your turn ends when you call it.

Leave currency alone; only usd is supported.

Write title and context for the user, not for yourself. They appear on the approval card and on Link's own page, so do not narrate what you are doing and do not restate the amount — the card renders it. Give line items the labels the merchant's own cart uses, use a negative amountCents for a discount, and do not add a total row.

Then read the result:

• The card was raised — your turn is over. Wait to be resumed.
• A card is already pending — the user has an unanswered request open. Do not ask again. Use a message if you need to tell them something.
• It failed or was canceled — nothing was charged and nothing is pending. Tell the user plainly; ask before retrying.
• They denied it — that is final. Do not re-ask for the same purchase.

Step 4: Poll, then retrieve the credential

On approval you are resumed with the spend request id. The user is finishing authorization on Link's page in their browser.

Poll get_spend_request with that id on a widening delay: wait 5, then 15, then 30, then 60 seconds, checking once after each wait. Say nothing to the user while you poll. They are on Link's page, not reading the chat, and a running commentary is noise.

Once the status is approved, call get_spend_request again with include: ["card"] to get the number, CVC, expiry, billing address, and a valid_until timestamp after which the card stops working.

Only pass include at the moment you are about to pay. Without it the same tool returns status alone, which is what every other check wants.

If it comes back denied or expired, or is still pending after the last check, stop polling and say where it stands in one message. Do not create or ask for another card unless the user asks you to.