From a security perspective, I really wouldn't recommend putting your bank account details on a web page Wayne, as you'll attract every scamster and fraud merchant in net land.

Whilst offering a method of offline payment would be of benefit to some traders, you have to take into account how customers will input that data, how you will store that data and more importantly how the data will be secured.

Accepting payment via direct deposit to your bank is probably the most difficult method as it presents all sort of issues we would need to address inside of the software.

Issues that would need to be addressed in one form or another:

1. When you are on your cart page with all the order information on it, where do we send that information to when they press submit on their order? We would need to build an e-mail mechanism into the software for order information to be sent. It is not just as simple adding your e-mail address to a box in the software.

2. Since there is no logging of any personal information due to PCI Compliance rules, what would happen if you did not receive the order details?

3. There is no invoicing system, so the consumer would not receive any invoice for what they purchased.

4. If issue #1 and #2 failed the order could be lost in limbo and you would have received money with no way to track it back.

For all of these reasons, this is is why we rely on using a payment gateway because it eliminates each of these issues. I am sure we could code our software to make it work, but I am not sure we really want to at this point.

My personal take on using this method for payment is up there with sending my bank information to a Saudi Prince for a 500 million reward. Also, there is also no buyer protection. If I send you funds this way and you do not send me what I paid for, I have no recourse. If I paid with a credit card, I always have a way of disputing a charge.

OK Scott, I am seeing your point! and as I am not a programmer I do not know what is involved in getting this to work.

Anthony Temporal wrote:
Just going through all the posts and came across this one. We are a wholesaler and would like a off line payment as we sell on 30 days credit. Has there been any further development on this?

Anthony

But your reply to Anthony Temporal was " That will be something found eventually in SCC Pro."

So I am now asking: Is the above something that you are no longer considering for SCC Pro?

Wayne

P.S I read the forum rules...... I'll be a good boy, I promise!

If this feature appears at all in SCC Pro, it will probably be in combination with S-Drive.

I don't know know why CC insists that the server must be PCI compliant to store customer and sales data. The customer pays on a third party PCI compliant server, not the shopping cart server. If the credit card details never "touch" the shopping cart sever, it doesn't need to be PCI compliant. You can store customer and sales data on the server, just not the credit card data.



https://www.paypal.com/pcicompliance

The problem isn't one of of PCI compliance, but the security of a customer's non financial data. Most countries have the equivalent of the Data Protection Act, which means businesses have legal responsibilities for how a customer's data is collected, how it is used, who has access to it and finally how that data is protected. Plonking it online on a flat file database (irrespective of where it is hosted), would at best be irresponsible.

PayPal Express used to throw up warning messages on some browsers if it sent the user to a non SSL site. All that adds complexity and cost to the shop owner.

Payment processors don't do a great deal for their fees, so let them have the responsibility for keeping your customer's data secure. Most shoppers have far more trust in a payment processor, than a little known site operator.

Privacy issues concerning securing personal information you collect on a website can be a liability - but it has absolutely nothing to do with PCI compliance.

You don't need to use the shopping cart creator to worry about privacy issues. All you have to do is use the form builder to collect and store personal information in a database on your server.

Like I say, let the payment processors have the hassles and the responsibility of keeping that data secure.

I've just read thought this whole thread with great interest since I, too, have the same need as SO many other people here.

Like most other long discussion threads, this one has gone off down a couple of rabbit holes. But it seems to me that most people (especially in the early part of the discussion) don't need another online payment option ... rather, just a simple way to offer the alternative of passing responsibility for accepting the payment back to the vendor.

And that's what I am trying to achieve ... to have one very professional shopping cart (a la SCPro) that gives my customer the option to pay with PayPal (the only online payment I need) or to revert to me. Doesn't matter how I handle the payment (credit card over the phone, direct debit, purchase order, etc) - it just allows me to get their initial order in a clean way that's triggered from my website.

I love the Coffee Cup software and I will definitely stay with this for the creation of my website and cart. But it would make a world of difference (to me and many others) if there was a solution to this.

After reading the thread, I still can't see why this wouldn't be a relatively easy thing to add to SCPro, and it certainly seems it would be a widely welcomed enhancement.

That said, if Coffee Cup doesn't want to add this, I would welcome a work-around that allowed me to achieve this with the current SCPro and some kind of post-publish editing. In the end all I need is to (1) have another button for an "offline payment option" that (2) sends the order back to me and clears the shopping cart.

Any ideas most welcome!

You may want to read my post here Gary as I did outline quite a few reasons why this is not included with the software at this time.

http://www.coffeecup.com/forums/shoppin … post147579