OurPay’s current hosted deployment collects payments through a central PayPal account. Product, customer, and subscription records can be recreated, but saved cards, PayPal billing agreements, processor tokens, and active mandates cannot normally be copied between unrelated processor accounts.
There is no public ourpay-migrate CLI. Do not give an unknown tool your Stripe or PayPal secret key. If a migration screen is not visible in your dashboard, the guided migration feature is not enabled for your organization.

​
What can move

​
Safe migration sequence

1

Export and map records

Export the source catalog, customers, subscriptions, invoices, refunds, and disputes. Define a stable mapping from each source ID to the OurPay external_id or metadata you will use.
2

Recreate the catalog in sandbox

Build products, prices, discounts, and benefits in the sandbox first. Create checkout sessions for both one-time and recurring products and verify the resulting orders and subscriptions.
3

Import customers without charging them

Create customer records through the dashboard or SDK. Importing a customer does not import a payment authorization and must not create historical revenue.
4

Move new sales

Send new customers to OurPay hosted checkout. Keep the old provider available for existing subscriptions while you reconcile both systems.
5

Re-consent existing subscribers

Give each subscriber a new OurPay checkout link. After the new PayPal subscription is active, schedule cancellation at the old provider so there is no double charge or coverage gap.
6

Reconcile before cutover

Compare source exports with OurPay customers, orders, subscriptions, refunds, and Seller Payable. Preserve the old platform’s records for accounting and support.

​
Guided Stripe migration

Some organizations may have an operator-enabled Settings → Migrations workflow for a guided Stripe migration. It validates a restricted Stripe key, assesses records, imports supported catalog data, and coordinates any eligible payment-method handoff and subscription cutover. Use that workflow only when it appears in your dashboard and the deployment operator has confirmed that the destination payment processor supports the transfer. The central PayPal deployment does not turn a Stripe card token into a PayPal billing agreement.

​
Before accepting live payments

  • Complete the organization’s seller verification and legal invoice details.
  • Confirm the production PayPal payment method is available on a one-time product.
  • Confirm subscription vaulting with a recurring product.
  • Verify signed order.paid, subscription.active, and subscription.revoked webhooks.
  • Keep bank payouts out of migration assumptions. The standard deployment has payouts disabled, and the gated PayPal-recipient rail is available only when the operator has explicitly enabled and validated it.
  • Before cutover, confirm that the legally liable production account is live in Numeral, every required registration is active, the filing calendar has no blocking actions, and imported customer addresses and tax IDs are complete. The Taxes dashboard reads this state directly from Numeral; an OurPay ledger total is not proof of registration, filing, or remittance.
See Sandbox, Hosted Checkout, and Migrate Away for the corresponding test and exit paths.