I had a debate with a few developers about the heavily uses of sessions. "When processing payments"
Summary
We were discussing about storing Credit/Debit cards which cannot be written down to any file or db , so they said sessions are heavily used. Which obviously has its downside
Memory/Resource usage
especially when the project starts to scale to the enterprise level (tens of thousands or millions of hits)
What do you recommend as a best practice or alternative approach ?
Credit card numbers are used at the point of purchase and either entered by the user or fetched from a DB. The later should be PCI compliant. There's no logical reason to store credit card numbers in Session.
Credit card numbers are used at the point of purchase and either entered by the user or fetched from a DB. The later should be PCI compliant. There's no logical reason to store credit card numbers in Session.
Yes the server is a PCI complaint server, its for a company that has everything in place, but the mode of storing the card details are currently sessions, I asked if there was a better way
Yes the server is a PCI complaint server, its for a company that has everything in place, but the mode of storing the card details are currently sessions, I asked if there was a better way
I answered this question above. It seems you are looking for an answer that matches your expectations.
Session is an ASP.NET state management feature. In my experience, credit card numbers are entered by the user or fetched from the DB at the point of sale. There is no logical reason to use Session state management to store this type of information nor
is it recommended since Session is global. HTML form input and DB storage are both alternative forms of state management as explained above.
the mode of storing the card details are currently sessions, I asked if there was a better way
Why are you persisting credit card details? How long for? What happens in the event that the memory is reclaimed by the server and the card details are lost?
Why are you persisting credit card details? How long for?
What happens in the event that the memory is reclaimed by the server and the card details are lost?
Spot on !!!
That was my exact argument with the developers, my company is liaising with another team, who have over 10 years of code which simply persist sessions in IIS, I said it was a poor design and I am researching the way forward, I suggested as variables in a
Stored Procedure or clr function in sql server, but at the moment I am researching the way forward
It still begs the question why you are storing credit card details. You normally store them as a convenience for repeat customers, in which case you would use a database as mgebhard has pointed out. It's difficult to conceive of a reason for temporary storage
of the details. If you aren't going to store the details long term, you presumably just post the details to the payment provider and relieve yourselves of the issue, no?
By the way, Sessions are wiped out when the user closes the browser.
Using Session is a bad idea for this requirement. Session state will persist the information, but it is
not secure and only temporary. Be aware that
any kind of persistence may be violating the terms of service with the bank or credit agency. Most of them have very strict regulations on what you are allowed to do with this information. Furthermore, any payment application that accepts Visa and
MasterCard should be compliant with the PA-DSS (Payment Application Data Security Standard), a global security standard for payment applications.
Integrating with a 3rd party payment system that has all the built-in security mechanisms is the way to go.
Refer to the following
stackoverflow answer if you can't integrate with a 3rd party payment system.
Furthermore, any payment application that accepts Visa and MasterCard should be compliant with the PA-DSS (Payment Application Data Security Standard), a global security standard for payment applications.
Integrating with a 3rd party payment system that has all the built-in security mechanisms is the way to go.
Yes these are already in place. Its just the choice of storage that seems odd to me, hence I seeking alternatives which people have done
Ok - Session is not the right choice - use a database if you need to. Also, refer to the
stackoverflow answer I linked to in my previous response as to what kind of columns (if SQL) you should use and hashing.
Its just the choice of storage that seems odd to me, hence I seeking alternatives which people have done
The community has answer this question several times. Maybe the solution(s) presented by the community do not match the answer you are looking for?
Database inserts or hashing is out of the question, as the Payment gateways TOS demands it must never be written down or inserted. Hence reason I asked if there was another way
mgebhard
Or perhaps you are asking a more general question like; "What are the Pros and Cons of InProc Session?"
No, I dont like sessions, but as I said earlier, the developers are using sessions. Hence I am looking for an alternative
deepalgorithm
Ok - Session is not the right choice - use a database if you need to. Also, refer to the
stackoverflow answer I linked to in my previous response as to what kind of columns (if SQL) you should use and hashing.
No, I dont like sessions, but as I said earlier, the developers are using sessions. Hence I am looking for an alternative
Then you can look into using a distributed cache such as
Redis or the
Azure Redis service. If you decide to use redis, you need to use a good client library to work with it such as
StackExchange.Redis.
Knowing for how long you really need this credit card information could help.
As it seems you don't want a "save card details" feature, I would expect this value to be posted from the user input, used, and forgotten immediately or at worst kept for a short time using https://www.tutorialsteacher.com/mvc/tempdata-in-asp.net-mvc (still
uses a session variable but is is cleared when used).
Edit: More generally I use basically session variables as a browser session lifetime scoped cache that is for small, "private", frequently used values that preferably could be (re)loaded on demand. This way using the session is bascically just an implementation
detail.
ASP.NET comes with libraries that take advantage of these mechanisms.
Session
TempData
ViewState
Cache
Dependency Injection
Context
Configuration
Often a key is stored in an HTTP persistence mechanism which is used as an index; Session, TempData, etc.
There are also external persistence stores like database, distributed cache, and browser based storage.
These are your options. It is up to you to select an option that fits your needs. Given your requirement it seems HTML form Fields and/or a short lived cache is what you are looking for.
You can use Redis as session provider or SQL Server, in case of SQL Server it will have some side effect of performance but it will not consume as much memory resources and it will also solve issue of scalability, In case of radius it will give you great
performance. they are available as session state providers.
As far as security is concerned, if you want additional security then you can use encryption when store data.
We cannot solve our problems with the same thinking we used when we created them.
Then you can look into using a distributed cache such as
Redis or the
Azure Redis service. If you decide to use redis, you need to use a good client library to work with it such as
StackExchange.Redis.
ASP.NET comes with libraries that take advantage of these mechanisms.
Session
TempData
ViewState
Cache
Dependency Injection
Context
Configuration
Often a key is stored in an HTTP persistence mechanism which is used as an index; Session, TempData, etc.
There are also external persistence stores like database, distributed cache, and browser based storage.
These are your options. It is up to you to select an option that fits your needs. Given your requirement it seems HTML form Fields and/or a short lived cache is what you are looking for.
These options as well as others, dont quite hit the nail on the head, But Redis appears to do so
As I said above, I was asked to consult for a up coming company that processes a lot of payments and connected to the major gateways, Since the law demands they cant store credit or debit cards, redis seems to be a solution.
ViewData and the likes, named above, will expire when the scope (ie controller action) is completed, same with sessions, but I am looking into redis.
These options as well as others, dont quite hit the nail on the head, But Redis appears to do so
As I said above, I was asked to consult for a up coming company that processes a lot of payments and connected to the major gateways, Since the law demands they cant store credit or debit cards, redis seems to be a solution.
ViewData and the likes, named above, will expire when the scope (ie controller action) is completed, same with sessions, but I am looking into redis.
Redis is a global cache. Redis still requires state to tie the user to the cached credit card item.
Redis is a global cache. Redis still requires state to tie the user to the cached credit card item.
My thoughts are, with key value pairs, we can store the sessionID as the key and the card as the value. As if redis is installed on the local server, it could be dedicated to the card reader business/data object
Member
252 Points
1129 Posts
BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 03, 2019 11:22 AM|afrika|LINK
hi guys
I had a debate with a few developers about the heavily uses of sessions. "When processing payments"
Summary
We were discussing about storing Credit/Debit cards which cannot be written down to any file or db , so they said sessions are heavily used. Which obviously has its downside
Memory/Resource usage
especially when the project starts to scale to the enterprise level (tens of thousands or millions of hits)
What do you recommend as a best practice or alternative approach ?
many thanks
Ehi
All-Star
44411 Points
19195 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 03, 2019 12:01 PM|mgebhard|LINK
Credit card numbers are used at the point of purchase and either entered by the user or fetched from a DB. The later should be PCI compliant. There's no logical reason to store credit card numbers in Session.
Contributor
2036 Points
1025 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 03, 2019 12:59 PM|Khuram.Shahzad|LINK
I hope you will find answer here:
https://stackoverflow.com/questions/3002189/best-practices-to-store-creditcard-information-into-database
Member
252 Points
1129 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 03, 2019 01:30 PM|afrika|LINK
I think you missed the question. We are not trying to store card numbers, I asked about best practices to using sessions, as a developer
Member
252 Points
1129 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 03, 2019 01:31 PM|afrika|LINK
Yes the server is a PCI complaint server, its for a company that has everything in place, but the mode of storing the card details are currently sessions, I asked if there was a better way
All-Star
44411 Points
19195 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 03, 2019 02:08 PM|mgebhard|LINK
I answered this question above. It seems you are looking for an answer that matches your expectations.
Session is an ASP.NET state management feature. In my experience, credit card numbers are entered by the user or fetched from the DB at the point of sale. There is no logical reason to use Session state management to store this type of information nor is it recommended since Session is global. HTML form input and DB storage are both alternative forms of state management as explained above.
All-Star
190591 Points
27667 Posts
Moderator
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 03, 2019 04:09 PM|Mikesdotnetting|LINK
Member
252 Points
1129 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 03, 2019 04:13 PM|afrika|LINK
Spot on !!!
That was my exact argument with the developers, my company is liaising with another team, who have over 10 years of code which simply persist sessions in IIS, I said it was a poor design and I am researching the way forward, I suggested as variables in a Stored Procedure or clr function in sql server, but at the moment I am researching the way forward
All-Star
190591 Points
27667 Posts
Moderator
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 03, 2019 04:45 PM|Mikesdotnetting|LINK
It still begs the question why you are storing credit card details. You normally store them as a convenience for repeat customers, in which case you would use a database as mgebhard has pointed out. It's difficult to conceive of a reason for temporary storage of the details. If you aren't going to store the details long term, you presumably just post the details to the payment provider and relieve yourselves of the issue, no?
By the way, Sessions are wiped out when the user closes the browser.
Participant
1280 Points
439 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 04, 2019 03:16 PM|deepalgorithm|LINK
Using Session is a bad idea for this requirement. Session state will persist the information, but it is not secure and only temporary. Be aware that any kind of persistence may be violating the terms of service with the bank or credit agency. Most of them have very strict regulations on what you are allowed to do with this information. Furthermore, any payment application that accepts Visa and MasterCard should be compliant with the PA-DSS (Payment Application Data Security Standard), a global security standard for payment applications.
Integrating with a 3rd party payment system that has all the built-in security mechanisms is the way to go.
Refer to the following stackoverflow answer if you can't integrate with a 3rd party payment system.
Member
252 Points
1129 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 04, 2019 04:12 PM|afrika|LINK
Its a payment solution (IVR, click to pay, 3d secure etc)
There is a hash value generated by the card processing gateway, which developers are allowed to store in a db, but NOT the card number/details,
Yes I know, hence reason why I asked this question, to find out if there is a better way to persist data without sessions or written down
Member
252 Points
1129 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 04, 2019 04:14 PM|afrika|LINK
Yes these are already in place. Its just the choice of storage that seems odd to me, hence I seeking alternatives which people have done
All-Star
44411 Points
19195 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 04, 2019 04:46 PM|mgebhard|LINK
The community has answer this question several times. Maybe the solution(s) presented by the community do not match the answer you are looking for?
Or perhaps you are asking a more general question like; "What are the Pros and Cons of InProc Session?"
Participant
1280 Points
439 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 04, 2019 04:57 PM|deepalgorithm|LINK
Ok - Session is not the right choice - use a database if you need to. Also, refer to the stackoverflow answer I linked to in my previous response as to what kind of columns (if SQL) you should use and hashing.
Member
252 Points
1129 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 04, 2019 05:12 PM|afrika|LINK
Database inserts or hashing is out of the question, as the Payment gateways TOS demands it must never be written down or inserted. Hence reason I asked if there was another way
No, I dont like sessions, but as I said earlier, the developers are using sessions. Hence I am looking for an alternative
AS I said above, hashing is out of the questions
Participant
1280 Points
439 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 04, 2019 05:27 PM|deepalgorithm|LINK
Then you can look into using a distributed cache such as Redis or the Azure Redis service. If you decide to use redis, you need to use a good client library to work with it such as StackExchange.Redis.
Redis databases can also be secured.
All-Star
46080 Points
16782 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 04, 2019 05:54 PM|PatriceSc|LINK
Hi,
Knowing for how long you really need this credit card information could help.
As it seems you don't want a "save card details" feature, I would expect this value to be posted from the user input, used, and forgotten immediately or at worst kept for a short time using https://www.tutorialsteacher.com/mvc/tempdata-in-asp.net-mvc (still uses a session variable but is is cleared when used).
Edit: More generally I use basically session variables as a browser session lifetime scoped cache that is for small, "private", frequently used values that preferably could be (re)loaded on demand. This way using the session is bascically just an implementation detail.
All-Star
44411 Points
19195 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 04, 2019 09:33 PM|mgebhard|LINK
HTTP has 3 staple persistence mechanisms.
ASP.NET comes with libraries that take advantage of these mechanisms.
Often a key is stored in an HTTP persistence mechanism which is used as an index; Session, TempData, etc.
There are also external persistence stores like database, distributed cache, and browser based storage.
These are your options. It is up to you to select an option that fits your needs. Given your requirement it seems HTML form Fields and/or a short lived cache is what you are looking for.
Contributor
2036 Points
1025 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 05, 2019 05:20 AM|Khuram.Shahzad|LINK
You can use Redis as session provider or SQL Server, in case of SQL Server it will have some side effect of performance but it will not consume as much memory resources and it will also solve issue of scalability, In case of radius it will give you great performance. they are available as session state providers.
As far as security is concerned, if you want additional security then you can use encryption when store data.
Member
252 Points
1129 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 09, 2019 12:17 PM|afrika|LINK
Thank you everyone for the comments/advice. Interestingly, I never heard of redis and its a great way forward
I am researching into options provided. Many thanks
Member
252 Points
1129 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 09, 2019 12:21 PM|afrika|LINK
These options as well as others, dont quite hit the nail on the head, But Redis appears to do so
As I said above, I was asked to consult for a up coming company that processes a lot of payments and connected to the major gateways, Since the law demands they cant store credit or debit cards, redis seems to be a solution.
ViewData and the likes, named above, will expire when the scope (ie controller action) is completed, same with sessions, but I am looking into redis.
Thank you
All-Star
44411 Points
19195 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 09, 2019 01:01 PM|mgebhard|LINK
Redis is a global cache. Redis still requires state to tie the user to the cached credit card item.
Member
252 Points
1129 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 09, 2019 01:34 PM|afrika|LINK
My thoughts are, with key value pairs, we can store the sessionID as the key and the card as the value. As if redis is installed on the local server, it could be dedicated to the card reader business/data object
Contributor
2036 Points
1025 Posts
Re: BEST PRACTICE: Use of sessions to store Credit Cards ?
Dec 13, 2019 04:59 AM|Khuram.Shahzad|LINK
You can use local redis server or azure redis cache.