Export your data from Spreedly before the contract ends
If a renewal, a fee change or a move toward self-hosted payments is forcing your hand, know this first: vaulted cards and bank accounts can leave Spreedly only through the export paths Spreedly documents. Spreedly exports payment methods in two ways. For supported gateways, it moves payment methods through its store API, which returns a third_party_token for each payment method at the receiving gateway. For any other destination, you request a manual export, which Spreedly generally processes within 2 weeks once it has all the details it needs. Anything outside those two paths should be treated as not portable until Spreedly confirms otherwise.
Before you request a manual export, gather the inputs Spreedly asks for: the environment keys that hold the tokens, either a CSV list of tokens or a notice that you are migrating completely, and the receiving party's PGP public key. The output arrives as encrypted JSON or as separate encrypted CSV files for cards and bank accounts, so confirm with your receiving team that they can decrypt and parse both formats before the export is requested. Ask Spreedly to confirm the current export fees for your account, since its documentation says the first export to each third-party service is free and additional exports to the same provider are charged.
Exporting does not remove anything from Spreedly. Exported tokens stay in the Spreedly vault until you redact them, and they continue to incur storage charges until then. Plan redaction as its own step after you have verified that the receiving system holds working credentials, and ask Spreedly to confirm its redaction process and any final billing effects in writing. Do not decommission gateway connections until the cutover is complete, because a redacted token cannot be recovered.
Which data you can export from Spreedly and how
This table compares the two documented ways to move vaulted payment methods out of Spreedly: the store API path for supported gateways and the manual encrypted export for other endpoints. Read each row against what you must supply, how the file arrives and what it costs, so you can match the path to your destination before you ask Spreedly to start.
| Path | What it covers | What you must supply | Processing and fees |
|---|---|---|---|
| Store API export to supported gateways | Payment methods moved to a supported gateway, returned as a third_party_token for each payment method at that gateway | Access to the Spreedly store API and a supported destination gateway that can accept the export | Generally processed within 2 weeks; first export to each third-party service is free, extra exports to the same provider are charged |
| Manual encrypted export to other endpoints | Vaulted cards and bank accounts sent to a PCI compliant receiver that is not a supported gateway | Environment keys holding the tokens, a CSV list of tokens or notice of a complete migration, and the destination's PGP public key | Generally processed within 2 weeks once Spreedly has all details; first export to each service is free, extra exports are charged |
| Encrypted JSON file | Payment method data delivered as one encrypted JSON file | The destination's PGP public key so Spreedly can encrypt the output for that receiver only | Included in the manual export; confirm with Spreedly which file form suits your receiver |
| Separate encrypted CSV files | Cards and bank accounts delivered as separate encrypted CSV files | The same inputs as the manual export, plus a receiver able to decrypt and parse two file types | Included in the manual export; confirm column layout with Spreedly before import |
| Redaction after export | Removal of exported tokens from the Spreedly vault | Confirmation from your destination that the data loaded correctly | Exported tokens stay in the vault until redacted, and storage charges continue until then |
What does not leave Spreedly and how to work around it
The documented export covers payment method tokens and the details Spreedly needs to move them. Everything else in your Spreedly setup, from transaction history to configuration, needs a separate plan. The cards below cover what to confirm with Spreedly and what to keep from your own systems before you start.
Transaction history and receipts
The export documentation describes payment methods, not the full record of charges, refunds, voids and declines. Those records matter for reconciliation, disputes and tax reporting after cutover. Ask Spreedly support in writing whether transaction-level data is available for your account and in what format. Until you have that answer, treat your gateways and accounting ledger as the authoritative source for historical payments.
Gateway credentials and configuration
Gateway credentials, merchant IDs and gateway settings live in Spreedly's configuration, and the export is not documented as carrying them. Your new orchestration layer will need its own connector credentials at each processor. Inventory every gateway connected to Spreedly, confirm who holds the original credentials, and request new keys from each processor before the cutover date.
Account settings, webhooks and rules
Environment settings, webhook endpoints, retention configuration and any routing or fraud logic built in Spreedly are not in the list of exportable items. Document each one from your Spreedly dashboard and API calls, then rebuild the equivalent behavior in your self-hosted stack. Confirm with Spreedly support whether any of these settings can be exported.
Customer and user records
Customer profiles, names, addresses and other identifiers you attached to payment methods may not travel with the card token unless you sent them in the export scope. Map which of these fields your systems hold outside Spreedly. Pull them from your own databases so the new vault links each token to the right customer.
Confirming gaps before you commit
The documentation sets out supported exports, but account-specific scope can differ. Ask Spreedly support for a written list of what your account can export, including any data types not named in the public docs. Keep that answer in your migration file so auditors and procurement can see what was checked.
Records to keep after redaction
Once exported tokens are redacted, the Spreedly-side copies are gone and cannot be recovered. Before redaction, archive the export receipts, file hashes, decryption confirmations and reconciliation totals in your own records. This preserves evidence of what moved and when, which compliance reviewers will ask for.
Run a complete Spreedly export in the right order
This sequence moves vaulted cards and bank accounts out of Spreedly with the right keys, destination details and encrypted files, and ends with a check that the exported records match the source before anything is redacted.
Inventory the environment keys holding tokens
Start by listing every Spreedly environment that holds payment methods you need to move, such as production and any sandbox with live-like data. Record the environment keys and the approximate number of payment methods in each, and confirm with your payments owner which records are still in use. Export only what you intend to keep. The output is a written inventory that names each environment key and its scope, which you will reuse in the verification step.
Confirm the destination type
Decide whether the receiving system is a gateway that Spreedly supports for its store API export or a manual endpoint that needs an encrypted batch file. For supported gateways, Spreedly returns a third_party_token for each payment method at the gateway. For any other endpoint, plan for a manual export. Ask the destination provider to confirm in writing that it can accept the format you need. The output is a named destination type recorded against each environment.
Prepare the destination PGP public key
For a manual export, Spreedly encrypts the files to a PGP public key that you supply. Generate or obtain the key pair inside the receiving organization so that only that team holds the private key. Store the private key in your approved secrets process, test that it can decrypt a small sample file, and keep the fingerprint in your change record. The output is a verified public key that you have submitted to Spreedly with the export request.
Build the token list or migration notice
Prepare a CSV list of the payment method tokens to export, or state in the request that you want a complete migration of the environment. Use the token list when you want only a subset, and confirm the file contains one token per row with no extra columns. Check for duplicates and for test records that should not move. The output is a reviewed CSV file, or a written migration notice, that matches the inventory from the first step.
Submit the export request to Spreedly
Send the complete set to Spreedly: the environment keys, the token list or migration notice, and the PGP public key. Keep a record of the request date and the named contact who submitted it. For supported gateways, the export runs through the store API, while other endpoints go through a manual export that Spreedly generally processes within 2 weeks once it holds all details. Confirm the expected fee position before you submit, because Spreedly documents one free export per merchant to each third-party service, with additional exports to the same provider charged. The output is an acknowledged request with a reference you can track.
Receive and decrypt the export files
When Spreedly delivers the export, expect either one encrypted JSON file or separate encrypted CSV files for cards and bank accounts. Store the files in a restricted location, decrypt them only on a hardened system with the private key, and log who performed the decryption. Confirm the file format matches what your destination expects before loading any data. The output is a set of decrypted, readable files held in restricted storage.
Verify counts and sample tokens against the source
Before redaction, compare the decrypted record counts for cards and bank accounts with the counts in your inventory, per environment. Pick a sample of tokens across the list, including the oldest, the newest and any flagged records, and confirm each one is present in the destination and can be used there. Resolve any gap before continuing, because Spreedly keeps exported tokens in its vault until they are redacted. The output is a signed verification record showing matched counts and sampled tokens.
What the receiving endpoint must be ready for
The receiving endpoint must be PCI compliant before Spreedly will release card data to it, and it must be able to hold and use the keys that protect the export. Spreedly's manual export asks for the destination's PGP public key, so the receiver needs a PGP key pair in place first, with the private key kept under the receiver's control and the public key supplied to Spreedly. Confirm with the receiving provider which key lengths, key storage and rotation practices it applies, since those details determine who can decrypt the files once they arrive.
The receiver must also be able to decrypt what Spreedly sends and import it. Exports arrive as encrypted JSON or as separate encrypted CSV files for cards and bank accounts, so the receiving system needs tooling that decrypts each format and maps the fields, including the payment_method_token and card detail fields, into its own vault or gateway onboarding process. Test the decryption and import path with a small, non-production set of tokens before requesting the full export, and confirm that the receiver accepts the file formats Spreedly produces.
The PCI DSS scope and attestation of the destination are the reader's responsibility. Ask the receiving provider for its current attestation of compliance and confirm with your own assessor whether receiving card data changes your scope, which systems touch the decrypted files, and where they are stored in the interim. DeployOpen can prepare evidence for your assessment, including key handling procedures, transfer logs and access records, but DeployOpen does not issue attestations or certifications, and the assessor and the receiving provider must confirm the destination's status.
Questions buyers ask before exporting from Spreedly
How much does exporting data from Spreedly cost?
Spreedly's first export of payment methods to each third-party service is free, and additional exports to the same provider are charged. The number of exports is therefore the main cost driver: one export to one receiving service is the baseline, and each extra export to the same provider adds a charge that the Spreedly documentation describes. Your internal engineering time is the other component, covering the store API calls, the key and token inventory, and the receiving team's intake of the encrypted files. Ask Spreedly for its current export fee schedule in writing before you plan a second or third export, because the charge applies per export rather than per card.
How long does a Spreedly export take to process?
Manual exports to endpoints that are not supported gateways are generally processed within 2 weeks, once Spreedly has all the details it needs. Exports to supported gateways run through the store API and return a third_party_token for each payment method, so the timing depends on your own script and rate limits rather than a fixed Spreedly queue. Plan the export window around the 2-week figure for manual batches, and build in time for the receiving party to confirm it can decrypt and load the files.
What does the team need to prepare before requesting an export?
A manual export needs three inputs from your side: the environment keys that hold the tokens, either a CSV list of the tokens or a notice that you want a complete migration, and the destination's PGP public key. Confirm that the receiving service can accept encrypted JSON or separate encrypted CSV files for cards and bank accounts, because those are the formats Spreedly delivers. Assign owners for the token inventory, the key management on the receiving side, and sign-off on the scope of tokens to be exported.
Can we run a Spreedly export without an implementation partner?
Yes, a team with payments engineering and security skills can run the documented export process without outside help. The work is mostly coordination: building the token inventory, generating and exchanging PGP keys securely, requesting the export, and loading the encrypted files into the receiving system. A partner becomes more useful when the receiving system is not yet built, when the PCI DSS scope of the new environment needs to be defined, or when the team lacks capacity to test the import end to end. Whichever route you take, define the scope and acceptance tests in writing before the export starts.
Why does redacting exported tokens matter for storage charges?
Exported tokens remain in the Spreedly vault until you redact them, and Spreedly documents that retained tokens can carry ongoing storage charges. Redaction should therefore follow confirmation that the receiving system has loaded and validated every payment method it needs. Record which tokens were redacted, when, and by whom, so you can show the reconciliation later. Ask Spreedly to confirm the redaction behavior and any residual retention in writing, because the record of what was deleted is part of your audit trail.
What should we do if our payment gateway is not supported for a direct export?
Use the manual encrypted export route for that gateway. Spreedly's direct path covers supported gateways through its store API, while other endpoints need a manual export generally processed within 2 weeks. Gather the same three inputs described above, and agree with the receiving party how the files will be decrypted and mapped to the new gateway credentials. Confirm early with Spreedly whether your specific gateway is on the supported list, because that decision changes the effort and the timeline.
How should we handle keys and file transfers during the export?
Generate the PGP key pair on the receiving side, share only the public key with Spreedly, and keep the private key in a controlled key store with restricted access. Transfer the encrypted files over a channel your security team has approved, and verify file integrity before loading. Log every key exchange and file hand-off. These controls reduce the chance that exported card or bank data is exposed in transit, and they give auditors a clear record of how the data moved between systems.
What to plan before the Spreedly contract ends
A Spreedly exit is a sequence of decisions, not a single export. Each card below names one planning item, who owns it, and what to confirm before the next step starts. Read them in order, because the freeze on new vaulting determines what the export has to cover.
Confirm notice and renewal dates
Contract owner (procurement or finance) confirms the notice period and renewal date in writing with Spreedly. Those dates set the latest point for the export and the last day of billing, so every other step is scheduled backward from them. Ask Spreedly whether any export or redaction work falls after termination and whether exported tokens are charged for storage in the meantime. Do not rely on the dates in an internal summary.
Freeze new vaulting
Product owner stops adding new cards and bank accounts to Spreedly at a set cut-off date. A vault that keeps growing during migration means more tokens to export, more batches to reconcile and a moving target for verification. Route new checkouts to the replacement path or the current gateway directly, and document the cut-off so the export covers a fixed population.
Run the replacement in parallel
Platform engineering lead runs the replacement vault and orchestration alongside Spreedly for a test window. Parallel running shows whether transactions succeed through the new path before any production traffic depends on it. Compare authorization outcomes per gateway, and keep Spreedly active until every gateway you rely on has a verified route.
Decide PCI DSS scope for the new vault
Security and compliance lead chooses the vault model before any card data is received. A self-hosted in-house vault puts the organization fully in scope for PCI DSS certification and data handling, while an external PCI vault narrows that scope. Agree the model, the assessor's view and the evidence plan first, because the receiving system must be ready before Spreedly's encrypted export is sent to it.
Re-point gateways and verify tokens
Payments engineering owns re-pointing each gateway integration and verifying that imported credentials work. Exported tokens only help if the destination can charge them at the same gateway, so test a sample of each payment method type against each processor. Record which tokens fail, because those customers will need to re-enter their details.
Schedule redaction after verification
Data owner signs off the verified population, then requests redaction of exported tokens in Spreedly. Exported tokens stay in the Spreedly vault until they are redacted, which is what avoids ongoing storage charges. Set a redaction date only after reconciliation is complete, keep a record of the token counts sent and confirmed, and ask Spreedly to confirm in writing when redaction is done.
Verify the export and redact tokens afterward
Do not redact anything in Spreedly until the receiving system has confirmed it holds every token you asked for. Before you close out the export, reconcile counts: compare the number of tokens listed in your CSV, or the number of payment methods in the environment you scoped, against the number of records the receiver reports importing for cards and for bank accounts separately. Any gap should be explained at record level, not averaged away. Then run sample checks. Pick a set of payment methods, including some from each gateway and some with recent activity, and confirm with the receiving gateway or orchestrator that each token resolves to a usable payment method. Ask the receiver to confirm the mapping from Spreedly's returned tokens, including any third_party_token values for supported gateways, to its own identifiers.
Keep an audit record for each export from the first request onward. Record the date of the request, the environment and the token list or migration notice you supplied, the destination's PGP public key fingerprint, the file names and formats received (encrypted JSON or separate encrypted CSV files for cards and bank accounts), the reconciliation counts, the sample results and who approved each step. Store the record where your payment operations and compliance teams can both read it. Because the export is delivered encrypted, also record where the decryption keys are held and who can use them. Keep a change record for auditors that links this export to the change ticket, the approvals and the Spreedly fee invoice for any additional exports.
Redact only after sign-off. Exported tokens stay in the Spreedly vault until you redact them, and they continue to attract storage charges until then, so schedule the redaction once the audit record shows the receiving system is confirmed. Confirm with Spreedly's current documentation how redaction is requested and what it removes, and ask for written confirmation of the date it takes effect and whether any charges accrue after that date. Once redaction is complete, record the confirmation in the change record and remove any working copies of the export files from shared drives according to your retention policy.
How DeployOpen scopes and delivers a Spreedly exit
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the export of vaulted payment methods can be scoped and run as a defined piece of work. The steps below describe how that work is agreed, built, handed over and supported for an exit from Spreedly.
How we scope
- Confirm which payment methods sit in which Spreedly environments and which gateways each one supports
- Agree in writing whether exports go to a supported gateway or to a manual encrypted export at another endpoint
- Define the receiving party's PGP key handling, file formats and who signs off on the destination before work starts
How we build
- Prepare the export request inputs, including environment keys, token lists or a complete migration notice
- Set up the receiving environment and check that encrypted JSON or CSV output can be decrypted and reconciled
- Test a sample export end to end, then record token counts and mismatches before the full batch is requested
How we hand over
- Document the export steps, decryption checks, reconciliation results and owners for each receiving service
- Record the redaction plan for exported tokens in Spreedly so storage charges stop once the data is confirmed
- Deliver evidence of each control for your own compliance team and any independent assessor you engage
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Quotes follow from the written scope, so ask for line items covering export work, testing and documentation
