Pricing, coupons, and trials

Stripe subscriptions carry more than a customer and a price. RevBridge validates the billing details that can create revenue leakage or customer-visible billing surprises.

Pricing support

RevBridge supports recurring per-unit price shapes that can be matched or safely cloned, on any Stripe-documented interval (day, week, month, or year) with any interval count — quarterly and semi-annual subscriptions included. Explicit price tax_behavior (inclusive/exclusive) is preserved verbatim on clones; destination subscriptions always disable automatic tax, so it cannot change migrated invoice amounts.

Multi-item subscriptions are supported when every item independently passes the price rules and all items share one billing interval and one current_period_end. Each item's price is validated, cloned, or reused independently, per-item quantities and metadata are preserved, and the destination subscription is created with one item entry per source item. Items billing on different intervals or with divergent period ends are blocked because a single preserved billing anchor cannot reproduce their timing.

The dry-run can block unsupported cases such as metered prices, tiered pricing, custom unit amounts, transform quantity, multi-currency currency_options, undocumented intervals, or missing recurring price data.

An existing buyer-side price with the same ID is reused only when it is active and its economic terms and lookup key match the seller-side price. Inactive or mismatched buyer-side prices are treated as unsafe and RevBridge plans a fresh clone.

Price clones do not copy lookup_key or transfer_lookup_key. Those fields are often used by application code or operational pricing setup and can collide in the buyer account. RevBridge records source lineage metadata instead.

When several cloned source prices share the same source product, RevBridge creates one buyer-side product clone and attaches those prices to it. This keeps the destination catalog closer to the seller catalog instead of creating one product per cloned price. Product clones preserve safe Stripe-supported display and configuration fields: description, images, statement descriptor, tax code, unit label, URL, and metadata.

RevBridge treats only Stripe resource_missing responses as missing destination products, prices, or coupons. Permission, authentication, rate-limit, and network errors fail the run with the real Stripe error instead of being converted into clone actions.

Coupon support

RevBridge validates coupon shape before planning a buyer-side coupon clone.

Supported coupon matching considers duration, amount or percent off, currency, duration in months, and currency options. Unsupported coupon or discount structures are surfaced as blockers.

Customer-level discounts are blocked in v1 because Stripe can inherit them onto newly created subscriptions. RevBridge only migrates explicit subscription-level coupon discounts.

forever coupons are migrated when they are attached at the subscription level and match the supported shape. once coupons are migrated only when the latest finalized/open/paid source invoice does not show that same coupon as already applied. Stripe can represent consumed once-coupon state by removing the subscription discount or by keeping the discount visible while the latest invoice shows the coupon; RevBridge treats both as consumed and does not recreate it in the buyer account. If the latest invoice is void and shows a once coupon, RevBridge blocks the subscription because the invoice is not collectible and the intended future coupon state is ambiguous.

repeating coupons are carried by cloning a coupon whose duration_in_months equals the remaining whole months of the source discount window. Stripe starts a fresh repeating window when the coupon is applied at subscription create, so RevBridge computes which future renewal invoices the source window still discounts and picks the whole-month clone duration that discounts exactly the same renewals from the migration time. If no whole-month duration reproduces the same set — common on weekly and daily intervals — the subscription is blocked rather than approximated. A repeating window that ends before the next renewal migrates without the coupon, with a warning, because no future invoice would be discounted on either side.

Coupon clones copy discount economics and metadata. They do not copy source redemption limits such as max_redemptions, because those limits describe historical seller-account use and can prevent a valid buyer-account migration coupon from being applied.

An existing buyer-side coupon with the same ID is reused only when the economic terms and product scope match, and it has no buyer-side redemption gates such as max_redemptions or redeem_by. For repeating coupons the buyer-side duration_in_months must equal the computed remaining months, not the source's full duration. Gated or product-restricted buyer coupons are not safe for batch migration reuse because they can become invalid or apply to the wrong destination subscription.

Trial timing

Trialing subscriptions can use exact trial ends when supported. RevBridge mirrors Stripe's documented missing-payment-method trial end behavior values (cancel, create_invoice, or pause) when the exact trial is preserved. Unknown non-empty trial settings are blocked instead of silently dropped. If a trial is close to its end, RevBridge may need a trial anchor fallback to avoid invalid timing during execution.

Stripe Trial Offers are blocked in v1. Stripe's Trial Offer API is separate from legacy trial_end and attaches to subscription items; RevBridge does not recreate item-level trial-offer transitions.

The dry-run reports trial timing behavior through billing timing strategies and warnings. A true trial that can collect a future non-zero invoice and has no source payment method can be preserved with a warning only when the mapped destination customer has at least one card instrument for operator review. That approved action is marked explicitly so execution can distinguish an intentional unbound trial from stale dry-run data. Destination customers with zero cards are blocked when renewal can collect a non-zero amount because renewal would otherwise depend on collecting a payment method after migration. Provably non-collecting recurring subscriptions, such as price 0, quantity 0, or a supported forever coupon that fully discounts the subtotal, do not require payment binding, but RevBridge still binds a copied card when a unique match exists.

Renewal timing

For paid subscriptions, the migration plan preserves the renewal timestamp and avoids accidental immediate proration where supported. If the preserved timestamp is no longer in the future, dry-run blocks the subscription instead of letting Stripe reject execution later.

Scheduled cancellations are preserved: cancel_at_period_end is mirrored as a flag, and a custom cancel_at at or beyond the next renewal is mirrored as the exact timestamp on the destination subscription. A cancel_at earlier than the next renewal is blocked because the subscription has no future collectible invoice to migrate.

Subscriptions using billing_cycle_anchor_config are blocked in v1. Those configurations can encode calendar rules such as end-of-month billing; recreating only the next renewal timestamp can preserve the next invoice while changing later renewal cadence.

Subscriptions with latest_invoice.amount_remaining greater than zero are blocked. Pending invoice items on the source customer/source subscription or destination customer/recovered destination subscription are also blocked. RevBridge v1 does not migrate unpaid invoice balances, ad hoc invoice items, credits, or receivables; the operator should collect, delete, invoice, void, or manually reconcile those items before migration.

After each buyer-side subscription create, RevBridge inspects destination invoices before source cancellation. Any non-void, non-zero subscription_create invoice is unsafe, including a paid invoice, because the expected migration path creates no initial charge before the preserved renewal timestamp.

Destination subscriptions mirror the source billing mode (classic or flexible, including the flexible proration_discounts setting) and are always created with automatic_tax[enabled]=false. Under flexible mode a future-anchored creation produces no initial invoice at all; under classic it produces a zero-amount subscription_create invoice. Tax-bearing subscriptions are blocked in v1 rather than partially translated.

Destination subscriptions are also pinned to card payment method types so destination account invoice template settings cannot introduce unrelated payment methods into the migrated subscription.