Tokenization API

[vnagre138]

Hi,

when I create a payment instrument token with https://apitest.cybersource.com/tms/v1/paymentinstruments 

How long the token will be valid? Can I use same payment instrument token for similar transactions after few days?

thanks

Vijay

[rajvpate]

Hi, The tokenization API does not have an expiration date. You can continue to use it as long as it is ACTIVE and the associated payment method works

[GrehnanSondra]

As of right now, you cannot retrieve a permanent access token. You have 2 options that come close.

The first is to request a "refresh" token when using the standard OAuth flow. That's what you're doing by sending "duration" as "permanent" in your code. The refresh token can be used to automatically retrieve new 1 hour access tokens without user intervention; the only manual steps are on the initial retrieval of the refresh token.

The second alternative, which applies only when writing a script for personal use, is to use the password grant type. The steps are described in more detail on reddit's "OAuth Quick Start" wiki page, but I'll summarize here:

1. Make a request to with POST parameters grant_type=password&username=<USERNAME>&password=<PASSWORD>. Send your client ID and secret as HTTP basic authentication. <USERNAME> must be registered as a developer of the OAuth 2 client ID you send.

[JunaNougsan]

You seem to be a bit confused as to what, exactly, OAuth is, so hopefully I can clarify it here.

OAuth is not a web service or something you consume. It is a protocol that describes the way that a site can authenticate a user against a service, without allowing the site to know what the user's credentials are. As a side benefit, most OAuth providers also have a web service to query the user's information, and permission to do so can be granted at the same time.

Typically, you are interested in implementing OAuth from the perspective of the site (eg, AcmeWidgets.com) so that a user can log in via Facebook or Google or something. However, you can also implement the service side (eg, where Facebook normally would be), and allow others to authenticate against YOU.

So, for example, let's say you have a web service to allow for third-party sites to provision Acme-brand Widgets for users. Your first third-party implementor is the popular MyBook.org. The flow would look something like this:

1. Someone invites the User to use the "Acme Widgets" app on their MyBook profile.

2. The user clicks on the button, which redirects to AcmeWidgets.com. The URL looks something like:

   http://acmewidgets.com/oauth/user?r=http%3A%2F%2Fmybook.org%2Foauth%2Fclient&appid=12345

3. The user is asked if they want to allow MyBook to access their data and provision widgets.
4. The user clicks Yes, whereupon Acme Widgets notes that the user has allowed it.

5. The user is redirected back to MyBook, at a URL like this:

   http://mybook.org/oauth/client?token=ABCDEFG

6. MyBook, on the server side, now takes that token, and places a web service call BACK to AcmeWidgets:

   http://acmewidgets.com/oauth/validate?token=ABCDEFG&appid=12345&appsecret=67890

7. AcmeWidgets replies with the final authentication token identifying the user.
8. Alternately, it fails, which means the user is trying to fake a token, or they denied permission or some other failure condition.

9. MyBook, with the token, can now call AcmeWidgets APIs:

   http://acmewidgets.com/api/provision?appid=12345&token=ABC123&type=etc

This is all known as the OAuth dance. Note that there are a number of implementation defined things here, like URLs, the means of encoding the various tokens, whether tokens can expire or be revoked, etc.

https://developers.payulatam.com/latam/en/docs/integrations/api-integration/tokenization-api.html /omeglzechat