This month we launched two new sites, please take some time to check them out.
BestRest Products (http://www.bestrestproducts.com/) is a manufacturer and reseller of BMW motorcycle parts and accessories, all of which you can buy online. They make a bunch of cool custom add-ons that are known worldwide for their dependability and innovation. The site is built on AspDotNetStorefront and includes our WA Destination Sales Tax Lookup Tool that we created for ADNSF.
Eastside Basketball Club (http://www.eastsidebasketballclub.org/) is a non-profit organization that provides high-level training for youth basketball in Sammamish, WA. The site is built on the DotNetNuke content management platform, so EBC can make all of their own changes and add pages as they see fit.
Showing posts with label aspdotnetstorefront. Show all posts
Showing posts with label aspdotnetstorefront. Show all posts
Tuesday, January 27, 2009
Friday, January 2, 2009
2009 PABP Changes That Will Affect Your Online Store
Happy New Year to all. I wanted to start off the New Year with a bit of advanced notice to those in ecommerce that may not be up on all the rule changes for Visa security and merchant compliance and so you can make plans to take action this year.
In 2004 the credit card industry launched its standard security requirements which is based on the Visa standards set forth in 2001. The standard requires both online and offline merchants to safeguard sensitive consumer credit card information by following specific information storage rules and regulations.
For online store applications this took the form of Payment Application Best Practices (PABP). PABP changed the way that online store applications and shopping carts had to be developed; incorporating security features and rules into the store logic. Some of those security steps include, not storing credit card information in the database, requirement to change the administrators' password every 30 days, requiring "strong" password rules for site admins, and hashing all passwords.
For Merchants, this took the form of PCI Data Security Standards (PCI DSS) which required that merchants are either individually PCI compliant or use a system that is PABP compliant.
Why is this important to you, the online merchant?
As of October 2008, new online merchants with over 20,000 transactions per year cannot even recieve an online merchant account if they are not compliant in one way or another. However, beginning this year merchant account providers will start to "decertify" non-PABP applications, revok merchant accounts that are not using PABP certified applications and deny merchant applications to new applications that are not PABP certified. In 2010, all merchants will be required to be using a PABP certified application.
When I say non-PABP certified applications I'm not just talking about some obscure online stores, this includes some of the more popular store choices out there. As of this posting this includes:
1. OSCommerce
2. X-Cart
3. AbleCommerce
4. Volution
5. ZenCart
6. Miva Merchant
7. AmeriCart
8. Ecommerce Templates (ECT)
9. 3DCart
10. Eporia
11. Magento
...and a boat load more. In fact it's probably easier to tell you which applications are PABP certified and suitable for small to medium business (it's only a handful).
1. AspDotNetStorefront (Bright Spectrum's store of choice)
2. Storefront by LaGarde
3. eOne by Micros
4. MonsterCommerce (part of Network Solutions)
5. Znode Storefront
6. ShopSite
7. PowerCommerce by Merchantec
Using any of the non-PABP systems may pose some security risks and either they will need to become PABP compliant very soon or you will be required to move to a PABP certified store sometime in the near future.
If you want to explore moving over to AspDotNetStorefront and instantly becoming PCI Compliant schedule an online demo with us.
Bye for now.
In 2004 the credit card industry launched its standard security requirements which is based on the Visa standards set forth in 2001. The standard requires both online and offline merchants to safeguard sensitive consumer credit card information by following specific information storage rules and regulations.
For online store applications this took the form of Payment Application Best Practices (PABP). PABP changed the way that online store applications and shopping carts had to be developed; incorporating security features and rules into the store logic. Some of those security steps include, not storing credit card information in the database, requirement to change the administrators' password every 30 days, requiring "strong" password rules for site admins, and hashing all passwords.
For Merchants, this took the form of PCI Data Security Standards (PCI DSS) which required that merchants are either individually PCI compliant or use a system that is PABP compliant.
Why is this important to you, the online merchant?
As of October 2008, new online merchants with over 20,000 transactions per year cannot even recieve an online merchant account if they are not compliant in one way or another. However, beginning this year merchant account providers will start to "decertify" non-PABP applications, revok merchant accounts that are not using PABP certified applications and deny merchant applications to new applications that are not PABP certified. In 2010, all merchants will be required to be using a PABP certified application.
When I say non-PABP certified applications I'm not just talking about some obscure online stores, this includes some of the more popular store choices out there. As of this posting this includes:
1. OSCommerce
2. X-Cart
3. AbleCommerce
4. Volution
5. ZenCart
6. Miva Merchant
7. AmeriCart
8. Ecommerce Templates (ECT)
9. 3DCart
10. Eporia
11. Magento
...and a boat load more. In fact it's probably easier to tell you which applications are PABP certified and suitable for small to medium business (it's only a handful).
1. AspDotNetStorefront (Bright Spectrum's store of choice)
2. Storefront by LaGarde
3. eOne by Micros
4. MonsterCommerce (part of Network Solutions)
5. Znode Storefront
6. ShopSite
7. PowerCommerce by Merchantec
Using any of the non-PABP systems may pose some security risks and either they will need to become PABP compliant very soon or you will be required to move to a PABP certified store sometime in the near future.
If you want to explore moving over to AspDotNetStorefront and instantly becoming PCI Compliant schedule an online demo with us.
Bye for now.
Thursday, December 11, 2008
Destination Sales Tax...Brilliant!
For all you ecommerce folks here in Washington you have to really give it up to our state government when it comes to finding new, ever creative, ways to make work harder.
As most of you are well aware earlier this year (July 1, 2008) WA State launched its new "Streamlined Sales Tax" bill, otherwise known as Destination Based Sales Tax. For an ecommerce company this is a huge pain and is anything but "streamlined". The bill targets ecommerce companies and requires you to record each transaction amount and tax collected for each "tax location" that you do business with in the state. So not only do you have to figure out how much tax to collect, you have to become the state's accountant by explaining exactly where the tax should go. It is being sold as a way (sometime in the future) to level the playing field with out-of-state companies selling into our state, and vice versa, as part of the Streamlined Sales and Use Tax Agreement (SSUTA) which, ironically, is aimed at reducing the administrative burden on retailers and is full of controversy.
The reason I bring this up now is because I never really thought of it as a big issue, and that we could get away with just adding specific zip code rates to a stores zip code rate table, for a while at least. But after actually seeing the paperwork involved with accurately reporting the tax and seeing that a zip code can have several different rates, we were prompted to create a new Washington State tax lookup tool for AspDotNetStorefront. The tool works beautifully and plays nicely with the database-based tax lookup that it already contains. For a simplified explanation, our tax lookup contacts the state's database through our own web service (and a couple other functions) and applies it directly to the current order based on your shipping information, it even works with multiple shipping addresses. In addition, we will be adding a reporting tool that will spit out the information you need for reporting your quarterly tax collection to the State. I figure it is something that could done for the other 21 states that are a part of SSUTA, so that may be our next move.
I don't know how many states will end up taking part in SSUTA, it is not a federal government mandate, so only participating states have to go through this. Either way I'm sure that we will be soon collecting sales tax for other states sometime in the future. In fact you can start doing so now, if you so choose, by yourself becoming part of SSUTA; it's 100% voluntary. The SSUTA setup is actually pretty sweet and allows you to automatically pay the state for which you are collecting tax. We'd be more than happy to write the tax lookup code for that.
I guess I shouldn't complain too much this is the kind of stuff that keeps us in business.
As most of you are well aware earlier this year (July 1, 2008) WA State launched its new "Streamlined Sales Tax" bill, otherwise known as Destination Based Sales Tax. For an ecommerce company this is a huge pain and is anything but "streamlined". The bill targets ecommerce companies and requires you to record each transaction amount and tax collected for each "tax location" that you do business with in the state. So not only do you have to figure out how much tax to collect, you have to become the state's accountant by explaining exactly where the tax should go. It is being sold as a way (sometime in the future) to level the playing field with out-of-state companies selling into our state, and vice versa, as part of the Streamlined Sales and Use Tax Agreement (SSUTA) which, ironically, is aimed at reducing the administrative burden on retailers and is full of controversy.
The reason I bring this up now is because I never really thought of it as a big issue, and that we could get away with just adding specific zip code rates to a stores zip code rate table, for a while at least. But after actually seeing the paperwork involved with accurately reporting the tax and seeing that a zip code can have several different rates, we were prompted to create a new Washington State tax lookup tool for AspDotNetStorefront. The tool works beautifully and plays nicely with the database-based tax lookup that it already contains. For a simplified explanation, our tax lookup contacts the state's database through our own web service (and a couple other functions) and applies it directly to the current order based on your shipping information, it even works with multiple shipping addresses. In addition, we will be adding a reporting tool that will spit out the information you need for reporting your quarterly tax collection to the State. I figure it is something that could done for the other 21 states that are a part of SSUTA, so that may be our next move.
I don't know how many states will end up taking part in SSUTA, it is not a federal government mandate, so only participating states have to go through this. Either way I'm sure that we will be soon collecting sales tax for other states sometime in the future. In fact you can start doing so now, if you so choose, by yourself becoming part of SSUTA; it's 100% voluntary. The SSUTA setup is actually pretty sweet and allows you to automatically pay the state for which you are collecting tax. We'd be more than happy to write the tax lookup code for that.
I guess I shouldn't complain too much this is the kind of stuff that keeps us in business.
Subscribe to:
Posts (Atom)