Bind Link Pay Tokens to the checkout merchant - #243
Conversation
nvp-stripe
changed the title
raubrey-stripe
left a comment
raubrey-stripe
left a comment
There was a problem hiding this comment.
Feels like we might benefit from splitting out link_pay_token into its own credential-type, if you want to do that as a follow up or we have some reason not to let's chat!
| ```bash | ||
| link-cli spend-request create \ | ||
| --payment-method-id csmrpd_xxx \ | ||
| --execution-method link_pay_token \ |
There was a problem hiding this comment.
Feels like we should consider transitioning to the --credential-type link_pay_token?
There was a problem hiding this comment.
yeah I agree a link_pay_token credential type flow would be cleaner longer term. But let's focus on that in a follow-up?
| ``` | ||
|
|
||
| LPT requests use the default `card` credential type and do not support | ||
| `--test`, `--network-id`, or `shared_payment_token`. After approval, retrieve |
There was a problem hiding this comment.
no --test :/ is support for this incoming?
There was a problem hiding this comment.
yes, @sylwang-stripe is working on broader support in this area.
raubrey-stripe
left a comment
raubrey-stripe
left a comment
There was a problem hiding this comment.
Yeah I'm good to move forward with this for now!
5 participants
r? @sylwang-stripe @kreese-stripe @lkong-stripe
Summary
This change adds the Link CLI side of merchant bound Link Pay Token SpendRequests. It lets an agent read the merchant account ID exposed by the Stripe checkout's AI agent steering block and send it when creating the
SpendRequest.
execution_method: "link_pay_token"andmerchant_account_idfields to the SDK and/spend_requestsrequest.--execution-method link_pay_tokenand--merchant-account-id acct_...to the CLI and MCP schemas.shared_payment_token,network_id, test mode, and agent-provided merchant name or URL.data-stripe-merchant-account, create the bound SpendRequest, wait for approval, then retrieve and inject the LPT.Motivation
LPTs should be tied to the merchant the consumer sees and approves, rather than trusting the first checkout surface that presents the token. The CLI now supplies the checkout-derived merchant account ID so the backend can resolve
the canonical merchant identity, show it in the approval experience, and bind the LPT to that merchant at exchange time.