Support Link card payments in processor-hosted checkout iframes

[fmhall]

Problem

OpenInstinct can prepare an affordable checkout, then abandon the purchase because the card fields live in processor-hosted iframes.

In the October 2 production run, the user authorized a surprise purchase for $10 or less, including delivery. The agent verified a $6.52 total including shipping and tax, then reported that the shop's payment fields were unsupported by the secure checkout bridge.

The recorded flow showed:

• The original checkout used Braintree hosted fields at assets.braintreegateway.com.
• The agent stopped before creating a Link spend request or calling fill_from_link.
• Subsequent attempts encountered PayPal- and Shopify-hosted card fields and hit the same restriction.
• No payment submission was recorded in those attempts.

Link's virtual cards support standard card checkout at non-Stripe merchants. The browser bridge needs to support these payment forms. Link documentation

Why it stops

fill_from_link retrieves an approved card inside application code, then passes it to the shared vault autofill injector with the merchant's origin as expectedOrigin.

The injector excludes controls in every frame whose origin differs from that merchant origin. The worker instructions and coordinator's Link purchase instructions explicitly prohibit cross-origin payment frames.

Changing the instructions alone would leave the injector restriction in place. Browser automation can interact with iframe fields through frame-specific locators. Playwright documentation

Proposed implementation

Expand fill_from_link into a secure card-form executor with checkout inspection and processor-hosted field support.

1. Inspect checkout before requesting approval. Identify the payment provider, frame origins, and card-field roles. Return non-secret compatibility information and an opaque checkout handle bound to the owned browser and current page. The coordinator should establish execution support before requesting Link approval.
2. Add provider rules shared across merchants. Start with Braintree, Shopify, PayPal card fields, and Stripe Elements. Handle card number, expiration, CVC, and cardholder name split across separate frames, alongside ordinary same-origin card forms. Avoid merchant-specific product IDs or merchant credentials.
3. Resolve and fill targets inside trusted application code. Accept the checkout handle and approved spend-request ID. Retrieve the credential inside fill_from_link, validate the approved top-level merchant and recognized processor frames, and fill only the resolved payment fields. Revalidate frame identity and origin immediately before injection. Evaluate native autofill and a trusted Playwright/CDP fill path against actual hosted forms.
4. Retain approval and secret protections. Check request ownership, approval status, merchant, amount, currency, and expiry. Keep card details outside model prompts, assignments, tool results, logs, and errors. Mask payment fields across frames for screenshots and account for browser recordings where enabled.
5. Preserve purchase completion semantics. Recheck the checkout and total before submission, submit once, and verify the merchant's order confirmation. Preserve the existing session on an uncertain result so recovery can inspect it without creating another spend request or blindly resubmitting.
6. Update coordinator and worker instructions together. Replace the blanket cross-origin blocker with inspection and execution of supported payment forms. Return a specific unsupported-provider or required-user-action result when the flow cannot proceed.

Keep browser execution under the declared browser-agent tool surface and retain the existing user/workspace ownership boundary.

Acceptance criteria

• Compatibility inspection runs before Link purchase approval and returns no credentials.
• Braintree, Shopify, PayPal card fields, and Stripe Elements have verified hosted-field support, including split fields and nested frames where applicable.
• Ordinary same-origin card forms continue to work.
• Unknown or unrelated frames cannot receive payment credentials; changed or navigated frames invalidate the target before injection.
• Merchant, amount, currency, ownership, approval, and expiry checks remain enforced.
• Card values are absent from model-visible outputs, logs, errors, screenshots, and enabled recordings.
• Real-browser cross-origin fixtures and processor test checkouts verify filling, validation, frame changes, and secret masking. Validation does not require live charges.
• Submission and uncertain-result recovery do not create duplicate purchase attempts; success requires merchant confirmation.
• Coordinator and worker instructions agree on supported execution and challenge handoff.
• pnpm check, pnpm build, and pnpm exec eve build pass.

Rollout and follow-ups

Start with Braintree, which blocked the observed purchase, then add Shopify, PayPal card fields, and Stripe Elements.

Add Stripe's native Link Pay Token path when the checkout advertises a supported agent interface. Shared Payment Tokens for programmatic sellers and paying through a PayPal account are separate execution paths. CAPTCHA and 3-D Secure challenges should use the existing user handoff behavior.

Related: #149 introduced the Link/browser autofill composition. #155 fixed the separate callback token parsing issue. #156 removed redundant Eve tool approvals while preserving Link purchase approval.