From 36aa67cf406278a7449c9f08cdc995b649548cf5 Mon Sep 17 00:00:00 2001 From: hiroTamada <88675973+hiroTamada@users.noreply.github.com> Date: Thu, 17 Sep 2026 16:54:16 +0000 Subject: [PATCH 1/4] Document supported AgentCard processors --- integrations/wallets/agentcard.mdx | 32 ++++++++++++++++++------------ 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/integrations/wallets/agentcard.mdx b/integrations/wallets/agentcard.mdx index f8a62bf..ae0759c 100644 --- a/integrations/wallets/agentcard.mdx +++ b/integrations/wallets/agentcard.mdx @@ -13,22 +13,28 @@ agentcard is the wallet provider, not the merchant's payment processor. end-to-e agentcard's alias handoff uses native adapters for these checkout request formats: -| merchant processor or platform | recognized HTTPS `POST` request formats | -| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| stripe | form requests to `api.stripe.com/v1/payment_methods`, `/v1/tokens`, `/v1/payment_intents/{id}/confirm`, and `/v1/payment_pages/{id}/confirm` | -| shopify | JSON card-session requests to `checkout.pci.shopifyinc.com/sessions` and `deposit..shopifycs.com/sessions` | -| square | JSON card-nonce requests to `pci-connect.squareup.com/v2/card-nonce` and `pci-connect.squareupsandbox.com/v2/card-nonce` | -| recurly | form token requests to `api.recurly.com/js/v1/token` and `api.eu.recurly.com/js/v1/token` | -| razorpay | form card-payment requests to `api.razorpay.com/v1/payments/create/ajax` and `api.razorpay.com/v1/standard_checkout/payments/create/ajax` | +| merchant processor or platform | flow | recognized HTTPS `POST` request formats | +| ------------------------------ | ---- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| stripe | ordinary approval hold | form requests to `api.stripe.com/v1/payment_methods`, `/v1/tokens`, `/v1/payment_intents/{id}/confirm`, and `/v1/payment_pages/{id}/confirm` | +| shopify | ordinary approval hold | JSON card-session requests to `checkout.pci.shopifyinc.com/sessions` and `deposit..shopifycs.com/sessions` | +| square | ordinary approval hold or prepared single-use checkout | JSON card-nonce requests to `pci-connect.squareup.com/v2/card-nonce` and `pci-connect.squareupsandbox.com/v2/card-nonce` | +| recurly | ordinary approval hold | form token requests to `api.recurly.com/js/v1/token` and `api.eu.recurly.com/js/v1/token` | +| razorpay | ordinary approval hold; reconcile payment status with the merchant | form card-payment requests to `api.razorpay.com/v1/payments/create/ajax` and `api.razorpay.com/v1/standard_checkout/payments/create/ajax` | +| braintree | prepared single-use checkout only | GraphQL guest tokenization requests to `payments.braintree-api.com/graphql` and `payments.sandbox.braintree-api.com/graphql` | +| worldpay | prepared single-use checkout only | Access Checkout card-session requests to `access.worldpay.com/sessions/card` and `try.access.worldpay.com/sessions/card` | +| bambora | prepared single-use checkout only | card-token requests to `api.na.bambora.com/scripts/tokenization/tokens` and `api.bam.shift4api.net/scripts/tokenization/tokens` | +| mercado pago | prepared single-use checkout only | fresh-card token requests to `api.mercadopago.com/v1/card_tokens` | for example, an attached browser can enter agentcard aliases into a shopify checkout. shopify remains the merchant platform; agentcard supplies the credential and approval flow. -the outgoing request must contain the complete alias set and match the adapter's -expected HTTPS method, host, path, content type, and card-field layout. these -adapters are enabled today, but non-Stripe coverage still needs broader -validation against real processor SDKs and hosted checkouts. encrypted payloads, -different request layouts, and unrecognized processor endpoints pass through -without native handoff. +for ordinary approval holds, the outgoing request must contain the complete alias +set and match the adapter's expected HTTPS method, host, path, content type, and +card-field layout. prepared checkout rows require the card item to complete +`prepare_checkout` before native submission; Braintree, Worldpay, Bambora and +Mercado Pago don't support the ordinary hold flow. Square supports either flow, +depending on whether prepared checkout is enabled. encrypted payloads, different +request layouts, and unrecognized processor endpoints pass through without native +handoff. KERNEL's native handoff aims to support the same processors supported by agentcard's direct SDK. email From 7a17f9811dce82cd946f19577099110d8a355204 Mon Sep 17 00:00:00 2001 From: hiroTamada <88675973+hiroTamada@users.noreply.github.com> Date: Thu, 17 Sep 2026 16:55:53 +0000 Subject: [PATCH 2/4] Clarify Square checkout flow --- integrations/wallets/agentcard.mdx | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/integrations/wallets/agentcard.mdx b/integrations/wallets/agentcard.mdx index ae0759c..c105f8a 100644 --- a/integrations/wallets/agentcard.mdx +++ b/integrations/wallets/agentcard.mdx @@ -31,10 +31,11 @@ for ordinary approval holds, the outgoing request must contain the complete alia set and match the adapter's expected HTTPS method, host, path, content type, and card-field layout. prepared checkout rows require the card item to complete `prepare_checkout` before native submission; Braintree, Worldpay, Bambora and -Mercado Pago don't support the ordinary hold flow. Square supports either flow, -depending on whether prepared checkout is enabled. encrypted payloads, different -request layouts, and unrecognized processor endpoints pass through without native -handoff. +Mercado Pago don't support the ordinary hold flow. Square uses the ordinary hold +flow by default; when prepared checkout is enabled, new Square checkouts must use +`prepare_checkout`, and an unprepared request is rejected rather than falling back +to an ordinary hold. encrypted payloads, different request layouts, and +unrecognized processor endpoints pass through without native handoff. KERNEL's native handoff aims to support the same processors supported by agentcard's direct SDK. email From 1f2203f0c6c27459e5ebe21dc70a34735499d665 Mon Sep 17 00:00:00 2001 From: hiroTamada <88675973+hiroTamada@users.noreply.github.com> Date: Thu, 17 Sep 2026 16:57:04 +0000 Subject: [PATCH 3/4] Name prepared checkout feature flag --- integrations/wallets/agentcard.mdx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/integrations/wallets/agentcard.mdx b/integrations/wallets/agentcard.mdx index c105f8a..cb1021d 100644 --- a/integrations/wallets/agentcard.mdx +++ b/integrations/wallets/agentcard.mdx @@ -34,7 +34,8 @@ card-field layout. prepared checkout rows require the card item to complete Mercado Pago don't support the ordinary hold flow. Square uses the ordinary hold flow by default; when prepared checkout is enabled, new Square checkouts must use `prepare_checkout`, and an unprepared request is rejected rather than falling back -to an ordinary hold. encrypted payloads, different request layouts, and +to an ordinary hold. deployments control this behavior with +`AGENTCARD_PREPARED_CHECKOUT_ENABLED`. encrypted payloads, different request layouts, and unrecognized processor endpoints pass through without native handoff. KERNEL's native handoff aims to From 76c8723498a44b7e2dc35b389e00e8827f85ee78 Mon Sep 17 00:00:00 2001 From: hiroTamada <88675973+hiroTamada@users.noreply.github.com> Date: Thu, 17 Sep 2026 16:58:16 +0000 Subject: [PATCH 4/4] Keep internal flag out of public docs --- integrations/wallets/agentcard.mdx | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/integrations/wallets/agentcard.mdx b/integrations/wallets/agentcard.mdx index cb1021d..9c50e37 100644 --- a/integrations/wallets/agentcard.mdx +++ b/integrations/wallets/agentcard.mdx @@ -17,7 +17,7 @@ agentcard's alias handoff uses native adapters for these checkout request format | ------------------------------ | ---- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | stripe | ordinary approval hold | form requests to `api.stripe.com/v1/payment_methods`, `/v1/tokens`, `/v1/payment_intents/{id}/confirm`, and `/v1/payment_pages/{id}/confirm` | | shopify | ordinary approval hold | JSON card-session requests to `checkout.pci.shopifyinc.com/sessions` and `deposit..shopifycs.com/sessions` | -| square | ordinary approval hold or prepared single-use checkout | JSON card-nonce requests to `pci-connect.squareup.com/v2/card-nonce` and `pci-connect.squareupsandbox.com/v2/card-nonce` | +| square | prepared single-use checkout (currently enabled) | JSON card-nonce requests to `pci-connect.squareup.com/v2/card-nonce` and `pci-connect.squareupsandbox.com/v2/card-nonce` | | recurly | ordinary approval hold | form token requests to `api.recurly.com/js/v1/token` and `api.eu.recurly.com/js/v1/token` | | razorpay | ordinary approval hold; reconcile payment status with the merchant | form card-payment requests to `api.razorpay.com/v1/payments/create/ajax` and `api.razorpay.com/v1/standard_checkout/payments/create/ajax` | | braintree | prepared single-use checkout only | GraphQL guest tokenization requests to `payments.braintree-api.com/graphql` and `payments.sandbox.braintree-api.com/graphql` | @@ -31,11 +31,12 @@ for ordinary approval holds, the outgoing request must contain the complete alia set and match the adapter's expected HTTPS method, host, path, content type, and card-field layout. prepared checkout rows require the card item to complete `prepare_checkout` before native submission; Braintree, Worldpay, Bambora and -Mercado Pago don't support the ordinary hold flow. Square uses the ordinary hold -flow by default; when prepared checkout is enabled, new Square checkouts must use +Mercado Pago don't support the ordinary hold flow. The current KERNEL deployment +has prepared checkout enabled, so new Square checkouts must use `prepare_checkout`, and an unprepared request is rejected rather than falling back -to an ordinary hold. deployments control this behavior with -`AGENTCARD_PREPARED_CHECKOUT_ENABLED`. encrypted payloads, different request layouts, and +to an ordinary hold. The ordinary Square hold flow is retained for compatibility +with deployments that haven't enabled prepared checkout. Encrypted payloads, +different request layouts, and unrecognized processor endpoints pass through without native handoff. KERNEL's native handoff aims to