#charles_card-migration
slim beaconBOT
š Welcome to your new thread!
ā²ļø We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
ā±ļø We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
š This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1283565040728936544
š Have more to share? Add more details, code, screenshots, videos, etc. below.
vapid belfry
Hey @tawny ravine https://docs.stripe.com/get-started/data-migrations are our docs and the process
charles_card-migration
tawny ravine
I was told by WorldPay this..
Considering the number of tokens need to be migrated. We would recommend to use the API-based migration.
Worldpay would issue new credentials to us.
API-based
Prerequisites
A new set of basic auth credentials with the ability to fully detokenize tokens.
Request
Merchant should perform a token inquiry as specified in our documentation, with the following differences:
Ensure to use the correct, new credentials in the header
Any API version can be used
Pass masked = false as an additional header, as follows: Accept: āapplication/vnd.worldpay.tokens-v3.hal+json; masked=falseā
Use the above with the standard token inquiry only, GET token HREF. Full detokenization is not supported in the following:
GET by token ID
GET namespace
GET by namespace and token ID
Response
Response will be identical to current expected response objects, documented here: https://developer.worldpay.com/docs/access-worldpay/tokens/querying-and-updating-tokens#token-inquiry
With the following exceptions:
Within the paymentInstrument, ātypeā will become ācard/frontā or ācard/plainā
The cardNumber will be unmasked. Note: the hyphen in the cardNumber is only in the documentation and will not be included in the API response. The next action links will be included as usual.
Merchants should collect these card details and use them to create a new token with their new PSP.
vapid belfry
Yeah it's not something we support. So really Worldpay needs to export the data securely to Stripe as documented in the documentation page I shared. Worldpay has done this dozens of times over the years
tawny ravine
Thank you . I will pass this on to WorldPay. They also mentioned
There is a known issue with file-based outbound token migration in an Access Worldpay context, in that HREFs will not be included in the export file, and merchants will need to reconcile the token ID provided with the token HREF on their side. The API-based approach is fully functional, but given the merchant would be exposed to the PCI burden of handling plain card details, this approach is more likely to work if their new PSP integrates with our APIs on the merchantās behalf.
vapid belfry
yeah basically they give you the raw card details and say "good luck". Or force us to go and integrate with their APIs (And its quirks, how to do rate limits, handle errors, trigger alerts that suddenly a new server is hitting their API, etc.)
I get why they want this, but this is not the way literally hundreds of PSPs (including them) have for yours
tawny ravine
The way I understand it is that WorldPay will not be able to perform the process based on the documentation you have provided to me due to the known issue from their side. And the option they have given us is not supported by Stripe. What do you think is the best option or how should I push back to Worldpay? do I need to ask them to fix the known issue or perhaps advise the merchant to inform their customers to enter their card details again when moving to Stripe.
vapid belfry
I would push on Worldpay to force them to export. Many PSPs refuse to do the work until you escalate basically.
Considering the number of tokens need to be migrated. We would recommend to use the API-based migration.
clearly it's a recommendation, not a requirement.
and really I get it, I did card migrations for years at Stripe. We did sometimes reach the limits of our system in terms of what we can export. But then we prioritized a fix and fixed it!
tawny ravine
Awesome. Thank you so much for your help! Appreciate it. Legend