So everytime a customer enters the credit card information on my site, their credit card information gets stored (partially) in the database along with the corresponding gateway payment token for Authorize.net. How long is this token good for before it expires in the production site? I'm assuming that these tokens in development or staging accounts will never expire? Thanks!
Are you referring to the "customer_profile_id" that gets returned from Authorize.net? If so, this token does not expire. Be aware, that the credit card associated with the profile can expire/get cancelled/etc though, which would result in errors when you attempt to do a future purchase with that token.
Related
WE are looking to get payment card tokens on every order. I believe we only get the payment tokens on registered users but need them for all orders. Is it possible to set up CyberSource to provide the transaction id and customer and payment tokens on all orders.
Did the normal setup for CyberSource and verified in the order data that tokens only appear for registered users.
My skill requires Account Linking which will authenticate customers with an AWS cognito user pool through OAuth 2.0 Protocol.
I can specify in the user pool the TTL of the refresh token, which I decided to have it valid for 60 days.
From what I understand, alexa sends you the access token along with each request that your skill receives so you can identify customers using the skill. If their access token expires alexa would handle this by refreshing their token before forwarding the request with the access token to you. So you can have a valid access token.
Now, what happens when the refresh token expires? and does it expire after 60 days even if the customer is using the skill on daily basis? I guess what I'm asking is:
When the access token expires and alexa refreshes it. Does the refresh token also get refreshed?
If yes, how do we keep the customer signed in and their account linked when the refresh token expires after 60 days?
I think you can find the answers in the documentation.
Verify that the token is valid
If the accessToken exists, verify that it identifies a user in your resource server. The token could become invalid for multiple reasons, for example:
The user deleted or canceled their account with your service. For example, an Alexa user might have set up account linking with Ride Hailer, then later canceled their Ride Hailer account. At this point, the token stored by the Alexa service would identify a non-existent user.
The token has expired, and the Alexa service was unable to obtain a new token. This can occur with an authorization code grant if your authorization server does not provide refresh tokens. This can also occur if you use an implicit grant, which does not support refresh tokens.
If the token is valid, handle the request normally. You can use the token to access data from your resource server as needed. In the Ride Hailer example, the skill would retrieve profile and payment information for the user from the Ride Hailer service, order a car, and return a confirmation to the user. See Return a Response for details.
I am working for a client who has a legacy Server integration and make use of the Token system. The SagePay API shows they have 1583 saved Tokens however they only have 421 saved in their database - a huge discrepancy which I have been asked to investigate.
I think this is what has been happening:
Customer decides to click the "Save your card details" checkbox on their website
The POST is sent to SagePay containing "CreateToken=1&StoreToken=1"
Customer gets redirected to SagePay and decides to pay by PayPal instead
A Token gets created and the company gets charged for it even though it can't ever be used
The Dev before me only saved the Token from the notification page only if the payment type used was Credit Card which makes sense. What nobody realised until now was that SagePay would create and save Tokens even if the customer paid with PayPal [?] Surely this shouldn't be the case!
That means we have 1162 Tokens that we have simply lost control of. It is quite expensive to store so many Tokens and I have been asked to see if I can reduce the number. It is fairly easy to remove Tokens through the SagePay API, that is if you have the original Token! In this case, we don't have all of them.
I have contacted SagePay support but they just referred me to the API which doesn't solve the issue.
Will the Tokens we've lost control of simply naturally expire and delete?
Is there anything we can do to reduce the number of Tokens?
Thanks
There are two ways to create tokens:
As part of a PAYMENT, ask SagePay to additionally tokenize the card details (so you can reuse them without needing to store the card details)
Outwith a payment, you can send arbitrary card details and ask SagePay to store them in a TOKEN request.
If you are creating a token in a standalone TOKEN request, and then thereafter submitting a PAYMENT using the previously tokenized details, the solution I would recommend is creating a token as part of a PAYMENT (i.e one API request rather than two).
If you are already creating the token as part of the PAYMENT, the only solution I could recommend is keeping track of tokens stored in your data store, and if they haven't been used for any payments, have a scheduled job to remove these tokens (using the REMOVETOKEN request).
There seems to be a bug on submitting createToken=1 via Server, when the consumer selects Paypal - if you use the Reporting API to query such a useless token, the expiry returned is XXXX - which means it will never expire, so your client will be paying for it forever!
I'd contact Sage support if I were you and request a complete list of tokens that they hold, then use the API to query getTokenDetails on each, then discard those which are not usable / no longer active (via the REMOVETOKEN API call).
Application is intended to be used by the company for managment of intercompany documentation. These documents can contain valuable information, so it must be secure application. I am using Oauth2 with access and refresh tokens. Access token is valid for 15 minutes and refresh token is valid for 1 day.
I have not found any recommended lifetime for tokens.
Is 15mins for AT and 1 day for RT good? If yes, why these values are good enough OR are not good enough?
What is optimal lifetime for AT and RT for application which must be really secure.
Thanks a lot!
Gmail vs. bank accounts.
I can't tell where your business falls under. You should sit in in a meeting with your product team and explain what happens and let them decide. It's ok if it takes some try and error to get the right number.
But for Gmail the refresh token almost never expires. I can't think when was the last time I had to enter my credentials again.
For banks, the refresh token seems to be valid for only 10 minutes and if you background the bank app then you won’t be able to get a new refresh token and so you get signed out. Like my bank of America app. If I keep the app open then the app will continue to refresh the token.
And obviously refresh token expiry time should be more than your average user's session time.
I saw the description
You may verify the refresh token up to once a day to confirm that the user’s Apple ID on that device is still in good standing with Apple’s servers.
in https://developer.apple.com/documentation/signinwithapplerestapi/verifying_a_user .
I have two question about the description:
Why should we verify the refresh token instead of access token to confirm the user's Apple ID is still in good standing with Apple's server?
The doc said refresh token can only verify once a day. But i can verify refresh token multiple times in practice. Is there some conflict between documentation and implementation?
Update on 10/17/2019：
For apps running on other systems, use the periodic successful verification of the refresh token to determine the lifetime of the user session.
I also saw the description above in in https://developer.apple.com/documentation/signinwithapplerestapi/verifying_a_user . I think periodic is also conflict with once a day.
Right now, I store the access_token and set custom expires time for follow verify request. And get notification from iOS client(getCridentialState) to delete access_token.