[hiroTamada]

Summary

The AgentCard page told readers to expect amount_authority: 'display_only' and charged_kind from every checkout. In practice:

• AgentCard reports amount_authority as processor, agent, page, or none. display_only appears only on authorizations Kernel recovers itself.
• When the held request is a tokenization request (for example a Stripe card token), AgentCard returns the token to the page and never sees the charge. Those checkouts report agent and have no amount_verified or charged_* fields, even when the payment succeeds.
• For Stripe, the success signal is an item event that Kernel records when the page confirms the payment: payment_succeeded, with provider_status / provider_payment_status. Those events weren't documented.

Changes:

• Rewrites the authorization field table with every amount_authority value and states when the charged_* fields are absent.
• Adds a "Checkout item events" section listing the checkout events, which ones are Stripe-only, and the data fields they can carry.
• Reconciliation guidance now names payment_succeeded as supporting evidence.

Matches the spec change in kernel/kernel#5457.

Not previewed with mintlify dev.

---

Note

Low Risk
Documentation-only changes to the AgentCard MDX page with no runtime or API behavior impact.

Overview
Updates the AgentCard integration docs so authorization and reconciliation guidance match real checkout behavior instead of assuming every flow exposes display_only and charge fields.

The authorization field table now documents all amount_authority values (processor, agent, page, none, legacy display_only), when amount_verified and charged_* are absent, and what charged_kind means for token-only flows.

New prose explains that tokenization holds (e.g. Stripe card tokens) often show amount_authority: 'agent' with no charge proof on the item—the merchant charges later, so integrators should lean on item events and merchant orders.

A Checkout item events section lists processor-facing events (payment_succeeded, declines, credential_tokenized, payment_unknown, etc.), notes Stripe-specific follow-up payment observation, and documents common data fields. Reconciliation text now calls out payment_succeeded as supporting evidence alongside authorization and replay fields.

^{Reviewed by Cursor Bugbot for commit 5614a6e. Bugbot is set up for automated code reviews on this repo. Configure here.}

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
Kernel	🟢 Ready	View Preview	Nov 12, 2026, 7:57 PM

💡 Tip: Enable Automations to automatically generate PRs for you.

[yummybomb]

LGTM with one fix:

• "other processors only record checkout_response_replayed" isn't right. The held request's response is recorded for every processor: prod has credential_tokenized alongside checkout_response_replayed on Shopify and Square, and payment_unknown on Razorpay. Only the follow-up payment correlation is Stripe-only. Maybe: "for other processors, events cover only the held request's response; the follow-up payment isn't observed."

Optional nits:

• display_only: every stored value came from AgentCard's create response (all have a provider approval URL, Sep 4–8), not Kernel recovery (same note as kernel/kernel#5457).
• The table could say it lists processor events only; checkout_authorization_* and checkout_preparation_* events also appear on the item.

[hiroTamada]

Thanks, fixed in 5614a6e:

• The events section now says every processor records an event for the held request's response (for example credential_tokenized or payment_unknown) alongside checkout_response_replayed. Only the follow-up payment correlation is Stripe-only. I checked this in code: attachHold sets the audit context for every processor, and ObserveResponse classifies the replayed response.
• Took both nits. display_only is now described as a legacy provider value that Kernel also sets on recovery. The table now says it lists processor events only, and that checkout_authorization_* and checkout_preparation_* events also appear on the item.

kernel/kernel#5457 is already in the merge queue, so its spec description still has the old display_only wording. I'll fix that in a small follow-up after it merges.