- The situation when a customer provides credit card information by phone is rather unusual and not completely safe. Removing this from the admin panel simplified the interface and removed a potentially insecure approach.
This is a perfect example of why you are becoming very out of touch with your actual end user base, no one asked for this feature to be removed, it was/is instrumental to numerous businesses.
Our use case:
We create a product consulting fee or system design on our cart that customers can checkout on their own, we then design a complex system for them and often create a 10-15 item package that the client has agreed to, we need to then enter those product into an order thru admin. (This is not driven by client as too cumbersome for them or some products may be hidden from online view etc). We then finalize the order in admin and process final payment for the client on admin side.
Many Long time clients, and B2B clients want you to manage their orders, not shop for them online and checkout.
Many orders that are service type installation packages have items that change on the order after the job is finalized, everything is neatly edited on the order page of the admin side and the difference of price processed thru admin to reconcile job, this CANNOT be done using your workaround.
- Storing credit card data in CS-Cart is something we don't advise either. The "cc.tpl" template (credit card fields displayed on the CS-Cart checkout page) serves mostly for demonstration purposes.
Don't Stripe and Auth.Net arguably your 2 biggest processors use this? When entering credit cards into the storefront for purchases become for demonstration purposes, I'm out!
- Some payment processors (like Stripe) use "cc.tpl" too. But they capture the data themselves, without CS-Cart accessing it. This ensures that the sensitive data remains between your buyers and the payment processor.
- Not all payment methods in CS-Cart supported "Save and process payment" on the admin side; that required extensive development.
I have used Stripe (currently) authorize.net and Intuit, which all supported "Save and process payment". It's understandable that developing it for hundreds of processors may be cumbersome, but you already have it working so why remove it? Just hide that option for unsupported processors?!
- There was a workaround that allowed admins to achieve the same result on the storefront.
This workaround is so clumsy and poorly thought out, it also disproves your theory about insecure phone orders since we are just doing the same thing here anyway, its actually much less secure doing it here then on the admin side, where it is all cleanly packaged on one page with order management.
Also, when you use this "workaround" many things are not considered like every purchase you make logged in as your client, registers your IP/Identity with 3rd party chat clients and other add-ons as your client.
At worst, you should have consulted your customers more thoroughly before cutting this major functionality of a working store, I am sure I am not the only one that has many examples of why it should stay, it may even be a deal breaker for us after 12 years of businesses with you.
Please consider re-enabling this feature or at least providing it optionally for those that need it where it already worked, it literally cuts the intelligence of the cart system in half.
