Vendor pluginLast verified 2026-09-11 · Reviewed by a person 2026-09-25
Stripe connects to commercetools through two Stripe-built Connect apps installed from the Connect marketplace in the Merchant Center: a Checkout app that plugs the Payment Element into commercetools Checkout, and a Composable app for custom storefronts that adds Express Checkout and Stripe Billing subscriptions. commercetools lists the Stripe connector as a third-party public connector; Stripe maintains both apps as MIT-licensed repositories with releases in late August 2026.1
UAT-Ops testing: Stripe's sandbox was verified by UAT-Ops on 2026-09-11 with the directory's card flow (6 passed) → evidence on the Stripe hub. The commercetools integration itself has not been run.
Sources checked: 15 claims from 5 sites, listed at the foot of the page.
Connects through Connect connectors (enabler + processor) installed from the Connect marketplace in the Merchant Center; the processor creates PaymentIntents and turns Stripe webhooks into commercetools Payment transactions. Biggest gotcha: Two apps, three marketplace names.
How it connects
Method
Connect connectors (enabler + processor) installed from the Connect marketplace in the Merchant Center; the processor creates PaymentIntents and turns Stripe webhooks into commercetools Payment transactions1
commercetools Checkout (Complete Checkout and Payment Only) via the Stripe Payment for Checkout app, Custom storefront via the Stripe Payment for Composable Commerce app (Payment Element and Express Checkout Element)1
PCI scope
SAQ A for most merchants: card data is entered in the gateway's own fields or page, so it never touches your server. The gateway or your acquirer can still require a different questionnaire.1
What works on this platform
Yes: a source confirms it on this integration. Not verified here: the gateway supports it, but no source confirms this integration exposes it. No: not available. A capability with no source either way is left off.
Both apps embed the Stripe Payment Element with deferred-intent, server-side confirmation; automatic and manual capture and refunds are mapped to the commercetools payment schema.
Express Checkout Element wallets (Apple Pay, Google Pay) are wrapped by the enabler; Express Checkout can update shipping methods and briefly unfreezes the cart to do so.
ACH Direct Debit is supported, including on subscriptions since v1.7.5; micro-deposit verification is not supported on subscriptions and late returns need manual reconciliation.
Composable app only: product variants carry the payment-app-subscription-information type and Stripe Billing creates a new commercetools order per renewal; the Checkout app does not cover this guide.
charge.refunded adds Refund transactions; multiple partial captures and refunds need the opt-in STRIPE_ENABLE_MULTI_OPERATIONS flag, manual capture and multicapture enabled on the Stripe account.
Stripe supports this; no source confirms it on this integration.
Capability status reflects the integration and documentation available at the time of verification, not necessarily every capability of the underlying gateway or platform.
Testing it
Create a Stripe sandbox and a restricted key with at least Refunds, PaymentIntents, Customer, CustomerSession, Webhook Endpoints and Subscriptions write permissions. In the Stripe Dashboard create a webhook endpoint with a placeholder URL and copy its endpoint id and whsec_ signing secret into STRIPE_WEBHOOK_ID and STRIPE_WEBHOOK_SIGNING_SECRET; the post-deploy script rewrites the endpoint URL to the deployed processor after install. Install the connector from the Connect marketplace in a commercetools trial Project with an API client holding manage_payments, manage_orders, view_sessions, view_api_clients, manage_checkout_payment_intents, introspect_oauth_tokens, manage_types and view_types. For local runs, docker compose starts a JWT server, enabler and processor and the Stripe CLI forwards events to the processor root path. Pay with Stripe test cards and assert that payment_intent.succeeded produces a Charge:Success transaction (automatic capture) or Authorization then Charge (manual), that charge.refunded adds Refund:Success, and that the Order Subscriber sets Order.paymentState.2
UAT-Ops runs integration flows like this against the real sandbox and keeps the evidence. Get one email when it opens.
Gotchas
Two apps, three marketplace names
Stripe ships two separate Connect apps: "Stripe Payment for Checkout" (repo stripe-commercetools-checkout-app, v1.5.0 on 2026-08-28) for commercetools Checkout, and "Stripe Payment for Composable Commerce" (stripe-commercetools-connect-app, v1.7.5 on 2026-08-26) for custom storefronts. The commercetools partner page uses different names again, including "Stripe Payments for Payment Hub". Subscriptions and the Express Checkout shipping-update flow are documented only for the Composable app, so pick the app before scoping the project.
Webhook URL is rewritten after deploy, but not every event is registered
You create the Stripe webhook endpoint with a placeholder URL before install; a post-deploy script then swaps in the deployed processor URL and enables its event list. Two things it does not do: register charge.updated, which multicapture needs (the handler exists but Stripe never sends it), or add invoice.paid and invoice.payment_failed, which subscriptions require. Check the endpoint's enabled events in the Dashboard after every redeploy.
STRIPE_PAYMENT_FLOW defaults to deferred. The README says not to set pi_first yet: opening the payment page creates a PaymentIntent and commercetools Payment without deterministic idempotency, a remount orphans the pair, an unfunded bank transfer reads as paid in full, and saved payment methods cannot be used. Yet EU customer_balance bank transfers on subscription carts require pi_first, and BLIK needs it, so those methods are effectively not production-ready through this connector.
Capture default differs between Stripe's docs and the Checkout app
Stripe's install pages state STRIPE_CAPTURE_METHOD defaults to automatic; the Checkout app README defaults it to automatic_async and lists manual as limited to certain payment methods. Multicapture (partial captures and multiple refunds) is opt-in via STRIPE_ENABLE_MULTI_OPERATIONS=true, only works with manual, and needs multicapture enabled on the Stripe account. Set the variable explicitly rather than trusting either default.
Async rails give you Pending transactions and clawbacks you must watch
Stablecoin and bank-transfer payments create Authorization: Pending transactions that finalize only on payment_intent.succeeded. ACH late returns (reversals up to about 60 days) are flagged as ach_late_return on the payment interface code, and bank-transfer clawbacks arrive only as customer_cash_balance_transaction.created. The README calls that the only in-connector signal that money was pulled back, so route it to an alert; nothing updates the commercetools order for you.
Last verified 2026-09-11 · Reviewed by a person 2026-09-25
Integration capabilities, requirements, pricing, availability, and vendor policies may change over time. UAT-Ops documents information based on the authoritative sources and testing available at the time of review.
Where newer information, testing, or vendor documentation materially changes a published claim, UAT-Ops may revise the page to reflect the most current verified information. Readers should confirm time-sensitive requirements with the relevant vendor before making production or purchasing decisions.