[hiroTamada]

Adds a page for server enrollment: pushing a card into a KERNEL wallet server to server through a single-use card_ingest URL. SDK 0.144.0 added enrollment: "server" to add_payment_method; the generated docs update (#746) mentions the option in one sentence but not how the card is posted, because that request goes to a URL outside the SDK.

The new page integrations/wallets/push-cards.mdx covers two ways to send the card:

• from a card issuer, posting single-use cards from its PCI-compliant backend
• from the customer's own card vault (VGS, Basis Theory, Skyflow, Evervault), sending the vault's aliases through the vault's outbound proxy so the raw card only exists between the two vaults

It covers:

• how the flow works, with a sequence diagram, and a warning never to post raw cards from servers that aren't allowed to handle them
• starting a server enrollment (TypeScript and Python)
• the request: required fields, formats and authentication, with direct and vault-proxy examples in TypeScript and Python
• the response, the error codes, and retry behavior
• paying with the pushed card: one purchase per push, the CVC window starting at the push, and what the card shows afterwards
• limiting what a pushed card can pay for, for issuer cards and for cards from a customer's vault

It's added to the Payments navigation after "Pay with multiple cards". Pages that #746 also edits are left untouched to avoid conflicts.

Behavior was checked against the API implementation and end-to-end pushes in production; the vault-proxy example wasn't run end to end. mint broken-links passes; the page wasn't previewed with mint dev.

---

Note

Low Risk
Documentation and navigation only; no application or API code changes.

Overview
Adds Push cards from your backend to the Payments docs and registers it in docs.json right after pay-with-multiple-cards.

The new integrations/wallets/push-cards.mdx guide documents server enrollment (add_payment_method with enrollment: "server"), the single-use card_ingest URL flow, and how to POST card data without KERNEL handling raw PAN/CVC. It covers issuer direct POSTs vs. third-party vault outbound-proxy pushes, request fields/auth, responses/errors/retries, paying with an immediately-ready purchase, single-use CVC behavior, and risk/limit guidance.

^{Reviewed by Cursor Bugbot for commit 7726bae. 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 9, 2026, 3:10 PM

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

[yummybomb]

LGTM. Verified the flow, request/response schemas, error codes, retry semantics, and CVC lifecycle against vault_card_ingest.go and the VGS/Evervault ingest backends.

One optional note on integrations/wallets/push-cards.mdx:287: funding_status: "unavailable" and 409 on authorize apply when a second purchase was created before the first one authorized; creating (upsert) a new purchase after the CVC is taken or expired fails upfront with 400 (cvc_unavailable).