What shipped
The migration tool imports a merchant’s existing card-subscriber list from any UK card processor into Fluxa and runs the card-update flow under the merchant’s domain. Three steps, end to end.
- Export · pull the subscriber list from the current processor as CSV. The migration tool accepts the standard exports from Stripe, Square, GoCardless, Adyen, Worldpay and Paddle out of the box; bespoke schemas are mapped through a column-mapping UI on first run.
- Validate · the import is dry-run validated against the Fluxa schema with row-level error reporting. The merchant sees every row that will fail before any side effects fire. Common failures (missing email, malformed currency, expired card token) are flagged with a remediation suggestion.
- Send · once the merchant approves the validated list, branded re-tokenise emails go out from the merchant’s own domain. Each cardholder enters card details once on a hosted checkout. The new card token is bound to the existing subscription record in Fluxa.
Why it matters
The biggest single blocker to switching card processors is the subscriber book. A SaaS with five thousand customers on Stripe and rolling subscriptions cannot ask cardholders to re-enter card details one by one without churning a meaningful slice of the base. Most teams assume that means the subscriber book is locked in.
It is not. A migration can be run on branded re-tokenise emails sent from the merchant’s domain, with each cardholder re-entering card details once on a hosted checkout. The cardholder sees a single card-input form, branded as the merchant. For the merchant, it is three steps and a row-level validation pass.
For founding-cohort merchants, the rate difference between current effective processing costs and 1.8% flat pays back the migration effort inside the first quarter on most B2B SaaS volume profiles.
The detail
Behind the three-step UI sits a stateful migration engine. The architecture choices that matter:
- Schema validation
- Every row is checked against the target schema with row-level error reporting before any side effects fire. The dry run reports total rows, valid rows, invalid rows by error class, and the specific row indices for each error.
- Idempotency
- Each migration run has a unique key. Replays of the same run do not double-process subscribers or send duplicate emails. If the run is interrupted halfway, the next attempt picks up at the first un-processed row.
- Email branding
- SPF and DKIM records are configured for the merchant’s domain at onboarding. Cardholder re-tokenise emails are signed under the merchant’s DKIM, not Fluxa’s. The cardholder sees an email from the merchant, with the merchant’s branding, on the merchant’s domain.
- Hosted checkout
- The cardholder re-enters card details on a hosted checkout page. No card data passes through the merchant’s servers; PCI DSS scope stays at SAQ-A. Apple Pay and Google Pay are available where the underlying card brand is supported.
- Subscription state preserved
- The migration maps each old subscription to its new Fluxa subscription with the original anchor date, billing cycle, currency and amount preserved. The first Fluxa charge runs on the next scheduled cycle, not on migration day.
What follows
For merchants on the fence about switching: the blocker was always the migration. The migration is now three steps. The economic question (does flat 1.8% beat the merchant’s current effective rate?) is on the pricing page and in the comparison page.
This shipped as a v1. The account-updater integration for cards that have changed since the export is the next release. It uses the Visa Account Updater and Mastercard Automatic Billing Updater feeds to refresh tokens without contacting the cardholder, where the card brand and the issuing bank support it.
Questions on the migration tool: support@fluxapay.co.uk. To start a migration, open a Fluxa account from the home page.