Migrations overview
Pismo lets you migrate existing products, such as cards and accounts, to the Pismo platform. There are two ways to migrate data:
- Call Pismo's migration APIs.
- Send the data in files directly to AWS cloud storage. The data in these files is formatted according to templates provided by Pismo.
Note to developers: You must schedule a time with your Pismo representative before you can use the migration APIs.
Types of data that can be migrated
You can migrate the following information:
Accounts
- The data that is migrated for accounts and customers includes name, document number, address, telephone, status, and account limit. Other custom fields can be specified.
- You can migrate canceled/inactive accounts.
- Fields can be updated at any time before the migration is fully finished.
Cards
- A card must have an associated account.
- Data for cards includes card name, status, type, issue date, expiration date, PAN, service code, and password).
- There is an exclusive bucket for PCI data (encrypted file with AWS KMS keys).
- Pismo migration APIs and workers are PCI compliant.
Authorizations
- Information about authorizations is ISO 8583 based.
- An authorization must have an associated account and card.
- You can migrate up to 6 months of data history for authorizations.
Balance/Statements
- A statement must have an associated account.
- Information about statements includes closing date, due date, current and previous balance.
- You can migrate up to 6 months of data history for statements.
- You can migrate pre-calculated accruals (and to continue accruals calculation on the Pismo platform after migration).
Transactions
- A transaction must have an associated account and statement. If it is a network transaction, it must also have an associated card and authorization.
- Information about transactions includes date, amount, authorization code, transaction type, merchant data, interest rate.
- You can migrate up to 6 months of data history for transactions.
- You can migrate different transaction types including purchases with or without installments, adjustments, and payments.
Migration process
In the migration process, the term "entry" refers to a data object that you are migrating to the Pismo platform. Every entry generates an event that is processed asynchronously. You need to send a unique migration ID and migration date with every entry. This guarantees no duplicate entries. If you want to update an entry, you must send the same migration ID and a new migration date that is later than the current migration date.
Migration events
There are three types of migration events:
- File events β If a line fails, a
file_unparseable_line
event is generated that specifies which line had a problem. After a file processes, the Pismo platform generates thefile_summary
event. This event includes the file name, status, number of processed lines, and number of failed lines. - Incoming events β Sent for every entry. Includes all the data sent to migration endpoints or files.
- Outgoing events β Sent for every entry. Includes the migration ID and Pismo IDs. For example, when you migrate an account, the generated event includes the account migration ID, the Pismo account ID, and the Pismo customer ID. It also indicates whether or not the migration was successful. If the migration fails, the event includes an error code and message.
Go live events
There are two types of go live events:
- After migrating accounts, you must call the Migrate accounts Go Live endpoint to let the Pismo platform know that the accounts are migrated and ready to use. Pismo responds by changing the migration status of the accounts to
MIGRATED
. - After an account goes live, the platform might still need to update cards. For example, a cardholder might have their password changed on an ATM machine soon after their account is marked as MIGRATED. The Pismo platform allows cards to be updated until you call the Migrate PCI cards Go Live endpoint. After that, no more changes are allowed. So, you can choose how large a window of time you want to provide for such changes.
Calling the Migrate PCI cards Go Live endpoint blocks further changes to cards.
Migration using files
You can migrate the following types of products using files:
- Authorizations
- Cards
- Statements
- Transactions
At this time, you have to use API endpoints to migrate accounts.
To migrate a product using a file:
Note:
To obtain the latest file templates, contact the Implementation team.
-
Download the template for the type of product you want to migrate:
- To migrate authorizations, use template_authorizations (en).xlsx
- To migrate card data, use template_cards (en).xlsx. This spreadsheet contains two worksheets. The
non-pci data
worksheet is used for non-PCI data, and thepci data
worksheet is used for PCI data. - To migrate statements or transactions, use template_statements_and_transactions (en).xlsx
-
Add the information specified in the template to a CSV file. For example, the following image shows part of a CSV file for migrating cards. Compare this to the corresponding template (template_cards (en).xlsx).
- The first line in the file corresponds to the header section of the template (lines 5 - 9).
- The next lines correspond to the card information that you want to migrate, formatted as specified in lines 13 - 36. (Only part of each line is shown in the image.)
- The last line in the file should be in following format:
99, [number of records]
For example:
99,00000000000000021
This is specified in the trailer section of the template (lines 40 - 41).
The following figure shows a snippet from a typical migration file:
-
Ask your customer respresentative to have Pismo create an S3 bucket for your CSV files. This bucket should contain a folder for each type of product. For example:
- /cards
- /pciCards
-
Upload your CSV files to the appropriate bucket.
Updated about 2 months ago