Migrating Saved Cards to Forter

overview move your card vault without asking customers to enter their cards again if your existing payment service provider (psp) stores your customers' cards, you can migrate that vault to forter's agnostic card vault forter imports the exported card data and creates new forter tokens for your existing cards once the migration is complete, your saved cards can be used with the psps and payment services you choose, instead of being tied to the original psp the result is a single, processor independent vault for new cards, saved cards, recurring payments, and future payment optimization why migrate your vault to forter? use the same card token across multiple processors reduce dependency on a single psp keep sensitive card data out of your merchant systems when using forter's zero pci scope approach support network tokens and account updater capabilities from the same vault change processors without requiring customers to add their cards again forter's card vaulting solution is designed to replace sensitive card data with secure tokens and support processor flexibility across the payment stack see card vaulting https //docs forter com/card vaulting migration flow sequencediagram participant m as merchant participant p as current psp participant f as forter note over m,f step 1 · plan the migration \<br/> agree on cards in scope, timeline, processors, and whether to enable network tokens or account updater m >>p step 2 · request export of the existing vault f >>m step 3 · provide encryption key & transfer destination m >>p step 3 · forward pci aoc + encryption key p >>m step 4 · transfer the encrypted export (sftp/https, csv/jsonl) m >>f step 4 · share the encrypted export with forter note over f step 5 · decrypt, import & create forter tokens f >>m step 6 · return token mapping note over m step 7 · validate & roll out gradually \<br/> test a subset, reconcile, then shift traffic gradually how the migration works before migration you and forter agree on the cards in scope, migration timeline, payment processors, recurring payment use cases, and whether network tokenization or account updater should be enabled a smooth migration starts with a clear owner and a complete view of the existing payment integration before contacting your psp, identify a technical migration owner who understands your current checkout, vault, and payment flows the account owner or authorized signer who can request the export from the psp the customer, account, and payment method identifiers needed to map migrated cards back to your systems the psp's export documentation, file headers, transfer requirements, expected delivery timeline, and any associated fees during migration request an export from your current psp your authorized account owner contacts the current tokenization provider and requests an export of the existing vault depending on the psp, this may involve a support request, signed letter, or formal migration process the export process and file format depend on the provider prepare the secure transfer forter provides you an encryption key to share with the psp and destination needed for the transfer you provide the psp with the required pci attestation of compliance (aoc), together with the forter encryption key transfer the vault the current provider securely transfers you the agreed encrypted export common export formats include csv and jsonl, while common transfer methods include sftp or https; the psp's requirements determine the final format and transmission method your team does not need to expose the card data to its own systems as part of the migration process once you have the export, share it encrypted with forter to the destination provided import and tokenize forter decrypts and imports the card data and creates a new forter token for each eligible card map the new tokens forter provides the resulting token mapping so your systems can associate each existing customer payment method with its new forter token preserve the customer, account, and payment method references needed for traceability where supported by the integration, keeping the original psp reference as an alias can simplify reconciliation and downstream lookups your application then stores and uses the forter token going forward validate and roll out gradually start with a test migration using a representative subset of cards, or synthetic data where appropriate validate the file structure, token count, mapping, card metadata, and representative payment scenarios before migrating the full dataset after the test passes, reconcile the source and destination populations, then move traffic gradually to the forter based flow the original psp flow can remain available during the transition where needed after migration once a customer's card has a forter token, your system sends the forter token when a payment is needed forter can then use the stored card details to support authorization through the selected psp detokenize through the forter proxy when the downstream processor requires card data use a network token and cryptogram when network tokenization is enabled and available support a multi processor strategy without requiring a separate customer card entry flow for each psp the merchant facing experience remains a token based integration your systems store and pass forter tokens, while forter manages the underlying card data what happens to new cards during the migration? new cards should be tokenized directly through forter once the forter integration is ready this prevents the vault from continuing to grow in the old psp while the historical cards are being migrated depending on your rollout plan, you may use one of these approaches cutover all new cards begin using forter at once gradual rollout a percentage of new card traffic moves to forter while the migration is validated parallel transition existing cards continue through the psp until their forter tokens are available, while new cards are created in forter the exact approach depends on your checkout, subscription, and order management architecture recurring payments and saved cards before migration, identify all flows that use stored cards, including customer initiated transactions with a saved card merchant initiated transactions and subscription renewals re authentication or incremental authorization flows refunds that require access to the original payment method cvv collection for transactions where a fresh security code is required card deletion, replacement, or update flows your backend should be updated to store the forter token and send it to forter for the relevant payment operation customers should not need to re enter their card details solely because the vault moved from the psp to forter network tokens migration forter generally does not import a psp's existing network token as is network tokens are merchant specific and tied to the network's token requestor id (trid) forter typically creates or re provisions a new network token in the forter vault, linked to the forter token typical migration flow migrate the underlying card data into forter's pci vault and create a forter token confirm the network registration —including trid, legal entity, and network enrollment provide the migration population using stable card aliases/internal ids plus the required card metadata through the secure pci process forter maps the cards to the new vault and re provisions the network tokens return the mapping between the merchant's existing reference/forter token and the new network token record switch provisioning and processing to the new forter vault, then validate a subset before scaling up migration planning considerations timeline the schedule is driven by the psp's export process, your migration scope, and the time needed for testing and reconciliation confirm the psp's expected delivery date early and build time for a test run, issue resolution, full migration, and rollout validation test runs and reconciliation a test run helps identify formatting, mapping, and data quality issues before the complete vault is moved after each run, reconcile the number of source records, transferred records, successfully tokenized records, rejected records, and records requiring remediation multiple batches if the vault is large or the psp can only provide partial exports, agree on batch boundaries and a process for tracking completed, failed, and retried records continue tokenizing new cards in forter during the migration so the legacy vault does not keep growing merchant responsibilities you are typically responsible for confirming the cards and customer accounts in scope coordinating the vault export with your current psp providing the required pci aoc and transfer information to the psp confirming the desired migration timeline and any hard business deadlines updating your database and payment logic to store forter tokens testing new card, saved card, recurring payment, refund, and failure scenarios defining the rollout and fallback approach forter responsibilities forter typically supports you by providing the secure transfer destination and encryption key importing the vault export creating forter tokens for migrated cards providing the token mapping needed for your systems supporting validation and migration monitoring enabling the forter tokenization, detokenization, network token, or account updater flows included in your project scope migration checklist before starting, confirm the current psp supports exporting the vault the export includes the card and customer reference fields needed to map cards back to your accounts the migration scope includes all relevant websites, markets, and processors the recurring payment and merchant initiated transaction use cases are documented a migration window and validation plan are agreed your backend can store and use forter tokens a rollback or fallback path is available during the transition network tokenization and account updater requirements have been decided frequently asked questions do customers need to add their cards again? no the purpose of the vault migration is to make existing saved cards available through forter without requiring customers to re enter them, provided the source psp can export the cards successfully and they are included in the migration scope can we keep using the old psp during migration? usually, yes a transition can be designed so that the original psp remains available while cards are being migrated and validated the exact parallel processing and fallback design depends on your integration can we keep using the old psp after migration? yes forter tokens are designed to be agnostic to the downstream processor the psp must be configured to accept the relevant forter payment flow, typically through forter's detokenization proxy or orchestration integration does forter simply import the psp token? no the migration transfers the vault data through the agreed secure process, and forter creates new forter tokens your systems should use the new forter tokens after the mapping and validation steps are complete is there any data loss? the migration process is designed to avoid data loss cards that cannot be exported, transferred, validated, or tokenized should be identified and reconciled as part of migration validation what information does forter need to start? at minimum, forter needs the migration scope, current tokenization provider, estimated card count, timeline, desired payment scenarios, and whether network tokens or account updater are in scope forter then provides the secure transfer details required by the current provider