STRIPE INTEGRATION
Checkout Sessions Migration
Local currency display and local payment methods require Adaptive Pricing. Adaptive Pricing requires Checkout Sessions. But the integration path — and whether the stated objective is even achievable — depends on three unanswered questions. This page maps what we know, what we don't, and what determines whether this is weeks or quarters.
Enable local currency display and local payment methods across current markets. The driver is expanding payment acceptance — particularly in markets like India where UPI requires presenting prices in INR.
Show prices in the customer's local currency. Stripe handles conversion and presentation via Adaptive Pricing.
Accept region-specific methods — UPI, iDEAL, Bancontact, etc. Some require local currency presentation as a prerequisite.
Stripe's own documentation states: "For cross-border subscriptions, Adaptive Pricing supports only card payments, Link, Apple Pay, and Google Pay." UPI, iDEAL, Bancontact, and most local payment methods are NOT supported for subscriptions through Adaptive Pricing. Since Cloudflare's billing is overwhelmingly subscription-based, the primary stated objective — enabling UPI for Indian customers — may not be achievable through this path at all. This must be confirmed with Stripe before any work begins.
Adaptive Pricing is simpler than the dependency chain suggests. The core requirement is Checkout Sessions. Everything else — the API upgrade, the Meters migration — depends on which Checkout Session mode you use.
Cloudflare uses Elements with the Payment Intents API (PaymentElement in Unified Checkout, CardElement in Multisku). Stripe explicitly excludes this integration pattern from Adaptive Pricing.
Switch to Checkout Sessions (any mode). Adaptive Pricing is then a Dashboard toggle. Embedded modes also need one code flag and a Currency Selector.
Subscription modifications (upgrade, downgrade, cancel) stay on the Subscription API. Checkout Sessions only handle creation. Reconciliation, invoicing, and webhooks remain on the current integration.
The depth of the dependency chain depends entirely on which Checkout Session mode Cloudflare adopts. Three options, three very different effort profiles.
| Hosted | Embedded | Custom (EwCS) | |
|---|---|---|---|
| ui_mode | (default) | embedded_page | custom / elements |
| UX | Redirect to stripe.com | Stripe form in our page | Full UI control |
| Dashboard viable? | ❌ Redirect mid-upgrade | ⚠️ Viable if form fits | ✅ Best fit |
| API version | Pre-basil ✅ | Needs verification | Basil required |
| Meters migration | No | No (if pre-basil) | Yes — full chain |
| AP enablement | Dashboard toggle | Dashboard toggle + code flag | Code + Currency Selector + toggle |
| Dependency depth | 2 links | 2–3 links | 5 links (full chain) |
| Effort | Weeks | Weeks to months | Multi-quarter |
The 5-link dependency chain that was communicated by Stripe (Wisam) assumes Custom/EwCS mode — full UI control, which requires 2025-03-31.basil, which requires migrating Usage Records to Meters. If Embedded mode is viable for the dashboard UX, the API upgrade and Meters migration may be unnecessary. Hosted mode is likely a non-starter for a dashboard checkout flow.
This chain applies only if Custom/EwCS mode is required. Each layer depends on the one below it. If Embedded mode is viable, skip this section.
Communicated by Wisam (Stripe Billing Product lead) during partnership discussions, late March 2026. This chain assumes Custom/EwCS mode is required.
Regardless of which integration path is chosen, three constraints apply.
Checkout Sessions support subscription creation only — not modification. Our checkout flow handles create, upgrade, and downgrade through a single path and does not know ahead of time which operation is needed. The integration must split into two parallel pipelines: Checkout Sessions for new subscriptions, Subscription API for modifications. This is a permanent constraint of the Checkout Sessions model.
Adaptive Pricing does not support custom payment methods. PayPal is implemented via the Braintree adapter and stored as custom PM metadata — not as a native Stripe PaymentMethod. Any non-native-Stripe processor faces the same exclusion. However, Stripe-native PayPal IS listed as an Adaptive Pricing-supported PM — switching from Braintree to Stripe-native PayPal could resolve this for PayPal specifically. The same question applies to Checkout.com if it is integrated as a non-Stripe processor.
USD is hardcoded throughout subscriptions-api, webhooks, usage metering, BigQuery, reconciliation, and 52 Stripe metadata fields. Adaptive Pricing handles presentation-layer currency conversion — Stripe converts and settles in USD — but any internal system that interprets amounts must understand presentment vs. settlement currency.
Six questions. The first three determine whether this is weeks, quarters, or impossible.
| Question | Owner | Impact |
|---|---|---|
| Does Adaptive Pricing support UPI on cross-border subscriptions? | Stripe (Wisam) | If no, the primary objective is unachievable through this path |
| Can embedded Checkout Sessions work within the dashboard UX? | Frontend | If yes, the chain collapses from 5 links to 2 — no API upgrade, no Meters migration |
| Does embedded mode + AP work on Cloudflare's current Stripe API version? | Billing + Stripe | If yes, zero backend prerequisites |
| Can Cloudflare switch PayPal from Braintree to Stripe-native? | Billing | If yes, the PayPal exclusion dissolves |
| Is Checkout.com integrated as a non-Stripe processor like PayPal/Braintree? | Billing | If yes, another PM excluded from Adaptive Pricing |
| Does the checkout create/modify split work with our product catalog? | Frontend + Billing | Shapes all integration paths — may require rearchitecting operation detection |
Three answers — UPI on subscriptions, embedded mode viability, and API version requirements — could collapse a multi-quarter initiative into weeks of integration. Or they could confirm the stated goal was never achievable through this path. Ask before building.