Skip to main content
Checkout is one of the highest-trust moments in migration. The subscriber is being asked to move billing rails. The surface needs to feel like the app they already trust.

​
What checkout carries

  • Customer brand
  • Product and plan context
  • Subscriber identity
  • Payment rail
  • Offer framing
  • Price parity logic
  • Help and support links
  • Confirmation and next steps

​
Stripe checkout path

Stripe is the default rail. The checkout path is configured around the customer’s Stripe setup and the agreed subscriber experience.

​
Apple Pay domain verification

Apple Pay on the web requires domain verification for the domain that serves checkout. If checkout runs on a branded subdomain, that subdomain needs to be verified for Apple Pay. If checkout is mounted through a reverse proxy or path on the primary domain, the customer and Recurr confirm how the Apple Pay verification file is served and how the payment rail sees the checkout domain. This is checked before a live cohort is contacted so wallet-first checkout works when the subscriber arrives.

​
Paddle checkout path

Paddle can be scoped where merchant-of-record coverage or existing Paddle setup makes it the right rail. Paddle support is early access.

​
Domain pattern

Checkout can usually run on a branded subdomain such as checkout.customer.com or billing.customer.com. Where a customer needs checkout under the primary domain, such as customer.com/checkout, that path is scoped as a reverse-proxy or edge-routing pattern and requires customer-side web infrastructure.

​
Why brand matters

Migration conversion depends on trust. A branded, clear, low-friction checkout gives subscribers confidence that the billing update belongs to the app they already use.