Visa Developer Community

Newbie

Problems with Flexibile Token API

I have set up a Project on Visa Developer Center, and I have API keys generated for use in the project. I am trying to test the Flexible Token API - https://developer.visa.com/capabilities/cybersource/reference#cybersource__cybersource_flex_api but I get an error when put my API Key into the call to Generate a Key referenced at:

 

https://developer.visa.com/capabilities/cybersource/reference#cybersource__cybersource_flex_api 

 

Which, according that doco is a Post to: 

 

https://sandbox.api.visa.com/cybersource/payments/flex/v1/keys?apikey={apikey}

Any help is very much appreciated as our project to move to the Flexible Token API, in order to improve our PCI DSS compliance is now running behind schedule. Thank you very much.

 

Tags (1)
4 REPLIES
Newbie

Re: Problems with Flexibile Token API

... and I have checked the npm site too, which wasn't much of a help either: https://www.npmjs.com/package/@cybersource/flex-sdk-web

Community Scholar

Re: Problems with Flexibile Token API

Hi @

 

Thank you for your inquiry. Please provide me more information to further investigate in the issue. Please provide the following:

 

1. Request Header and Body
2. Response Header and Body
3. Which version of CyberSource are you using?

 

If you are using CyberSource v1 APIs, this version was recently deprecated. You will need to move to v2 CyberSource APIs going forward. I have provided the link to the v2 Cybersource APIs below.

 

Cybersource Payments REST API
https://developer.visa.com/capabilities/cybersource/reference#cybersource__cybs_payments_v2

 

 

Thanks,
Diana

Regular Visitor

Re: Problems with Flexibile Token API

Regular Visitor

Re: Problems with Flexibile Token API

Therefore what I meant is that Cookies (traditionally called sessions) are a good way to go in web browsers (since they come built-in and are the most secure way of TRANSFERRING tokens). Other system may not support Cookies or are otherwise (e.g. Web View (Cordova/Phonegapp) apps) blocked from seeing Cookies may want to "manually" deal with the token (aka sending it back to the server on every authenticated request)

On the server you would traditionally have a store (a so called Session Store) to save the token<->user mapping. AKA When a user logs in, create a unique and random token for that user, save the binding/mapping in the Session Store and send the token as the response for the incoming login request back to the user (either in a Cookie header or some other header (Authorization header commonly used)).

Stateless tokens is the idea of encoding the user mapping (like a unique user id in your database that is plain text safe) within the token itself (meaning that you wouldn't have to check a Session Store on the server in order for you to know from what user that request is coming from).

There are problems with stateless tokens though, namely that you cannot revoke access to that token (only the expiry date will expire it) -- unless of course you incorporate a blacklisting system AKA a so called blacklist store -- then you would, for every incoming request, have to check the blacklist store to check if the token is blacklisted -- this of course pretty much defeats the entire purpose of stateless tokens -- since to begin with we wanted to skip the step of checking a store.