How to export data from Primer before your contract ends
If your Primer renewal, pricing change or residency requirement is pushing you toward self-hosting, start with the card tokens. Primer documents a token export for vaulted payment credentials, delivered as an encrypted file over SFTP, and some token types cannot leave the platform at all. The export is initiated through a support ticket, and the file is only useful if the receiving provider can accept it, so plan the export as a joint exercise with that provider from day one.
Before you open a ticket, inventory your token types. Apple Pay tokens, Google Pay tokens using CRYPTOGRAM_3DS, network tokens bound to Primer, and inactive or expired tokens cannot be exported, so each of those categories needs a re-tokenization or customer re-entry plan. Ask Primer to confirm the exact token categories in your merchant account, and decide whether you want a full export or a partial one. A partial export requires a list of tokens, which Primer can generate for you. Read the Primer token export guide with your engineering and compliance leads before the ticket goes in.
The receiving provider must supply its PCI attestation, an encryption public key and its preferred import file format, and these are the items most likely to delay a cutover. Confirm early that the receiver can accept the encrypted file and will import it, and agree a completion date only after Primer validates the export. That date depends on volume and on the receiver, so ask Primer for it in writing and build your contract notice period and parallel-run window around it, not around your renewal date alone.
Which Primer data can be exported and how
This table compares what Primer's documented token export covers against what it cannot export, and the inputs each side must provide. Read it as a scoping checklist: the export path is defined, but the field-level file schema must be confirmed with Primer before the receiving side is built. The main takeaway is that wallet tokens, some network tokens and inactive or expired tokens will need re-tokenization or customer re-entry.
| Item | What the documentation says | What you must confirm or supply |
|---|---|---|
| Request start | A support ticket with the merchant account ID starts the export | Merchant account ID and the internal owner who approves the request |
| Export scope | Full export, or partial export driven by a token list Primer can generate | Whether you need every vaulted token or a filtered subset, and who signs off the list |
| Delivery channel | Primer delivers the encrypted file over SFTP | SFTP host details, key exchange process and who on your side holds the decryption key |
| Receiver requirements | Receiving provider supplies its PCI attestation, an encryption public key and its preferred import file format | Current attestation of compliance, the public key owner and the file format version the receiver accepts |
| Field-level schema | The documentation does not list every field in the export file | Full field list and data types in writing from Primer before you scope the receiving import |
| Non-exportable: wallet tokens | Apple Pay tokens and Google Pay tokens using CRYPTOGRAM_3DS cannot be exported | Plan customer re-enrollment or wallet re-provisioning with the new provider |
| Non-exportable: network and inactive tokens | Network tokens bound to Primer and inactive or expired tokens cannot be exported | Count these tokens in your inventory and decide whether to let them lapse or re-collect them |
| Completion date | Agreed after validation, depending on volume and the receiving provider | Ask Primer for a written completion date and the validation steps that set it |
Which Primer token types cannot leave and what to do about them
Primer's documented export exclusions cover wallet tokens, a specific Google Pay cryptogram type, network tokens bound to Primer, and inactive or expired tokens. Each one changes what the new provider can accept on day one, so inventory them before the export is scheduled.
Apple Pay tokens
Primer cannot export Apple Pay tokens, so any customer whose saved payment method is an Apple Pay token will not arrive at the new provider with a usable credential. The practical consequence is that these customers must authorize Apple Pay again on the new checkout before a recurring or saved-card charge can run. Ask your receiving provider how it sets up Apple Pay merchant enrollment and whether it needs a separate processing configuration.
Google Pay CRYPTOGRAM_3DS tokens
Primer cannot export Google Pay tokens that use the CRYPTOGRAM_3DS authentication method. Customers holding these tokens will need to re-authorize Google Pay at checkout, and any stored-credential or subscription flow that depended on them will fail until that happens. Identify these tokens in your Primer data before the export, count the affected customers, and confirm with the receiving provider which Google Pay authentication methods it supports.
Network tokens bound to Primer
Network tokens bound to Primer are tied to Primer's token service and cannot be exported. The consequence is that card-on-file credentials issued through card network token programs may need to be requested again through the new provider, which can change the cardholder experience and authorization rates during the transition. Ask the receiving provider how it obtains network tokens for migrated cards and how it handles token lifecycle updates from the card networks.
Inactive and expired tokens
Primer does not export inactive or expired tokens, so these records leave your estate with no equivalent at the new provider. Before scheduling the export, decide which inactive records you need to keep for reconciliation or dispute handling, and which should be retired. Customers with expired cards will need to provide updated payment details, so plan communications and a fallback for failed renewals.
Partial export token lists
For a partial export, Primer generates the token list from the identifiers you provide in the support request, so the list is only as complete as the input. Excluded token types should be filtered out of that list before it is finalized, or the export will not match the migration plan. Ask Primer to confirm which tokens in your list fall under these exclusions before validation begins.
What the receiving provider must supply before the export starts
For a Primer token export, the receiving payment provider must supply three things before any card data moves: its PCI attestation, an encryption public key and its preferred import file format. The attestation is the evidence Primer and your security team use to confirm that the recipient can lawfully hold full card numbers. Without it, the export stops at the review stage no matter how the file is packaged. Ask the receiver for its current attestation of compliance and confirm that the scope it covers includes the storage environment where the imported tokens will sit, not only its payment processing.
The encryption public key matters for a different reason. Primer encrypts the export file for one specific recipient, so the key must belong to the receiving environment and must be generated and held under that provider's control. Ask the receiver who manages the matching private key, how it is stored and who can use it to decrypt the file. Confirm the key format and how it will be exchanged, because a key sent through an informal channel is itself a risk to the transfer. The preferred import file format matters because it determines how Primer shapes the encrypted file, so a format mismatch will delay delivery even when the security review is complete.
Confirm with both Primer and the receiver whether the key exchange and attestation review happen before or after the support ticket is opened. If the ticket starts the clock and the review follows, your team may wait on a provider that has not finished its checks. If the review comes first, the ticket can be raised with the receiving details already agreed. Write the sequence, the named owner on each side and the document or key that closes each step into the cutover plan, so that the export schedule depends on completed inputs and not on assumptions.
The sequence for a complete Primer token export
This sequence moves vaulted card tokens from Primer to a receiving provider in an agreed scope, delivered as one encrypted file. Each step closes with a record you keep, so the scope, the receiver's requirements and the delivery terms can be traced later.
Decide between a full or partial export
Your payments or security lead decides whether to export every eligible token in the merchant account or only a defined subset, such as one customer segment or one card scheme. A full export removes the need to maintain a token list, while a partial export requires you to identify each token up front. Record the decision, the business reason and the owner in your migration log. The output is an approved export type that the support request will reference.
Open the support ticket with Primer
Your Primer account owner opens a support ticket that gives the merchant account ID. For a partial export, the ticket also includes a list of tokens, and Primer can generate that list for you if you do not hold it. Keep the ticket number, the submission date and the exact list version you sent. The output is a ticket that Primer acknowledges and assigns to an export contact.
Agree the token list and exclusions
Review the token list with Primer and confirm the exclusions before any file is prepared. Primer cannot export Apple Pay tokens, Google Pay tokens that use CRYPTOGRAM_3DS, network tokens bound to Primer, or inactive and expired tokens. Map each excluded token type to a customer re-tokenization or re-authentication plan with its owner. The output is a signed-off scope document listing included tokens, excluded types and the re-tokenization workload.
Confirm the receiver's requirements
Obtain from the receiving payment provider its PCI attestation, its encryption public key and its preferred import file format. Check that the attestation is current and that the key is the one the receiver's security team controls, and store the key fingerprint in your records. Ask the receiver to confirm the file format against a sample. The output is a receiver requirements pack that Primer will need before it encrypts anything.
Validate the export scope with Primer
Send the receiver requirements pack to Primer and ask it to validate the scope, the file format and the key against the token list. Primer confirms the volume and the receiver's acceptance, and it may ask for changes before it proceeds. Your team should reconcile the validated token count with the approved scope from step three. The output is a written validation confirmation with the final token count and any agreed changes.
Receive the encrypted file over SFTP
Primer delivers the encrypted export file over SFTP. Confirm the transfer details through a channel independent of the email that carried the file, then verify the file's checksum and size against Primer's delivery notice. Only the receiver's private key can decrypt the file, so have the receiver confirm it can open the file before you delete any staging copies. The output is a transfer record with the checksum, the delivery time and the receiver's decryption confirmation.
Agree the completion date and cutover
Once the file is received, agree a completion date with Primer that reflects the validated volume and the receiver's import schedule. Primer sets this date after validation, so you should not expect it before step five is closed. Plan the cutover so that the receiver's import is verified before traffic moves and the Primer tokens stay active until the import is confirmed. The output is a written completion date and a cutover record linked to the transfer record.
How to verify the imported tokens before cutover
Reconcile the delivered token count against the agreed token list before anyone routes a live payment. The support request that starts a Primer token export can carry a list of tokens for a partial export, and that list is the baseline. Compare the number of records the receiving provider reports as imported with the number Primer delivered in the encrypted file, then compare both with the agreed list. Any gap between the three numbers needs an explanation in writing. Expect some tokens to be absent by design, because Primer cannot export Apple Pay tokens, Google Pay tokens using CRYPTOGRAM_3DS, network tokens bound to Primer, or inactive and expired tokens. Build a reconciliation sheet that marks each of those categories as expected exclusions, so that an unexplained difference stands out.
Test a sample of imported tokens with the receiver in a non-production or controlled environment before any live traffic is routed. Choose records across card brands, countries, expiry dates and token origins, and run test authorizations against the receiving provider's sandbox or a controlled test merchant account. Confirm that each sample token decrypts and resolves to the expected payment method and that the card-on-file or recurring flags survived the transfer. Keep the test results, including failures, as evidence for your change record. Before you start, confirm with the receiver how failed or rejected tokens are reported, in what file format, and whether the receiver will identify the specific records that did not import. If the receiver cannot name those records, plan a manual way to find them, because a count alone will not tell you which customers need re-tokenization.
What to plan before the Primer contract ends
Exporting vaulted tokens is one step in a larger exit. The cards below cover the timing, dependencies and customer-facing gaps that need decisions before termination or renewal, so the export lands inside a cutover window you control.
Time the export ticket
Primer starts a token export with a support ticket that names the merchant account ID and, for a partial export, the list of tokens. Primer agrees the completion date after validation, based on volume and the receiving provider. Open the ticket early enough that the agreed completion date falls inside your cutover window, with room for a failed validation and a second delivery. Ask Primer how it sizes that window for your token count before you set the contract end date.
Keep Primer active until validation
Do not switch off Primer checkout, routing or the vault until the receiving provider has confirmed that imported tokens validate and that test payments succeed with them. A cancelled account can end the path you need to resolve a failed file, a rejected token or a question about delivery. Agree in writing when the last live transaction runs through Primer and when the vault is closed.
Inventory Primer-dependent routing
Before the export, list every routing workflow, retry rule, fallback processor and failover path that runs on Primer. Map each one to its replacement in the new orchestrator, along with the processor credentials it needs. Routing that reads Primer's vault output or processor responses can break silently after cutover, so record which rules you will rebuild and which you will retire on purpose.
List checkout components and webhooks
Identify every checkout component, SDK call, server-side API request and webhook endpoint that sends or receives data from Primer. Include reconciliation jobs, fraud or ledger feeds and internal services that parse Primer event payloads. Each item needs an owner, a replacement and a test case, because webhook consumers often fail without an error in the checkout flow itself.
Plan for wallet and network tokens
Primer cannot export Apple Pay tokens, Google Pay tokens using CRYPTOGRAM_3DS, network tokens bound to Primer, or inactive and expired tokens. Pull a count of these by customer segment and identify which customers must re-enter a card or re-authorize a wallet. Decide how you will ask for consent, when you will show the prompt and how you will handle subscriptions or saved payment methods that depend on those tokens.
Confirm data return terms in writing
The export documentation covers the technical path only. Ask Primer in writing what happens to your vaulted data, logs and payment records at termination, including return formats, retention periods, deletion timelines and any certificate of destruction. Compare those answers with your own retention obligations and with the terms your receiving provider requires before you sign anything.
Common questions about exporting data from Primer
How long does a Primer token export take?
The documentation does not publish a fixed duration, so the completion date is agreed after Primer validates the request, based on the volume of tokens and the receiving provider. Ask Primer to confirm the agreed date in writing before you plan a cutover. Your team should expect validation to happen before any file is produced, and the export to run on the date both sides accept. Build your migration plan around that agreed date rather than an estimate from a third party, and keep the old routing live until the receiver confirms imports.
What does our team have to provide before an export starts?
The export starts with a support ticket that gives your merchant account ID and, for a partial export, the list of tokens to include. Primer can generate that token list for you if you do not hold it. On the receiving side, the payment provider must supply its PCI attestation, an encryption public key and its preferred import file format. Your team should also name who will receive the encrypted file over SFTP, confirm the receiver's import window, and agree who signs off on validation results.
Which card credentials cannot be exported from Primer?
Primer documents four exclusions that you must plan for. The first is Apple Pay tokens. The second is Google Pay tokens that use CRYPTOGRAM_3DS. The third is network tokens bound to Primer. The fourth is inactive and expired tokens. Each excluded credential must be recollected from the customer or reissued through the new provider, so count them during planning. The share of your vault affected depends on your payment mix, which you should ask Primer to report in the validation step.
Can our own engineers run the export without outside help?
Yes, the documented process is a support request, a receiver readiness step and an encrypted SFTP delivery, so an internal team can run it. The work that is hard to staff in-house is the receiving side: encryption key handling, file format mapping, import testing and evidence for your PCI DSS assessment. Teams that run it internally usually own the receiver integration and the cutover checklist. If you want outside help, DeployOpen plans, implements and integrates self-hosted platforms in your own infrastructure, and the scope is agreed in writing before work starts.
What makes the export effort go up or down?
Four factors drive effort most. Token volume determines validation and file preparation. The number of excluded token types determines how much recollection or reissue work follows. Receiver readiness, including attestation, key exchange and a tested import format, determines how many rounds of correction happen. A partial export is simpler than a full one because it limits the token list. Ask for each factor to be reported as a count in your scope so you can compare quotes on the same basis.
What should a written scope for a Primer export include?
A written scope should name the merchant account ID, the token list or the rule used to build it, the receiving provider and its attestation status, the encryption key owner, the SFTP delivery arrangement, and the agreed completion date. It should list the excluded token types and state how each will be handled, such as recollection or reissue. It should also define acceptance criteria for the receiver's import, the cutover plan, the rollback path and who keeps the evidence for your compliance assessment. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any attestation or certification.
How do the costs of exporting from Primer break down?
Costs fall into one-time work and recurring work. One-time work includes validation, export preparation, receiver integration, import testing, re-collection of excluded credentials and cutover. Recurring costs appear when you run the receiving platform, such as hosting, patching and PCI DSS scope maintenance. Ask any quote to separate these categories and to show who is paid for each. No price list is published, and a quote follows from the written scope. Note that the Spreedly documentation sets one free export per merchant per receiving service, which is a different vendor's policy and not a Primer term.
How is the encrypted file delivered and what must the receiver check?
Primer delivers the encrypted file over SFTP, and the receiving provider must hold the matching private key to decrypt it. The receiver should verify the file integrity, confirm the record count against the agreed token list, and test a sample import in a non-production environment before the full load. Keep the decryption key in a managed secrets store with restricted access and log every decryption event. Confirm with Primer the exact file format and naming convention in writing, since the receiver's preferred format was supplied at the attestation step.
How DeployOpen works on this
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so a Primer token export lands in an environment you control. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory which stored credentials are card tokens, wallet tokens, network tokens or inactive tokens, since Primer cannot export several of these types.
- Confirm the receiving provider's PCI attestation, encryption public key and preferred import file format before any export is requested.
- Agree in writing whether the export is full or partial, and which merchant account IDs and token lists the support ticket will name.
How we build
- Set up the receiving environment and the decryption and import steps so the encrypted SFTP file can be processed without manual handling of raw card data.
- Test the import against a validation batch and reconcile token counts and field mappings against the source list before cutover.
- Plan re-tokenization or customer re-authentication for the wallet and network tokens that cannot leave Primer, and document the order of work.
How we hand over
- Deliver runbooks covering the export request, file receipt, decryption, import, reconciliation and rollback steps for your team.
- Document the cutover schedule, including the date agreed with Primer after validation, and the routing change that follows it.
- Provide evidence of controls and test results to support your own assessment, while independent auditors and certification bodies issue any formal reports.
How we support
- Available as a retainer for ongoing operations, upgrades, backups and continuous security testing after the cutover is complete.
- Maintain the self-hosted components and apply updates on a schedule you approve, with changes recorded in the documentation.
- Ask for a written quote built from the agreed scope, including the one-time export work and any recurring support you choose to add.
